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 fifth in a series about what they learned. (Click here for more information.)
In our design system interviews, we heard a lot a mysterious figure we'd never met before. Some called this figure the "guardian," others called it the "sheriff." We heard many different names, but the role was always the same: To enforce law and order in the design system.
We call it the Design System Police.
We were curious. Why did so many teams feel the need to establish a strict authority to vigilate over the design system? What problem are they trying to solve? And most important: Was it working?
So we started digging deeper.
.png)
A library alone won’t get you far
When building a design system, teams need to get their head around the concept of design system governance. This means understanding how to manage responsibility around the design system, how to ensure that it’s correctly maintained, and how to structure an effective contribution system.
Governance is a structural part of a design system, just as much as adoption — which I wrote about in my previous post. A component library won’t be of much use if the team doesn’t have a method to work around it.
A way out of chaos… or not?
Governance can be implemented in different ways, depending on how the team is structured, but one thing is for sure: it is hard work. Especially if you think about it too late.
Some teams get lost in the process of figuring out what works for them. They start to see chaos — an endless proliferation of components, detached instances, no clear understanding of who’s accountable for what — and they get stuck.
There only seems to be one way to keep things under control: centralising authority on the design system. This new set up is supposed to be temporary and let room for dialogue, but then the design system police is established and it ends up looking a lot like an authoritarian government.
And from this decision onward, things get dark.
The problem with the design system police
The design system police is the sole editor in the Figma file of the component library. It reviews every new component and variant proposed by product teams. It monitors every product design file to ensure components are used correctly. If they are not, it intervenes to indicate which ones to use and how.
This may sound like it’s not a big deal. After all, someone must be responsible for the design system, mustn’t they?
There’s only one problem with this approach.
That is, it creates an informational bottleneck. When the design system police is established, an officer will have to gatekeep every decision and give their stamp of approval on even the tiniest edit to ensure everything is always under control.
This is clearly not scalable, and it doesn’t allow for other people in the team to grow responsible for the way they use the deign system and learn how to do it properly. This way, the design system quickly becomes an obstacle to product growth rather than a facilitator.
Luckily there are other ways to go about design system governance.
How they did it: Klarna’s experience
To better understand this phenomenon we talked with Sabrina Copertini, Product Designer specialising in design systems at Klarna.
Klarna’s design system is quite complex, as one would imagine for a product serving 150 million users. A Core library includes all main components, while some minor libraries are used to collect task-specific ones — such as those used for handoff within design files. This way the design system can easily cater to different needs within the organisation. Getting there required a lot of collaboration and some rework. "The design system must be willing to evolve alongside the product and its needs. This sometimes means updating materials and even sacrificing some of the work done in the past.”
Everyone at their own pace
In tandem with the official libraries, product teams have autonomy in managing their own local ones. Local libraries contain all components that are yet to be validated by the design system team and are therefore not ready to be included in the Core library. This decentralisation stemmed from the necessity of empowering teams to self-manage and innovate at their own pace, avoiding for the design team to become a bottleneck in decision-making processes.
“As you can imagine, a team of eight people cannot manage all the demands coming from product teams. Instead of becoming a blocker we looked for an alternative, that’s how local libraries came about.”
— Sabrina Copertini, Product Designer, Klarna
This doesn’t mean the design system team has no ownership over the maintenance and growth of the design system, quite the contrary. “Obviously, we need to provide support, carry out checks, and validate the teams’ new explorations. However, we leave it up to specific product teams to manage it as they see fit, at the speed they believe is most in line with their needs.” With this setup, product teams enjoy the flexibility to design with the agility they need, while the design system team meticulously vets and validates components before integrating them in the Core library. This way only components meeting rigorous criteria for usability and durability pass the test.
Getting people onboard
Another important role the design system team has is to create space for confrontation, supervise the overall growth of the design system, and make everyone aware of new developments. “Collaboration is not optional, and it doesn’t just mean accepting any request that comes our way.” It means setting up communication channels to answer questions and announce new releases, organising workshops about the most complex components, and having dedicated Q&A sessions.
“The whole point is to maintain maximum transparency. The product teams are my clients, we work for them. If the design system doesn't meet their needs, friction arises, which means something isn't working on our side.”
— Sabrina Copertini, Product Designer, Klarna
Finally, Sabrina gave us her take on the delicate balance between having things under control and being ready to manage change. “The design system cannot be restrictive, we’re not the design police. We need to be open to dialogue in order to evolve the design system as needs evolve. This, for me, is truly the cornerstone of the work we do.”
.png)
Getting governance right
Building a healthy practice of design system governance may require some trial and errors. There’s no one-size-fits-all recipe for success — companies, like people, are all different — however, I’m here to share the most magical tips we got from our interviewees.
Someone to take care of things
First off, accountability is key. Both on the design and development side, meaning you’ll need a person from both teams to make this work. Accountability is about having someone who keeps things on track, making sure everyone does their part and things move in the right direction. But keep in mind, we’re not talking about being the design system police. What we need is a facilitator, not someone who's there to enforce rules, make all the decisions and handle the execution one-handed. This person will take care of enabling the success of the design system team.
Let them be a part of it
Then, you need to establish a contribution model that fosters continuous participation. Input should come from different directions — this includes product teams as well as the design system team itself, encompassing both designers and developers. Make sure all requests can be easily expressed, are correctly collected and processed. Define criteria you’ll apply to decide what qualifies to enter the design system and what you’ll do with whatever is left out.
”We’ve established an operational flow that encourages co-design, with designers directly involved. Each request is collected through dedicated Figma files, where designers input component details and specific requirements. We used a shared Excel sheet to track all ongoing requests, monitoring progress and any updates. This enables us to keep track of requests and ensure a smooth, transparent process.”
— Design Lead at a large fintech firm
Give them the tools
Finally, make sure the team has everything they need to integrate the design system in their daily practices. This can happen gradually or in one go, depending on product priorities. In any case, people need to be aware of changes made to the design system, be able to ask questions and receive answers promptly. Clear communication and support will ensure a smooth transition and autonomy, with no need for a the design system team to supervise every tiny step.
”When a component is ready, we release it as a beta version for testing. Designers can play with it and provide feedback. We also have a documentation website that everyone can access. Every new release or update is announced on our Slack channel, which can be used to leave feedback or ask questions on our work.”
— Design System Manager at a SaaS company
Building a shared practice
The need for a strict control over design system practices might be a signal of low team awareness and engagement.
While it might be tempting to centralise design system governance to feel everything is in place, truth is that long term sustainability requires something different.
That is a shared and well-understood practice of communication, contribution and accountability that encourages the whole team to take ownership and responsibility over design system maintenance.
∗ ∗ ∗
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?
- Why isn't anyone using your design system?
- How to convince management that a design system is good investment?
- Why you shouldn't think too big when starting to build a design system?
In the next episode:
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.
