Approaching the Website Design Process from the Browser

Lucijan has 10+ years of experience planning, prototyping, designing, and coding standards-compliant, responsive websites, and interfaces.

SHARE

“Here’s to the crazy ones, the misfits, the rebels, the troublemakers, the round pegs in the square holes… the ones who see things differently — they’re not fond of rules… You can quote them, disagree with them, glorify or vilify them, but the only thing you can’t do is ignore them because they change things…”— Apple’s Think Different campaign, Steve Jobs, 1997.

Most of the time, designers are still creating static mock-ups of screens using traditional design tools during the website design process. But some designers are taking a giant leap and bypassing them, going straight to code, building and adjusting designs in-browser, and testing their designs as they would appear to people in real-time. Are they the crazy ones, the misfits, the rebels?

Typically, the traditional website development process involves many phases, including planning, content strategy, designing, wireframing, prototyping, testing, developing, publishing, and so on. But during the design phase, could there be another way of producing “pixel-perfect” responsive site designs and bypassing design tools altogether?

With the rise of responsive design and the variety of devices in use (mobiles, tablets, laptops, desktops, watches), it’s much harder to keep everything consistent—and with more moving parts to take into consideration, the approach to designing websites and interfaces is changing.

Though it’s not necessary for a designer to become an expert coder, one solution is for designers to start working directly with the code that drives a website. Designers who can wrangle code with just a bit of HTML and CSS will find themselves a great asset to any team and have a massive advantage overall.

Why? When engaging a responsive website design project with all its complexities, designers typically don’t have the time to create a static design of one component (let’s say a header or a footer) across 10 different resolutions and viewports. Even if designing for only the most popular devices, they’ll still have to consider 4-5 screens with different aspect ratios, screen density, and screen dimensions. No small task to say the least.

Solving Website Design Challenges with Pen and Paper First

Let’s explore a different website design approach and planning process.

The first phase begins with a client questionnaire inquiring about the general project goals from a business perspective, the target audience, conversion strategies, various performance expectations, and so on. This is done before the actual design phase is launched to better understand the client’s needs and the project overall and in order to be more efficient down the line.

The next step is to write an outline of the project to confirm that the brief was understood. This is helpful when working on projects in a niche where you may not have much experience or expertise. Call it a functional specification—but less technical.

This helps with defining terminologies, keywords, and processes. Depending on the project’s complexity, it’s a good idea to do several scenarios and user flows—typically, the onboarding flow, searching and navigating a site, or an “add to cart” and checkout flow if it’s an eCommerce site.

Wireframing and Prototyping

Prototyping is the next phase in the website design process. Building quick wireframes to talk about the page layout, the functionalities, and how the site pages will look on different devices is a good start. It doesn’t take much time to build dozens of wireframes of different templates and components. A simple website prototype can be created from these, and depending on the complexity of the project, prototyping tools like InVision, Adobe XD, Balsamiq, Moqups, or Axure can be used.

Mood Boards and Interface Inventory

The next step is putting together a mood board: a collection of things the designer, the client, and other stakeholders may like on other websites—layouts, look-and-feel, colors or fonts, icons, images, and so on. This will help to define the site’s overall look-and-feel. If the client has a branding style guide, it should be considered and incorporated into the new site design.

Once various artifacts are approved—wireframes, prototypes, mockups, mood boards, etc.—it’s a good idea to do an interface inventory.

An interface inventory is a comprehensive collection of the bits and pieces that make up your interface.

Brad Frost

If doing responsive web design from scratch, then start by writing down all the components and elements that the project will be built from. An unordered list will do just fine and is definitely better than nothing. For example tables, buttons, images, typography, media, forms, navigation, components, etc.

An example screen from an interface inventory.

Designing in the Browser

“Designing in the browser” is a term that became popular with the rise of responsive web design. In order to minimize the hours spent in design programs like Sketch, designers were urged to move the design phase into the browser, and utilize CSS for layout and styling. This website design approach proves to be more efficient as it cuts out a lot of steps.

By focusing on the HTML mockup, and testing design ideas “in-browser” with CSS, time usually spent creating static mockups of pages in other design tools such as Sketch can be saved. It’s a good idea for designers to get hold of a good code editor and come up with a good browser refresh method so they can see changes in real time. Sublime Text and Codekit, for example, are a great combination.

HTML and CSS, structured as they are, force you to think about patterns and keep you in check. It’s easier to think about modularity when building HTML components that can be easily copied, duplicated, and filled with dynamic data while keeping the same structure. If you want to create a specific modification, you have to explicitly target that element, or add another CSS class.

