Table of contents
In late 2023, Belka’s Sara Fazzini and Maria Sole Biondi interviewed designers, developers and managers at 27 companies in Europe and N-America to learn how they approach design systems. This article is the first in a series about what they learned. (Click here for more information.)
We’ve all heard the success stories: How a great design system helped make user experience more consistent, and speed up the delivery of new features.
We’ve also all seen examples of best practices and really advanced design system thinking, in the form of Google’s Material Design or Spotify’s Encore, for example.
But we rarely hear people talking about things that go wrong.
When we started our series of interviews with design teams in late 2023, one of the things that surprised us was how many of them had stories about things going wrong in the beginning, when they first started working on their design systems.
So many people told us they’d had to completely rethink their original ideas, after realizing that what they were building wasn’t working.
So what happened? We were curious to know.
If at first you don’t succeed…
So, what is it that makes you fail your first attempt at creating a design system?
In our interviews, we found roughly three different scenarios.
Scenario 1: Everything, everywhere, all at once
“We wanted to create something like [Google’s] Material Design.”
— UX designer from a high-growth scaleup
“We [started by building] a design system with many useless variants, creating more confusion than ever.”
— Design lead from a high-growth scaleup
A “design system project” can mean many different things, depending on the size of the company, the maturity of the team, as well as the age and complexity of the product.
Each design system has its own particular backstory, but in our interviews we noticed a pattern: Very often, the first attempt to create a design system was a bottom-up initiative, starting with someone from the product team, who was curious or even passionate about design systems.
The scene: A lone hero or a small team of enthusiasts, with a lot of enthusiasm, big ambitions and great expectations. Plans, a kanban, tasks, maybe even rituals to keep things going.
Driven by a mix of ambition and perfectionism, our heroes want to be as successful as the big companies, and to get there they want to jump straight to a complete design system for every possible device that includes design, development, marketing, sales, brand, and copy.
Plus a cool code name for the design system, and even merch to promote it.
But it doesn’t work.
Our heroes can’t stick to this plan, the project is too big, the design system is never a priority, and without a dedicated team the project won't happen. In the long run you feel like giving up.
This frustration is the biggest symptom of failure.
Why does this happen?
The root cause is simply too much ambition, or premature optimization:
- When you think of design systems, you’re thinking of those very advanced ones that the big companies have spent enormous time and money to develop. Think Spotify: a product that works on 45 platforms, and over 2,000 types of devices, worked on by hundreds of designers. If you’re starting a design system from scratch, this almost certainly doesn’t reflect the reality of your company and your product.
- You’re trying to think too far ahead, and plan for every single variant and component you’ll ever need, even far into the future, instead of focusing on the ones you need right now. You shortly find yourself managing a library with a huge number of variants that create even more confusion.
To summarize: What ends up happening is that you’re not working on what you really need, but on an idealized best possible result.
There is no link between your design system plan and your company priorities or product goals. You are most likely trying to create the perfect design system as an objective itself, but not as a tool to reach your actual objective.
Scenario 2: One team in the driver’s seat, the other in the back
“At some point we had a component on Figma, another component on Storybook, and another component in production.”
— UX designer from a high-growth scaleup
“Initially, we underestimated the time it would take to develop the components, and this complicated things a lot.”
— The design team at a growing startup
A design system isn’t just about design. It’s about how designers and developers collaborate. If this isn’t the case, you’ve got a problem.
In this 2nd scenario, you’ve managed to create a library of components, but you don’t have a design system yet: the design and development libraries are not in sync.
The design component library may be progressing fast, but the development team is slow in building the code. You could even have a situation where design and development are using different libraries or only one of the two teams is actively involved in creating it.
Once this gap becomes evident there are often no clear ideas on how to deal with it and in a short time the project is abandoned.
The risk here is that you are not building your design system as a tool for the whole product team, but a tool primarily intended for your own team, which builds it in its own image and likeness. In this case you’re not really building a design system — you’re just building a design tool for yourself.
Why does this happen?
The problem in this scenario is that design and development aren’t communicating properly. Each is going their own way, and the results are not aligned and do not match.
One team is firmly in charge and taking the lead, while the other team is having to adapt to the needs of the first without having much input. And — surprise, surprise — nobody likes that.
Scenario 3: Just because you build it, doesn’t mean they’ll come
“We had no problems getting the leadership onboard with the idea of adopting a design system, but what really surprised us was the level of friction from the others in our teams. So you have to deal with that as soon as possible.”
— Team leader at a leading digital product
So, you’ve survived the 2nd scenario, but now you’ve got another problem: Adoption.
The team responsible for creating the design system may have successfully created the components in Figma and Storybook, but nobody is using them — or the majority of the team is using them inappropriately.
You’ve built the design system (the artifact), but you didn’t build the practice and the understanding of the artifact. Things are in sync, but only you and your only design system friend are using it.
It’s very lonely.
Why does this happen?
This scenario occurs in bigger teams where the users of the design system are not the people who have created it. Your small team of designers and developers is tasked with building the design system, and you start working on it without the rest of you teams buying-in, thinking that building a good DS will drive the adoption 🪄 automagically.
You underestimate partner buy-in, focusing on building the artifacts of a design system (foundation, components, documentation), but neglecting to build the rituals you need for the rest of the team to use your artifacts in the proper way.
Having the artifacts without the rituals is a guarantee of failure.
When the first attempt at building a design system fails, it’s due to focusing on the ideal instead of the real
Disclaimer: The kind of failures we’re talking about in this article aren’t necessarily bad. All of the people we talked to said that they’d learned something from the experience. You could even say that they made the mistakes so you won’t have to make them.
So what are our big takeaways?
When the first attempt at building a design system fails, it’s usually due to Idealism vs. Realism – focusing on the ideal instead of the real:
- You seek to build an idealized, perfect design system without connection to the realities of the actual, real-world product goals.
- You build an artifact for people to use, without considering the messy reality of how people work, and specifically how they work together.
So how did our interviewees overcome these teething problems?
We’ll be looking at that in a later article!
∗ ∗ ∗
This article is part of a series of articles about design systems practices in the real world, based on interviews with design and developers at 27 tech companies in Europe and N-America, conducted in late 2023.
Belka would like to thank all the great people we talked to at the following companies for their help with this project: Balsamiq, Buddyfit, Coverzen, DaVinci Salute, Docebo, Docsity, Doctolib, Fatture in Cloud (TeamSystem Group), Fiscozen, Generali, Immobiliare.it, indigo.ai, isendu, Jet HR, Klarna, Musixmatch, NeN, Nibol, 1Password, Scalapay, Serenis, ShippyPro, Subito, Switcho, Telepass, Tot, and TrueLayer.
Read more about the project here, and for even more, subscribe to Belka’s newsletter.
∗ ∗ ∗
Want more insights from our independent research?
- How to start a design system: let's talk about design audit!
- By the way, what's a design system and do you need one?
- A casa study: migrating Subito's design system
In the next episode: Why you shouldn't think too big when starting to build a design system?
Want a safe pair of hands to help with your own design system?
Check Design System Audit, our service to make sure your design system brings you results.
