Guide

Is a design system a product?

Is a design system a product? Yes: an internal one that helps your teams build faster, spend less and take fewer risks. Run it like one, with an owner, a roadmap, regular releases and a way of measuring whether it's working.

We ended our episode on what should go into a design system with my co-host Mark Sutcliffe asking this question, and it was too good to squeeze into the last five minutes. So it got its own episode, with Mark, our other co-host Nick Tomlinson and me. For the record, all three of us said yes. We spent the next hour explaining why.

Why don't more companies treat it as a product?

Mostly because it's hard to touch. Nobody argues that a CRM like Salesforce is a product. It keeps all your customers in one place and helps your sales team close deals, and you pay a monthly fee for it without blinking.

A design system does a similar job for design and engineering, but because it's built in-house and nobody buys it, it gets treated as a side project. Picture someone walking in with a made-up offer: a tool that cuts 10% off the cost of building every product, for £2,000 a month. Most businesses would bite their hand off. That's roughly what a good design system offers.

What does Jira have to do with it?

The question I like to ask product managers who doubt it is simple. Could you run an agile product team without Jira, Trello or something like them? Probably not well. Those are products that make your job possible. A design system is the same thing for design and engineering. It's a toolkit everyone uses, and the people who benefit most are your customers.

It helps to remember where the famous design systems came from. Apple's Human Interface Guidelines, and later its App Store rules, set the standard apps were expected to meet. Apple wanted to control quality, and it didn't want people walking into Apple Stores complaining about badly built apps that weren't Apple's fault. Google's Material Design made it quicker for developers to build Android apps for the Play Store, which Google takes a cut from. Both existed to make money.

How do you measure a design system?

Other departments have targets and metrics. UX often doesn't, which makes it easy to dismiss as "making things look nice". So give the business a number.

The one I use is the System Usability Scale (SUS). Think of it as an NPS for usability. Users answer ten standard questions about a product, you turn the answers into a score, and you repeat it every quarter or every six months. Because it's a standard scale, you can also benchmark against a competitor by running the same survey with people who use their product.

Two warnings. A low score isn't automatically a priority. We once looked at a product with frankly ugly UX, but it was doing its job, nobody was complaining and changing it would have annoyed more people than it helped. And who you ask changes the answer. Someone who's used Photoshop every day for ten years will score it very differently from someone opening it for the first time. Mark's suggestion is to split your scores by type of user and tie them to whatever the business cares about that year, such as onboarding new customers.

What does running it like a product look like?

Regular releases come first. Nick's main reason for wanting product status was release windows. Without them, a lovely new component ends up in one product out of four, and the inconsistency makes things worse than before. A set release cycle gets improvements everywhere at once. Not every release has to be exciting, either. Figma ships bug-fix releases all the time, and nobody makes a YouTube video about those.

Then lead time. Mark's aim is to know what components the product teams will need at least a quarter ahead. That gives designers time to research, design, build and test the new accordion before anyone needs it, so it's sitting in the library when the feature work starts.

It also needs an owner. In most companies that's the UX team, at least to start with. Nick worried about the tail wagging the dog, with product owners chasing component deadlines and good process going out of the window. That's a fair worry, and owning the design system yourself is how you keep control of what goes in and when.

Finally, tell people about it. If you build a great design system and don't tell anyone, nobody will use it.

Where do you start?

Small. Watch how your product team runs their products and copy the same rigour: their release process, their roadmaps, their language. If you speak their language, they'll get on board much faster, because they don't have to learn anything new.

Start with the foundations, like colour, type and spacing, run them through that process and see what happens. Then measure. When Mark's team ran a SUS study, the score came out higher than they expected, which was a nice surprise and a very useful slide.

Want to run your design system like a product?

At Designed for Humans I help teams set up the ownership, releases and measures that make a design system stick, and I can train your team to run it. Design Systems for Humans handles the product side for you: governance rules, health scores, a changelog and Figma and GitHub sync, so releases reach design and code together.

See how we can work together, or listen to the full episode, S4E11 of Faster Horses, on Spotify or Apple Podcasts.