When you style headings, unless they are overridden, they will be consistent across the site. Same goes for other elements. This type of thinking forces you to standardize, group common elements together, reuse already styled elements as much as possible, and most importantly, keep everything modular.

With a single CSS declaration, you can change padding on buttons for better touch targets, and test directly on a mobile phone, tablet, and desktop. This isn’t easily done in Photoshop or Sketch because other elements are not aware of each other in layout, and you have to reorganize objects each time you resize something.

Want to try out a different header color scheme? By working with just a few lines of CSS code, changes are visible on all HTML templates instantly, on all devices and screens. That kind of flexibility can’t be emulated easily when you have 20 static mockups. Granted, you could use “symbols” in Sketch or Adobe XD for reusable components, but they’re not as versatile as CSS.

In this phase, several technical decisions will need to be made. Questions that will need to be answered are:

Are the fonts you want to use available for purchase? Does the client have the budget for premium web fonts, or will you revert to using available free web fonts?

Will you be using multicolor or single color icons? Will the size vary throughout the site? Following, are you relying on custom-drawn icons, or on an already existing icon pack? What sizes will your icons need to accommodate?

By adjusting a few lines of CSS, changes are visible instantly on all devices and screens.

The Trouble with Fonts and Responsive Web Design

Choosing fonts for a responsive web design project can be challenging. There are many possibilities and just as many pitfalls. Since the design will be used in the browser, this is the best place to try them out. Font readability can vary based on size, weight, colors, and rendering, so by trying out fonts directly in the browser, designers can make sure things look right, and that the desired expectations are met.

There are many online tools for selecting and testing fonts and trying out typeface combinations. On Typetester and Typecast different fonts from various services and foundries can be found and tested. When working with a specific font subscription service like Typekit or Fonts.com, designers can generate fonts and test on their page templates directly. Generating a Typekit package with new fonts is simple and fast, and you can easily see how particular fonts will affect the performance of web pages.

Icons That Fit the Brand Style

If drawing custom icons, the size, grid, and style will need to be defined. Working in Illustrator, every artboard would represent one icon, for example. Icons can be easily exported from Illustrator as SVG or PNG, which can later be turned into an icon font with services like Icomoon. It is recommended to use vector icons (SVG) because vectors are resolution independent, so there are no concerns about how they display on high-definition (Retina) screens.

A Style Guide and CSS to Keep the Website Design Process in Check

Even if we design in the browser, with dozens of templates and components we could potentially lose track of where something is used, and in what fashion. It’s a good idea to build a styleguide of all components as a central repository. Specific page templates will be built from this style guide by combining UI components and elements into web pages.

UI components could be things such as pagination, product listing, image gallery, modal windows, form elements, etc., and are used as building blocks for templates. Keeping everything in one place is really handy when it’s time to test build a specific UI component.

With CSS, it’s a best practice to separate the component styles into separate files. For example, pagination styling will be in _pagination.scss, form elements in _form.scss, and all these files will be included in a single SCSS file with other files (variables, mixin, etc.).

Although style.scss might be composed of dozens of “small files,” when several people are working on the same project, it’s easier to keep track of changes (whether using source control or not) if everything is separated into smaller chunks. It’s important to continue to maintain the style guide after the website design project is in production, as the team will need to keep track of every site component.

Using Stylesheets – Modular CSS

From a development standpoint, there are many approaches to writing modular CSS. Most known are SMACSS (Scalable and Modular Architecture for CSS), BEM (Block, Element, Modifier), and OOCSS (Object Oriented CSS ). There is a fair amount to learn, even if you end up developing your own approach. At this point, you should have a nice collection of UI components and web pages, which will enable you to easily build new web pages. You can copy and paste elements from the style guide, and rearrange them as needed.

Since everything is modular, you don’t have to worry about design and code consistency; but don’t forget that if you adjust a UI component system-wide, you’ll need to update the style guide with the changes (or add the new component). To keep everything organized, it’s best to use some sort of templating/automation approach to working on web pages such as Gulp or Grunt.

Check CSS and code in the browser with the element inspector in Google Chrome.

What’s Next? Designing in the Browser

Now you have a central repository of UI components, every element documented and web pages built from those components. From this point on, it’s more than likely that designers will no longer need to open their favorite design tools as most of the “design” will be done directly in the code, and previewed in the browser.

Not quite sure how a specific change will impact the design? Now you can preview your design on different devices and browsers simultaneously to see how a font changed on a heading, or changing the size and color of a button will impact the design.

When using custom web fonts, how will adding more font weights impact page load performance? We can test work-in-progress web page performance using services like WebPageTest, and make informed decisions on actual results. We definitely can’t do that in Photoshop or Sketch.

