On Designing in the Browser
It’s impossible to avoid discussion of a browser-centric design process now. A quick search engine query for “designing in the browser” turns up dozens of well-argued blog posts, articles, and presentations about the pros and cons of creating design systems in HTML and CSS versus the more traditional approach of creating static design comps in a program like Photoshop.
It’s interesting how dogmatic the discussion has become—anyone who writes code would bristle at the idea that there is only one way to do things. And yet, the front-end development community has a tendency to move from old best practices to new and shinier best practices at a brisk pace, and so it is easy to see how best practice thinking would also influence the design process.
Our process still revolves around creating static comps in Photoshop, but then we have also had a more hybrid approach later in the design stage, where the design system is extended into additional modules and pages in HTML. We’re lucky to be a team of a visual designer who can code in HTML and CSS, and a front-end developer who understands design and UX. In this way, we can create a solid foundation for the design system while remaining confident that it will be successfully developed into a comprehensive and responsive website.
Part of my own discomfort with designing in the browser is about maintaining some abstraction between the design process and the product. I don’t want to have my direct knowledge of CSS (or lack thereof) influence the designs; I don’t want to fall into a sameness due to executing the same code patterns. Photoshop allows me to look at art direction, color, type, and layout without worrying too much about semantics, structure, pseudo-elements, or SEO.
It’s true that there are drawbacks—text layout can be tedious, drawing can be slow, and fonts don’t look at all the same in Photoshop. It obviously doesn’t show liquid layouts and if you want to comp your responsive breakpoints, you need to draw every single one. But in some ways I find the forced tediousness of Photoshop comps to be a benefit—it makes me slow down and think about the choices I make rather than turning them into a sort of style lightning round.
All of this comes with the understanding that the process doesn’t result in a successful product without proper communication. If you are presenting static comps to a client, expectations about the final product need to carefully managed. Similarly, handing off static comps to a developer cannot be done without a lot of communication how the translation to HTML and CSS is going to work.
In the end, process is a subjective question—the best workflow is the one that leads the designer to a successful outcome. The more important point revolves around knowing the tools and the materials, as any designer should. Whether you design using static comps or markup, a solid working knowledge of the way web pages are built is a must for every designer.