We recently gave our Twitter followers the opportunity to ask anything they wanted on the subject of Front End Style Guides. Here are the best questions and (of course) the answers!
1. Semantics
@anna_debenham@wdtuts What's the difference between a style guide and a pattern library? (In both theory and practice).
— Jack Appleby (@jackappleby) May 12, 2014
There are lots of interpretations, but this is how I see it: Style Guides are an overarching term for a range of possibilities; editorial style guides that discuss tone of voice, design style guides that explore the typography and colours that can be use on the site, and even code style guides to maintain consistency when multiple people are adding to the codebase.
A pattern library is a type of style guide that's close to a fully-fledged framework. Pattern libraries are great deliverables for developers – they contain all the snippets of code for modules found on the site. It can be put together like an instruction manual for maintaining a site's styles and front-end code.
In Dave Rupert's words: "Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs." That's a pretty good description of what I think a pattern library is.
2. Style Guides and Redesigns
@anna_debenham How early do you start creating the style guide in a redesign project? @wdtuts
— Matt Quirk (@MattQuirk) May 12, 2014
Right at the start. It's the first piece of development I do. Every site has common elements like paragraphs, links, headings, lists, forms… and having a pre-prepared file with all these pieces of markup in is really useful to collaborate on early on in the project with designers.
A good place to start is with Paul Lloyd's Barebones, as that contains all the raw HTML likely to be used on a site. It's then easy to build upon this foundation with each piece of functionality that gets added.
3. A Matter of Maintenance
@anna_debenham@wdtuts How do you manage the process of creation/maintenance of SGs along with hi-fi deliverables: pattern libs, comps
— James Nettik (@jnettik) May 12, 2014
In past projects I've worked on, the designer has used TypeCast to build up their styles so they can try out the basic typography in the browser and test it looks good on different devices, before committing to a specific design. That worked really well for both of us, because it helped flag up issues with things like dodgy-looking webfonts or problems with colour contrast on low-dpi screens early on.
Some designers, such as Dan Mall, build up element libraries in their graphics software during the design process. By breaking up the design into modules, converting this into a style guide is really straightforward. Jon Aizlewoodused this approach during the redesign of Code for America, and it meant I could start building components and prototyping ideas while the rest of the design was still ongoing.
4. Clients and Communication
@anna_debenham@wdtuts Any tips on client communication/approval? How do you get clients on board with something they can't fully visualize?
— James Nettik (@jnettik) May 12, 2014
@anna_debenham@wdtuts How do you present/involve/get clients familiar with the style guide? (Especially those without web knowledge)
— natalie (@talkanatalka) May 12, 2014
(I grouped these two questions together because they are very similar.)
It will depend very much on the client. I've found that style guides are a really easy sell to in-house web teams because if they're maintaining a sprawing site, constantly rewriting the same code and dealing with a supermassive stylesheet, they will immedietly see the benefit of having one.
Clients who aren't directly dealing with design or code day-to-day probably won't understand the benefits of having one (It's not normally something I would show off to the CEO), but I build one regardless because I know it helps me, and hopefully, it'll help whoever has to add code to the site a year later. It's nice to be able to hand it over to the next developer at the end of a project. It feels like good manners.
5. Convincing Your Boss
@anna_debenham@wdtuts How to advocate for the use of styleguides in organizations that don't use them for lack of culture/tight deadlines?
— Daniel Fosco (@notdanielfosco) May 12, 2014
I explain that although style guides take a bit of time to develop and maintain, they actually save time in the long-run. Maybe I'm more aware of it as a contractor, but it takes quite a bit of time to familiarise myself with a new project, and not having all the information I need costs time.
With a site that has a pre-existing pattern library, I can add a new piece of functionality to the site much more quickly than if I had to forage around the site hunting for similar styles or recreating something that nobody is aware already exists.
Having a boilerplate style guide I can build upon also saves a lot of time, so producing one for a project doesn't take much extra effort. Making sure people maintain it is the hard work.
6. On Automatic Style Guide Generators
@anna_debenham Would love to know what you think about these automatic style guide generators I've been hearing about recently... @wdtuts
— Westley Knight (@westleyknight) May 12, 2014
There are a few style guide generators, Welch Canavan wrote up a list of them here: http://welchcanavan.com/styleguide-roundup/
A couple of others not mentioned include Stylify Me and Frontify, so you should check out those too. I really like the sound of KSS (Knyle Style Sheets) because it generates a living style guide from comments in your CSS.
Style guide generators can be useful in some cases, but one of the benefits of building up a style guide as a site develops is that it forces you to think more carefully about your code – each pattern is like a lego block, so it helps keep you in the right mindset if you're going for a more object oriented approach.
Where I think generators are useful is if you come into a project for a site that's already been designed, you're on a tight deadline and you're looking for what colours and different heading styles are used. It's handy if you want to grab a list of hex codes.
Nicole Sullivan's Type-o-matic is good for this situation as well. It's a browser plugin that counts all the fonts on a page and orders them by colour and size.
7. Non Visual Folks
@anna_debenham@wdtuts How do you effectively communicate to both designers and back-end devs within the style guide BEYOND showing code? TY
— Joseph James (@joeaugie) May 12, 2014
When building up your style guide, put yourself in the shoes of a contractor or new employee who has been asked to add a new section to the site. What information will they need?
- In some of my style guides, I add usage notes to explain when to use certain patterns. It's helpful for content editors to have a resource explaining when to use bold text and when to use a heading, or the type of list that's appropriate for different situations.
- While working on the University of Surrey redesign, we added some photo guidelines to explain how images on the web could be used, and the type of art direction that was appropriate to the brand.
- I often add colour swatches so designers can quickly find the hex code if they need it, and I also include the Sass variable name if there is one.
If you add information for different roles, it becomes a centralised place for people to go and find what they need. This is something GOV.UK have been successful at achieving with their Service Design Manual.
8. After You're Done
@anna_debenham@wdtuts What are some good ways to use styles guides in design development as well as a reference once site goes live?
— Marc Drummond (@MarcDrummond) May 12, 2014
@anna_debenham@wdtuts Particularly the challenge of keeping style guide relevant and accurate if design evolves once it is live.
— Marc Drummond (@MarcDrummond) May 12, 2014
Prototype code and designs with it, and refer to it in front of other people as much as possible. When you're building some new functionality for the site, build it in the style guide first so that if you're developing in that before pushing changes, it won't get out of date. By doing this, you can also check that other styles don't conflict with the new ones.
Version control your style guide. Make it open source if possible: people are more likely to keep it up to date if it's out in the open.
Ian Feather recently wrote about how Lonely Planet maintain their style guide with an API. This won't be suitable for every project, but I can see how useful this would be for a big site that's constantly in development. It feels like a good technique to aim for.
Conclusion
I hope I've been able to answer some of your questions about front end style guides! If you have any others, feel free to ask them in the comments section.