Working with HTML and CSS, and working in the browser may not be for every designer during a website design process. But if designers really care about how their work looks on various devices and screen sizes, they need to make sure that it’s perfect every time. Something that looks amazing as a static design mockup might look less-than-desirable when viewed in a web browser on a mobile device. It would behoove savvy designers to build and test web designs in an environment where everyone will see them… in the browser.

Understanding the basics

What is the process of building a website?

1. Choose a web host 2. Register a Domain Name 3. Plan the site (type, navigation, content) 4. Design and build the site 5. Publish site 6. Promote site 7. Maintain site.

How long should it take to design a website?

Broadly, as it depends on the scope, a typical site (50-100 pages) can take approximately 14 weeks (discovery 3 weeks, design 6 weeks, dev 5 weeks). A simple 10-15 page, custom design site will take approximately 4-6 weeks.

How do you structure a website?

A good site structure equals better UX. A conventional site structure is critical for SEO and usability. Typically shaped like a pyramid, it should have clear navigation and keep the user in mind: 1. Homepage 2. Sections 3. Sub categories 4. Individual pages and posts.

How do you plan a layout for a website?

1. Choose a layout type taking into account the range of devices used to view the site 2. Define the structure using a sitemap 3. Identify navigation flow 4. Create wireframes to identify hierarchy.

Lucijan has 10+ years of experience working on the web, including planning, prototyping, designing, and coding standards–compliant and semantic websites and interfaces. He is a strong advocate of responsive design, building mobile–first interfaces where loading speed and optimization are a top priority so that users can benefit most from the website.

Comments

Stewart Pressney

Awesome article! I am just going to plug webflow.com here.
I use it to rapidly prototype with HTML CSS and JS animations.
The tool crafts succinct code and has a familiar interface for anyone moving over from programs like sketch.

Matthew Sandahl

Bravo! This process is so similar to how I work. Glad to see it makes sense to others. :)

Fabio

Wow. Just... WOW.
Such a giant step backwards to the age of system centered design when developer/designer's subjectivity was the alpha and omega ignoring the user completely.
Welcome back 1980, we missed you! (not!)

Jacob Conway

It's always best to be organized and your process seems to be pretty in depth. When you offer that kind of custom tailoring to a clients specific needs you deserve to make the big bucks. That's the kind of exceptional service every designer should incorporate. Thanks for sharing!

Bianca Sherawat

We are also providing magento websites so if you have any query related to magento or you want to develop the website in magento just contact us.
You can get answers for your relevant queries, call us on our company number 01724608777.

Lucijan Blagonić

Agreed. This process doesn't work in all cases, but a lot of times it's up to the designer to communicate benefits of different approaches and to make the clients understand. As long the clients have the user needs at the top of the list, I don't mind whatever approach they choose, but that's the story for another article. ;)

Frank McClung

I've been using this approach for several years in web design. It is very efficient and works great if you have a client that appreciates your expertise to the point they trust your design solutions. If you have clients that are new to web design, don't trust you, or have multiple levels of design approval to jump through, then this method won't work well for you or the client.

Jitendra Vyas

I also like to work with this approach only these days.

Ivo Lukač

Of course, it needs to be flexible enough. It is not a simple problem to crack :)

Lucijan Blagonić

I agree with you on that point, especially if you are using a CMS with that capability, but keep in mind that you still need to create a modular design that will be fitted into these building blocks. Looking forward to your example :)

Ivo Lukač

Starting with paper and pencil, yes. But as soon as you want to proceed switching to a CMS capable of building layouts and block in an easy way would be even more efficient IMO. Then it is possible to do design, content and code work in parallel.... Hope to show you what I mean one day soon ;)

Lucijan Blagonić

Like Ivo said, even this process can be improved upon further but the more we work in code the faster and more efficient we are — that's what I love the most. Thanks.

Lucijan Blagonić

I'd still say it's definitely faster with paper and pencil. :) On the other note, when working on larger projects where the code is often implemented on a custom backend so doing prototypes from "modules" is as good as it gets in that case. Like I said in the article though, I choose my approach based on the project and if the implementation into backend can begin during prototyping/discovery phase — we'll probably take advantage of that as well.

Ivo Lukač

Very nice insights in the web creation process. But there are still some parts to improve.
What if you could create wireframes and prototypes directly in a CMS instead of using Balsamiq or similar tools? ;)

Bojan Janjanin

A great read, Lucijan, thanks for sharing. This is a similar process to the one I use and have learnt is quite efficient.