A couple weeks ago, I wrote about using Live Wires to create better prototypes in a way that helps reduce needless disposable deliverables. This week, I’m going to talk about how I begin the next phase of my in-browser design process: Crafting a style guide.
As I mentioned before, I’m all about reducing as much waste as possible in my design process. Everything we do should contribute to the final product so we can spend more time addressing design problems and less time painting pictures and translating them into our intended medium. Ultimately, I think this change in approach results in better products and more value for our clients.
Disclaimer: While I personally think designing in-browser is the way of the future, I don’t believe that great design can’t be done without it. Most of my favourite designers are diehard Photoshop champions (though I hope one day they give the in-browser concept a fair chance).
The concept of designing web sites and apps with graphics editors like Photoshop is so ubiquitous, it seems crazy to imagine working without these tools.
When you think about it, the traditional web design process is a response to the limitations of early CSS. Photoshop just happened to be the tool that best fit the job at hand; one that we bludgeoned beyond its intended purpose so we could design graphically complex UIs. The result of toying around in it created a slough of UI porn which was meant to give web design similar capabilities to print design. When we use a graphical editor, we design graphics. We add layer style like gradients, drop shadows, and textures to make things “pop.”
Ironically, print design never succumbed to these visual tricks and ‘flat design’ is actually just a return to its core principles.
We’ve gotten really comfortable on this picture-painting path over the years, but as products get more interactive, UIs more flexible, devices more unpredictable, and web typography more sophisticated, it’s leading us astray. Photoshop comps can no longer cut it.
I’m far from the first to express the virtues of in-browser design. Many smart people have presented compelling arguments for it over the past few years, so I don’t have to. I’m curious to find out why more designers haven’t adopted this approach and how we can make it easier to transition to this way of thinking.
When you read any of the articles prosthelytizing in-browser design, all it takes is a scroll through the comments to witness the common hurdles that stop people in their tracks. They’ll usually say something like this:
- “Coding is too hard.”
- “It limits your creativity.”
- “It leads to bland designs.”
- “It can’t work for complex sites.”
- “It’s difficult to create irregular objects.”
- “It’s difficult to think visually with code.”
- “I can think more creatively in Photoshop.”
- “I need to show the client something earlier.”
Are these concerns really symptoms of in-browser design, or is it simply that we haven’t distilled the process yet? I have a feeling that most critics dive in, flounder, and drain the pool without really learning how to swim.
In Switch, the Heath brothers make a good observation:
When people try to change things, they’re usually tinkering with behaviors that have become automatic, and changing those behaviors requires careful supervision by the [rational part of your brain]. The bigger the change you’re suggesting, the more it will sap people’s self-control. And when people exhaust their self-control, what they’re exhausting are the mental muscles needed to think creatively, to focus, to inhibit their impulses, and to persist in the face of frustration or failure. In other words, they’re exhausting precisely the mental muscles needed to make a big change.
There’s a lot of truth to this. When we try to make sweeping changes to our process, it’s almost impossible to be comfortable and feel like we’re doing good work right away. A lot of folks dive off the deep end attempting to apply familiar comp-based workflows to in-browser design, expecting the results to be of similar quality. When they get tripped up or find the designs aren’t working, it’s much easier to revert to old habits instead of sticking it through and re-examining each step.
I spent a lot of years frustratedly switching between Photoshop and CSS before nailing down my workflow and learning how to be creative in code (by the way, memorizing a few CSS declarations is far easier than memorizing those Photoshop tool menus). I still occasionally find myself hopping in the ‘ol faithful Photoshop in search of ideas, but that’s where it stays. Idea generation and graphic editing. Start small and move on.
Okay, enough philosophical pep talking. Let’s do this.
Make the transition
There’s a lot of muscle memory locked up in those esoteric tool palettes to unlearn, and a great first step towards UI design in the browser is to start with a live style guide. There are plenty of articles about live style guides out there, but most seem to be an afterthought used as a reference guide for future design and development. I’m suggesting it as a starting point. There are several unique advantages to this:
- It’s a fantastic early design deliverable for clients.
- You’re not deferring the finer details of your UI to a developer.
- You eliminate much of the slicing and dicing of Photoshop comps.
- You are writing a strong foundation of production CSS right off the bat.
- It’s fun and easy to experiment on such a focused collection of elements.
- For less experienced developers, it’s a great place to learn the finer points ofCSS without getting bogged down with its quirky layout aspects.
- It gets you thinking modularly about your design. Focusing on individual elements without the distraction of layout is helpful on getting the details right.
If you are still uncomfortable coding a full site, this also works as a decent hand-off to more experienced front-end engineers on your team. You can even use Pagelayers to export your elements into a full layered PSD if you feel the need to continue in Photoshop. And if you change your mind about certain elements as you progress, you can always update your guide.
We don’t have to dive into browser-based design head first. We can do little things that gradually enable us to create more powerful interfaces without the intense discomfort brought on by total immersion.
Here’s how I do it:
Choose your type
Typography always comes first—using a combination of client requirements, experience, and research, I settle on a few typefaces I’d like to experiment with. I’ll usually plug a sample of real content into Typecast and start typesetting in there. I always begin with paragraph text, create a modular scale, and move on to headlines, block quotes, and callouts. See Tim Brown’s magnificent More Perfect Typography talk for a great breakdown on how to design typographically.
Once I get a rough idea of the basics, I take the generated CSS out of Typecast and pop it into my own home-grown style guide template, which you can check out for yourself on Github.
Design your system
Now for the fun: building that style guide. Here’s how I do it:
- Tailor guide.html to my project by changing the title, typeface names & fonts used, and if decided, the colours; then remove any unneeded elements.
- Apply my type settings from Typecast to my SCSS files and start refining.
- Work down the page styling, using separate .scss files for each UI element until I’m satisfied with the entire document.
- Review the finished guide with the team and client and adjust accordingly.
It’s dead simple to experiment with various colours and typefaces. Just copy your styles to a new folder and adjust accordingly (or do what I do and create separate git branches for each version). This method is great for focusing on individual elements and gets you thinking in modular systems rather than pages, which as we addressed in the last post, prevents us from missing vital elements and functionality.
Connect it to Live Wires
Once I have a solid style guide, I simply apply the CSS to our Live Wires template. At this point, we’re well on our way to a solid design in the browser. We have a full set of designed elements applied to a rough layout.
We still have to massage and refine the details, but at least much of our foundation is taken care of. This can really save you and your clients a ton of time.
It may take a little longer to get each of the elements just right when you’re getting your feet wet, but then again, you won’t need to translate designs to code later and you’ve covered much of your front-end development, too.
- Keep your guide.html file alongside your site. It will stay updated even as you refine your pages, and continue to work as a nice reference for others.
- If you need to add an element more than once across different pages, bring it into your style guide and start designing it there first. Refine as needed. This will keep you ‘thinking modular’ and ensures your guide stays current.
- Feel free to drop into your graphics editor every now and then to experiment with specific elements, but resist the urge to design an entire layout. Get into code as soon as possible.
- Set aside major milestones in your work for comparing progress across reviews. I like to use tags in Git to mark important milestones, but you can regularly copy and archive your folders if Git ain’t your thang.
Skip the trap
Starting with a live version of my style guide has been pivotal to successful in-browser design. I can focus on individual elements and typography without getting bogged down by layout or page-specific quirks. Thinking this way also allows me to skip the trap of designing a series of individual pages in Photoshop. I’m less concerned about the quantity of templates I need to design, and more focused on putting valuable time into creating higher-quality reusable elements. By skipping Photoshop, I conserve several hours for experimentation and refinement and I have full control over the final product.
Designing web interfaces in Photoshop and handing them off to a developer to finish them is like an architect designing the outside of a building and leaving the the internal structure up to the construction team.
Give in-browser design a fair shot and let me know how it goes. Together we influence how this concept evolves. Let’s see what’s possible.