Are you thinking about style guides lately? It seems to me it couldn’t be a hotter topic these days. I’m delighted to see it, as someone who was trying to think and build this way when the prevailing wisdom was nice thought, but these never work. I suspect it’s threefold why style guides and design systems have taken off:
- Component-based front-end architectures becoming very popular
- Styling philosophies that scope styles becoming very popular
- A shift in community attitude that style guides work
That last one feels akin to cryptocurrency to me. If everyone believes in the value, it works. If people stop believing in the value, it dies.
Anyway, in my typical Coffee-and-RSS mornings, I’ve come across quite a few recently written articles on style guides, so I figured I’d round them up for your enjoyment.
How to Build a Design System with a Small Team by Naema Baskanderi:
As a small team working on B2B enterprise software, we were diving into creating a design system with limited time, budget and resources … Where do you start when you don’t have enough resources, time or budget?
Her five tips feel about right to me:
- Don’t start from scratch
- Know what you’re working with (an audit)
- Build as you go
- Know your limits
- Stay organized
Style guide-driven design systems by Brad Frost:
I’ll often have teams stand up the style guide website on Day 1 of their design system initiative. A style guide serves as the storefront that showcases all of the design system’s ingredients and serves as a tangible center of mass for the whole endeavor.
This Also published their style guide (Here’s 100’s of others, if you like peaking at other people’s take on this kind of thing).
What is notable about this to me is that it’s the closest to the meaning of style guide to me (as opposed to a pattern library or design system that are more about design instructions for building out parts of the website). They only include the three things that are most important to their brand: typography, writing, and identity. Smart.
Everything you write should be easy to understand. Clarity of writing usually follows clarity of thought. Take time to think about what you’re going to say, then say it as simply as possible. Keep these rules in mind whenever you’re writing on behalf of the studio.
Laying the foundations for system design by Andrew Couldwell:
I use the term ‘foundations’ as part of a hierarchy for design systems and thinking. Think of the foundations as digital brand guidelines. They inspire and dovetail into our design systems, guiding all our digital products.
- At a brand level they cover things like values, identity, tone of voice, photography, illustration, colours and typography.
- At a digital level they cover things like formatting, localization, calls to action, responsive design and accessibility.
- And in design systems they are the basis of, and cover the application of, things like text styles, form inputs, buttons and responsive grids.
Again a step back and wider view. Yes, a design system, but one that works alongside brand values.
How to create a living style guide by Adriana De La Cuadra:
Similar to a standard style guide, a living style guide provides a set of standards for the use and creation of styles for an application. In the case of a standard style guide, the purpose is to maintain brand cohesiveness and prevent the misuse of graphics and design elements. In the same way LSGs are used to maintain consistency in an application and to guide their implementation. But what makes a LSG different and more powerful is that much of its information comes right from the source code
An easy first reaction might be: Of course our style guide is “living”, we aren’t setting out to build a dead style guide. But I think it’s an interesting distinction to make. Style guides can sit in your development process in different places, as I wrote a few years back.
It’s all to easy to make a style guide that sits on the sidelines or is “the exhaust” of the process. It’s different entirely to place your style guide smack in the middle of a development workflow and not allow any sidestepping.
Lastly, Punit Web rounds up some very recently published style guides, in case you’re particularly interested in fresh ones you perhaps haven’t seen before.
My point would be that the style guide has to be written down by the design team. The spirit of things, and what they actually look like.
Then the development team may build a kind of copy of this style guide showing the actual implementation and may be explain how to achieve this or that component.
The issue I see with a “living styles guide” (some guide that gets updated automatically as soon as you add a definition in your code) is that if you create a style that doesn’t respect any prior constraint, it becomes part of the style guide anyway. A broken rule becomes a rule.
Coming from a design point of view, when I’ve often been the UX Team of One, and speaking as someone who knows more CSS than usual, but is adamantly not a front-end coder:
There are wonderful component library tools out there (Fractal comes to mind), but most of them are developer-centric. To get them running, you need to understand Node, and build toolchains, and task runners, and JSDoc, and/or Git, etc. It becomes a barrier when everyone can’t contribute.
For instance, there aren’t many CMS themes that are suitable for creating style and component documentation using popular tools like WordPress. (If there was a CodePen custom field plugin maybe?)
There are a handful of designer-oriented SaaS tools for creating online style guides, like Frontify, but most fall down when handling live code previews (CSS was leaky, at least when I tried it).
And, of course, there are few to no really good WYSIWYG tools for web prototyping or style generation. (Waiting to see if Invision Studio will be the holy grail it promises to be).
Ideally, a designer + coder would work as a pair team to put it together – but more often than we admit, non-coding designers are in their own silo, generating lots of static comps and Google Docs which, as we all know, go out of date nearly immediately, which is a waste of time if they could be prototyping and contributing style docs to a common tool.
So…if style guides / component libraries are to be truly embraced, they need to be both designer and developer friendly.
I would say a good compromise is to have a “vanilla” canonical version of a component in plain HTML/CSS/JS as a visual and interaction design reference, alongside code adapted for one or more frameworks… otherwise you might need to build your tool in the framework you’re using to get the component to render properly.
And what happens when you need to port those styles to a different framework (say, when your company acquires a complementary product, or you’re customizing a front-end for a client, etc?)