This article is based on the talk (with the same title) I gave on WordCamp Europe 2016 in Vienna, WordCamp Split 2016, WordCamp Kyiv 2016 and WordCamp Sofia 2016. You can find the full slides on Speakerdeck. You can find more resources and examples on GitHub.

It started almost a decade ago when I first got a chance to read Designing with Web Standards by Jeffrey Zeldman. Designing with Web Standards was a starting point (or a turning point) for most of the designers at that time. There was no real guide for making a website back then. In a sense, this book was a guideline that advocated why web standards are important — and for me personally, it made me a better designer.

Since I wanted to excel in building web standards compliant websites, I’ve grown quite fast in writing HTML and CSS myself. Today, code is mostly the tool I use to prototype and design but it still holds great importance in my design process.

Static Image Is Not A Website

When we take on a problem we want to solve: on the web, mobile or somewhere else — first thing is to define the problem and find the right approach that will help us solve it. Building websites is hard, and it hasn’t gotten easier over the years. Most designers spend a lot of time in design programs like Photoshop and Sketch and it’s important to note that result of those programs are not websites. They are only visual representations of a website.

Unrealistic expectations — Static image we produce can often set unrealistic expectations for the overall experience. When presenting static designs to clients I always set expectations in advance so that we can focus on functionality over eye candy. That’s why I spend more time with code than Sketch.

Limited interaction — You can’t easily test interaction on that static mockup. Prototyping is welcome, but if you want top–notch experience then you need to make sure you test things in code as well and not only the initial concept. There are tools that try to change the way we build websites by generating HTML and CSS code directly while we design, but that code is far from one that an experienced front–end developer will deliver. Tools like InVision and Principle can help you prototype and animate your static mockups but they can also create extra overhead in your design process.

Different screens and devices — There is still no easy way to design for different resolutions in graphical programs.

Content: images and text — Working with content has gotten easier over the years. There are plugins for Photoshop, Sketch etc. that will help you generate placeholder content based on pre–customized input, but testing edge use–cases is usually easier directly in HTML.

Single point of view — And one of the main problems of delivering static design mockups to developers is that we can’t specify everything, only the visual layer of the final experience.

That visual layer can often be misleading. Our website shouldn’t be a work of art to be put on a shelf and admired — instead it should be vital in achieving goals we defined earlier.

If we were to test that design in the browser as a HTML prototype we would define a much different opinion as opposed to observing the static image. Designing perfect use–cases in Photoshop can often lead to problems on other platforms and screen sizes. Our beautiful background images could overlap our text with low contrast and our main call–to–action would suddenly become invisible.

Actual User Concerns

Our visitors don’t see the perfect mockup but only a website. Their overall experience will depend on a different set of things. Beside looking at the website aesthetically they will also take other things into account.

It takes too long to load — Everything is great when we are at home, browsing the web from a fast Wifi connection. But this is the ideal case. Using the site on the mobile, on a slow Edge connection provides a different experience, not necessarily a good one.

Text is not legible — Due to poor choice of web fonts, font weights or font sizes, the text in the browser is not legible. Fonts on static mockups looked great, but the rendering of fonts varies in browsers and you have to take that into account while choosing typefaces.

It’s not keyboard accessible — Some basic things like skipping content sections, toggles that work with the keyboard, modals you can close with escape key and many more.

The touch targets are too small — Small touch targets are usually evident on smartphones and tablets. Wanted to open the dropdown but instead you opened a product page.

There are no hover states — You’d think we’d master the hover states so far, but designers still forget about that.

It lags when I scroll (Parallax <3) — And one of my favorites — it lags when I scroll. Usually a beautiful site, large background image and a badly implemented parallax effect that even a high–end computer can’t scroll without choking on it.

There are many more things that will make the site unusable, but these are usually the first I observe.

Set Ground Rules

If we define our expectations before we start to design then we can tackle these challenges during the whole process. It’s important to set some ground rules as well.

Performance — With the average page size growing to almost 2MB — performance is one of the most important things we should consider when building websites. Optimize assets, rethink web font delivery, reduce number of requests per page and improve the overall performance of your website.

Usability — Do you want to create a page that is simple to use? Then set usability as one of your main goals. If you think it’s more important to showcase your animation skills than to create a usable menu — you might be on a wrong path. There is nothing wrong with designing beautiful interactions, but focus on usability first, polish after that. Simple and functional will always get you points with users.

Readability and legibility — With thousands of available web fonts to choose from it’s hard not to get distracted while setting type. Whatever you choose, please keep your readers in mind. Make sure the font is legible on different screen sizes and resolutions, and it works well in the context where it’s used.

Accessibility — We came a long way with accessibility — we have good tools, libraries and resources. Accessibility is also very well received in our WordPress community as well. But there is still a long way to go. Designers and developers often see accessibility as an afterthought. “People with disabilities are only a small percentage of our user base.” — or so they say. This can’t be further from the truth. Next time you create that fancy checkbox with two lines of JavaScript or CSS, think about how it’s affecting people who don’t use the computer the same way you do.

To name only a few, there are many more goals you can set. Good design is hard but you can pull it off by making decisions and meeting your users where they are — in the browser.

Designing in The Browser

Designing in the browsers doesn’t presume that designers need to write their own HTML and CSS. Instead it presumes that certain decisions should be made in the browser with the input of other team members and their specific skill–sets. The browser is really a synonym for making decisions on actual feedback and usage — and not assumptions. I have worked with designers who made poor design decisions simply because they weren’t aware of how a certain font would look like in the browser, or how that specific interface element (e.g. dropdown) would work on a touch–screen device.

Style guides

