Guide
What should go into a design system?
What should go into a design system? More than most teams think. Components and design tokens, yes, but also tone of voice, the icon and photo libraries, research, documentation and the brand rules your print team uses. My rule of thumb: if two departments could end up making the same thing twice, it belongs in the design system.
This one started with my Faster Horses co-host Nick Tomlinson. He'd been asked to explain design systems to his product team, so he went back to a talk by Brad Frost, the author of Atomic Design. As Nick heard it, Brad's view was that tone of voice sits outside a design system, because design systems are about building interactive things. Nick disagreed. So did I, and so did our other co-host, Mark Sutcliffe. Three UX designers agreeing on something is rare enough that we got an episode out of it.
Should you argue about atoms and molecules?
No. I like atomic design as a way of organising things, but I've watched teams lose whole meetings to whether a button is an atom or a molecule. It has a shape, a label, several states and sometimes an icon. Is that a molecule now? Does it matter?
Nick put it well: atomic design is a framework to help you think about structure, not an exam with right answers. Mark's version is a sliding scale. The smallest parts, such as containers, labels and icons, have no behaviour of their own. As you move up the scale, things become more about behaviour, until you reach patterns like filters or forms that are defined by what they let people do. Use the model to make sense of things, and drop it when it gets in the way.
Does tone of voice belong in a design system?
Yes. I add a "core" layer that sits beneath the atoms, molecules and organisms. It holds the things everything else depends on: tone of voice, colour and typography.
If your website speaks one way, your app another and your customer portal a third, customers notice, even if they can't say what's wrong. It's like one department speaking French and the next speaking Spanish. Your product team and your marketing team might quite rightly use different tones, and that's fine. Document both, side by side, in the same place, so everyone can see where they differ and why.
Nick also asked whether a digital design system needs the CMYK colour values for print. If marketing uses them, yes. One place for all of it beats three places that slowly drift apart.
How do you make the business case?
With maths. This is how I've sold design systems to every company I've worked with, because they save money.
Start with icons. Run an audit across a large business and you'll often find 50 or 60 icons that do exactly the same job, each drawn separately by a different team. If each one took an hour, at around £60 an hour, that's £3,000 spent on one icon. Multiply that across your whole library.
Then photos. How long does it take to find the perfect stock photo? An hour, if you're lucky. If five designers in five departments each do that for the same kind of image, you've lost most of a day. A shared photo library fixes that.
Then accessibility. Mark's formula is the one I'd steal first. If an inaccessible component costs someone five seconds, and they hit it 40 times a day, and 2,000 people use it, that's over 110 hours of your customers' time lost every day. Put an hourly rate next to that figure and it usually ends the debate.
What are the main parts of a design system?
Mark took a diagram I use to explain design systems and added to it. His version has five parts:
- Design kit: what designers use to build screens and components, usually in Figma
- Component library: the coded components your developers build
- Developer sandbox: where developers build and test, owned by your UI developers
- Research repository: run by your researchers, but open to everyone who needs it
- Documentation: the glue across all of it, and the hardest part to get right
Around those sits your design language, the overall look and feel, and around that sits your UX strategy, which decides how all of it gets used.
Where should your design system live?
Wherever everyone in the business can already get to it. I call it the lowest common denominator. Figma is great for designers, but plenty of people don't know how to find the pages in the left-hand panel, let alone find their way around a component library.
At one company I used SharePoint as the front door, because everyone had access to it. That gave people a two-minute introduction, then linked to Confluence for the detail, which in turn linked out to everything else. For quick answers I put a small wiki inside Microsoft Teams, because that's where people spent their whole day.
Nick has a test I love: if an accountant followed a link to your design system, would the page make sense to them? If not, simplify it. Mark's model for the structure is a hub and spokes. People can arrive from anywhere, but every route leads back to the same centre.
A design system needs the same UX care as anything else we design. We'd test a mobile screen with users, yet most teams throw their design system documentation together and expect people to read it.
Is a design system a product?
That question took over the end of the episode, so we gave it an episode and an article of its own. The short version: yes, and you should run it like one.
Need a hand with yours?
At Designed for Humans I run design system audits that find the duplication, the accessibility gaps and the handover arguments, and turn them into a prioritised plan. If you want everything in one place, Design Systems for Humans gives you a design system hub with principles, tone of voice, colours, components and separate views for designers and engineers.
See how we can work together, or listen to the full episode, S4E10 of Faster Horses, on Spotify or Apple Podcasts.