Approaching the Website Design Process From the Browser

“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.

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:

• Will you use a CSS preprocessor? (recommended)
• What type of responsive grid will you use for the layout?
• 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?

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.

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.