Brad Frost{:target="_blank"} had an incredible talk about Style Guide Best Practices and I really hope the slides go up soon because they were great. As someone who admittedly doesn’t have the best design eye, i’m always looking for good ways to see and know if there are style issues I should be concerned about or how to help other on my team or non-developers that I work with think about styling and consistency. I guess, for me, what it comes down to is less “does this look pretty” and more “are we being consistent” which is why I thought this talk was really great AND had some super actionable, tangible takeaways that I can use when trying to use my design eye in the future.
Brad started talking about the idea of companies and brands. As a user, I want to see 1 brand. In order to think about this, someone has to think about six different types of style guides. First, there’s brand identity. Does the brand convert a clear identity of who they are. West Virginia University was given as a brand that does this well. Then there is a design lunges style guide. This related mostly to material design. Third, the voice and tone style guide. How does the company want to speak? What sort of language do they use? Mail chimp is a great example of this. One thing to note is that it’s easy to think about a fun playful tone you want to create for the positive scenarios or confirmation messages, but make sure you’re thinking about how to use that tone and voice for negative scenarios as well, like when a credit card is declined. Fourth, there is the writing style guide for grammar, etc. Fifth, the code style guide which could be things like SMACSS, BEM, css guidelines, modularity, and more. GitHub has a good example of code guidelines. And then finally, pattern libraries looking at the pages, responsive design and looking at designing systems of components. For example, tools like bootstrap and foundation are great but it does mean that so many pages end up looking so similar. The other framework pitfalls might be that you don’t need everything that’s in the package and you’re subscribing to some els’ed structure instead of creating your own. There were a few more pitfall points that I didn’t quite capture in my notes.
The major benefits of pattern libraries, which is what the rest of the talk focused on, are that they promote UI consistency and cohesion, they lead to faster production because you’re not reinventing the wheel every time you need something, there is a shared vocabulary, they’re easier to test, a useful resource (great to go back to as you continue developing), and finally, they are pretty future-friendly because you set them up once and son’t have to set them up again. Brad showed some great examples of how many different button types exist on large airline or bank sites to help demonstrate these points and more. He then went on to talk about how you sell the idea of investing time in creating a pattern library style guide to a company. You can to show, not tell. SO first, conduct an interface inventory which shows the decision-makers all the different button types, styles, etc. (The slide provides a great list of different things you can inventory). This also helps you as the person selling the idea to point out all the inconsistencies which lets you get buy-in, establish a scope of work, lays the groundwork, an plants seeds for spending time on something like this.
Once you are given permission to actually work on this, there’s a great methodology he introduced called the atomic design methodology. He also wrote a book{:target="_blank"} on this which I believe is either free and asks for a donation or is very very well priced. Here’s the methodology… atoms -> molecules -> organisms -> templates -> pages. So, you start with atoms. You want to really break the interface down as much as possible. Look at the h1s, buttons, fields, images, etc. The you want to take those atoms and put them together into molecules, a molecule is a UI component like a search form. The the molecules make up an organism so you take the molecules and put them into context like a header might include a search form molecule and a nav molecule. From there, you move on to a template which takes the organisms and puts them into a page layout, so the content and skeleton of a page. Finally, you make a page by putting content into the template. You validate or invalidate the underlying assumptions, you test variations like dashboards, alert messages, etc.
To break it down a different way you can look at it as reference (atoms) -> build (molecules, organisms, and templates) -> review (pages)
You want to stylize pieces at a time and explore different ideas together so that the dev-designer interaction isn’t do the discovery, then do all the design, then hand it over complete to the developers. Make you're you’re making element collages and not putting too much time into high fidelity mockups too early.
