Distilling How We Think About Design Systems
Have you all heard of this cool new thing called design systems? They’re popping up everywhere. They’re not really new, but more of a distillation of a lot of things we’ve been starting to do for a long time now. They help us with creating consistency, productivity, and creating better user experiences. Companies are quickly getting behind the benefits that they can bring your teams.
But, design systems have a marketing problem. There are so many terms and definitions being thrown around that it makes it really hard for newcomers and experts alike to get the crux of the problems we are solving.
Focusing on vocabulary creates tribal knowledge and cognitive debt for newcomers. If every time someone joins your team or adopts your system you have the same conversation about why a design system is not the styleguide but what’s the pattern library and are components the same as modules but aren’t design tokens just variables, then we’re using up valuable time. We can make this less confusing.
I’m going to attempt to bring some clarity to what can seem like a jumble of new terms by introducing the model of how I think of a design system.
We are really confused about what a design system is
Ask a hundred people what a design system is and you’re bound to get a hundred different answers. Here’s a collection of a few graphics I’ve picked up from around the internet that attempt to explain it:
And just a few articles…
I could go on.
I don’t know about you all, but I find that all to be just a little overwhelming. A lot of those terms kind of sound the same, and each chart uses them a little differently. We’re splitting hairs. When you bring a visualization out like this in a presentation to sell people on a design system, they’re just as likely to be impressed by its complexity as they are to be confused by what you are trying to say. I wouldn’t expect for someone to look at that and understand how a design system can benefit their organization or team.
We can start to distill all of these terms into something more digestible by exploring product vs operations.
Are design systems a product?
Design systems expert (guru?) Nathan Curtis put out this excellent article encouraging teams to think of Design Systems as a product because it helps drive home the fact that it must be a continuous process with constant resourcing. I agree with almost everything he is saying, but I wonder about the effectiveness of calling all of the processes that go into a design system a “product.” It seems a bit ambiguous to me.
Operations vs Product
Let’s talk about one of my favorite things: whiskey. Imagine for a second that you had just gotten a bottle of something really good, like a limited edition of The Macallan. What’s the product here?
It’s the whiskey, right?
But what is it that makes that whiskey so good? You might say it’s the quality of the water, the barley, the wood it was aged in. What else? Was it the time that it was aged, the skill of the master distiller? Did it taste better because of the occasion that you were drinking for? Or maybe the fact that you knew it was expensive?
The resources (like the soil and master distiller), and the operations (like the aging and distillation process) physically create an excellent whiskey. The emotion that the Macallan evokes in the consumer creates the experience.
Resources + Operations outputs Product
Product + Emotion creates Experience
Of course, you can argue that the whole experience is the product and you’d be perfectly justified in doing so. However, if we revisit the question above, and asked someone holding a bottle of Macallan what the product they bought was, I doubt they would say something like “the entire Macallan experience.” Maybe I’m wrong, but I think the common understanding is that the product is what is consumed. I think using a more literal definition helps create more clarity.
Elements of Success
So let’s get back to design systems. What’s the product? Here’s my perspective:
The product is what users consume. The documentation (commonly called the styleguide), the UI kit, the code, etc. The product is the tangible parts.
The experience is how it makes them feel. Do your users like using your system? Or does it feel cumbersome and block their creativity?
The operations are how it’s made. And execution is the act of making it. What’s your testing process? How are assets stored and distributed? How do users learn about the system or get support?
All of these things make or break a design system’s success. However, they can all be flexible. Say you’re open sourcing your design system and you expect third parties to be able to adopt your system. You have to also accept that while they will be using your product, their experience and operations may be different. While releasing bi-weekly and creating a Slack support bot may work great for your team, another team might not work best that way. So are they no longer using your design system if they don’t follow your process? Well, it depends on how you choose to define “design system”.
So then, what’s a design system?
So what’s the design system? If we go by this model, we have several options. It’s either:
The Design System is a Methodology — like how the Agile Manifesto transformed the development process, a design system is the methods by which you design products.
OR
The Design System is the Product — the tangible bits. And like any great product, it requires a great process to make it successful. Your documentation, your UI kit, your code repositories are your design system. And your design system operations are what makes it work.
Let’s look at this visually.
Personally, I lean towards the second definition. I think it provides more clarity to separate the design system vs. the design system ops. As long as we stress that we need excellent resources and operations, then I find it makes more sense for me to think of the end product as the design system.
They are both totally viable definitions though, and a lot of people use the left model. But I wouldn’t call the whole outer box on the left a “product” if you’re using that model. I think it’s confusing.
Takeaways
Here are some principles I like to go by:
If you can avoid being ambiguous, please do. It helps everyone get on the same page, more quickly. If there’s an abstract or ambiguous interpretation of a term, use the literal one. (e.g. product = tangible)
Favor common understanding over dictionary correctness. Be flexible with your vocabulary. If you decide to call something an “element” but everyone is naturally referring to it as a “component,” embrace that.
Make great operations a priority. A design system is nothing if your team can’t use it well or it takes more energy to execute than productivity gained.
Don’t get trapped in defining things instead of explaining things. For example, I recently had a conversation with someone about how they thought “consistency” is bad but “cohesiveness” is good. They thought that consistency had to mean that everything is the same and cohesiveness meant everything made sense, but could be different. For our team, we’ve been using the word “consistency” and we’ve also made a point to show that consistency doesn’t mean using the exact same elements everywhere. For us, it means that the experience is familiar and makes sense, regardless of the user’s context. We don’t need to champion new vocabulary to get our point across that a mobile menu shouldn’t be used on desktop.
I don’t really want to read any more articles about the difference between a pattern library and a styleguide. I think there are more interesting problems to solve. I don’t want to have another religious conversation about why I shouldn’t call the styleguide the design system, because I choose to think of product output as the design system.
I think as a community we’re starting to get a bit dogmatic about what design systems are and are not. I want to stress that all of this is just personal opinion and whatever works for your team is the right answer. I want newcomers to feel welcome and to help make design systems accessible to everyone, because I ❤ design systems.
Thanks for making it this far! I would love to hear your thoughts and perspectives.