Style guides help transpose the design process from a single point of view to include multiple perspectives (and expectations) that help deliver a better experience. Style guides are changing the way we deliver design. We used to create full blown pages in Photoshop, relying on Smart objects to easily reuse components, but this always fell short. With responsive design gaining momentum, it was almost impossible to continue the usual practice. Since I was fluent in CSS, it was easier for me to improve the design in code, and show it to the client, than to create iterations in Photoshop. Style guides build upon these ideas, by helping me define a set of standards and guidelines — effectively building a design system.

Style guides encourage modular thinking. It’s in our interest to keep things simple, and what better way then to reuse things as much as possible. Reuse components, styles, fonts, colors, proportions etc. Modular thinking is responsible for delivery of the building blocks that are part of that design system. Where we once delivered only carefully produced pages, we now deliver components that can be (re)used to create more variations.

One characteristic of good design is consistency. Having all components and building blocks laid out on a single page helps us in achieving that. By observing how certain user interfaces work and look on their own and as part of a whole system we can get a broader perspective on consistency. Common examples of visual consistency are colors and typography.

Components presented in the style guide are by nature self–documented. If you see a navigation tabs components, it’s upfront obvious what it is and how it works. Observing that same component on a full blown page would result in questions — is this a custom use–case example, or will it work anywhere (e.g. in the sidebar)? Will it work without this container that gives visual border? What classes/modifiers are necessary to get this visual look? You can write a few sentences about each component, explaining what it does and how it should be used but for start — make it modular and display it on your style guide.

Living Style Guides

Living style guides (sometimes referred to as “front–end” style guides) combine the power of templating and automation to display styles, components and code examples. Basically, every pattern we see on the style guide is just another instance (duplicate) of the actual component used on the project. If we change the style of that specific component even slightly, the changes will be visible throughout the site and in our style guide as well. This is the true power of style guides in our everyday design work. In the end, if the style guide isn’t updated accordingly, it will become obsolete over time.

Besides automating, we want to be able to pass dynamic data to each module so that can see how content shapes our design. Depending on the type of the project, I define a set of variables for each component and then pass custom content values. That way we can reuse a single, for example, product listing component in different places and with different results. Testing long title? No problem. On some projects, I rely on Gulp build system and “file include” plugin to build templates where I can easily replace placeholder variables with dynamic data. By combining automation with dynamic data, we get reusable code patterns we can use throughout our site. Generating variations is simple and we can easily test different situations.

Design Deliverable

So what do we actually deliver to developers and clients? A set of rules and guidelines. It’s much harder to deviate in the future if you have everything laid out to the detail. What colors are used where? What components can be used together?

We are delivering components and building blocks, but more importantly, we are delivering a design system. Components that follow the rules and guidelines set before.

These goes without saying, we are presenting how those components work together in the form of full pages. We don’t have to build every single “About us” sub page out there. But for important things like user onboarding, searching, view and buying products on webshops — it’s mandatory. Since we have good workflow for building pages this shouldn’t be a problem.

We also deliver our best practices. Best practices for how code is written, how colors are defined, how new components are designed. If we strive to include best practices in our process then this will also reflect in our work.

Start Simple, Complicate Gradually

Style guides can seem daunting, but there are plenty of resources and tools that can help you get started. styleguides.io is a good place to start — a comprehensive collection of articles, tools, talks and more.

Start simple by creating a simple spreadsheet where you document different interface elements.

I maintain a list of components and pages I need to create for a project. I list their basic properties, names (following naming conventions) and a short description. I try to identify usage patterns — how someone can interact with them, how will it be discoverable in the design etc. For interactive components like tabs, accordions, modals etc. — I also define a dependency, if I rely on a third–party script or code to make it accessible or functional. Read more about the initial concept and see the spreadsheet example (Google Spreadsheet).

Next, categorizing your colors, font choices, default element styles… Your SASS or LESS variables are a pretty good place to start. You’ve already defined font families, colors, proportions… and now it’s time to display them in your style guide.

Design discussions are usually much more productive when we focus on specific components. Where before the client would comment on the “whole page”, he can now focus his attention on a specific component. Discussing and improving overall design starts from the smallest component first. Since you’ve taken a modular approach, you already have the building blocks. Include these patterns in a style guide.

If you want to keep your style guides relevant — they should be based on your codebase. Find a way to automate the process of generating and updating style guides. I’m currently working with Knyle Style Sheets. KSS is a methodology for documenting CSS. It enables you to document your CSS code in a way that can be automatically parsed and transformed into a living style guide.

The best part of designing in the browser is that you can use all sorts of tools for testing, from your browser inspector to third–party scripts and services. Want to test basic accessibility to make sure you didn’t forgot or misuse something? Try tota11y JS library which highlight potential accessibility problems with “how to improve” example. You can’t test accessibility in a static image. Not happy with your PageSpeed score? Test how your assets, custom fonts and libraries affect page loading. Showing stakeholders a loading score with proposals for improvement will in the end leverage you to make right decisions.

Good Design Makes Sense

Starting with style guides can be hard — and implementing this approach into our existing design and development process can be challenging. Designer’s job is not easy, but going that extra mile pays off. Good design can be hard, but it makes sense. By designing in the browser I am able to communicate better with my clients, reduce delivery time and provide extra value to the project. But in the end, when designing in the browser, clients can become a part of that design process from the start.

Additional Resources

Links that were helpful in creating this article.

• Collection of tools and articles for building style guides — Styleguides.io
• An In-Depth Overview Of Living Style Guide Tools — Smashing Magazine
• KSS — A methodology for documenting CSS and generating styleguides
• Documenting interfaces — Concept
• Polar Starter — Project starter with Gulp and KSS setup
• Has Design Become Too Hard — Article by Jeffrey Zeldman