Zalando’s Design System Contribution Model
Creative technologist, Leonardo Lanzinger, and product designer, Madeline Rogier, describe the process of maintaining and evolving a design system.
How do we scale a design system at a company with over 20 million active customers and a team of hundreds of developers and designers? How are all of the components managed?
It’s definitely a lot to juggle and there’s a lot of trial and error in the beginning. A design system is not just a pattern library or a set of design guidelines, but rather a full product that requires both the focus of a central team and contributions from distributed feature teams. This article focuses on how our design system contribution model ensures that our design system has all the components and styles that teams at Zalando need to deliver their features. We hope to provide some tips to other folks working on this topic, and will share some of the insights that we learned along the way.
Curious what a design system is and why you need one? Then we suggest reading this UX Collective article on Medium. And if you’d like to know how our design system is structured, we use Atomic Design. For how to build a contribution model, read on…
Why should more people contribute to the design system?
Our contribution model allows feature teams to add new components or new styles based on their product requirements. At the same time, as the contribution model provides a central place to manage changes in the design system, we are able to keep an eye on the quality and consistency of the user experience. It also comes with the benefit of sharing the effort of evolving the design system across the many teams who are using it.
What does the contribution model look like?
Feature teams at Zalando are organised around specific segments of the customer journey. They are fully fledged teams that include dedicated designers who focus their work on specific customer problems.
The Zalando Design System, however, is mainly maintained by a centralised team called (you guessed it!) ZDS. This team’s main goal is to help feature team designers to deliver engaging and delightful experiences to our customers by providing them with the right set of components and styles.
When the feature team designers start designing a new feature, they may come across a component or UX pattern that isn’t defined in the Zalando Design System. When that happens, they will reach out to the ZDS team to make a contribution.
Our contribution process follows this schema:
Contribution proposal
As soon as a team identifies the need for a change in the design system, they are encouraged to submit a contribution ticket using a simple Google Form. This ticket helps the ZDS team understand the problem, the stakeholders involved, and the expectations of the contributors.
To facilitate this process, we group contributions into three main use cases:
1. Light: when making a small design tweak to existing components
2. Medium: when making a bigger change to an existing component
3. Heavy: when creating a brand new component
In order to determine the contribution weight, we ask our contributors to check this decision tree:
When the ticket gets submitted, it automatically syncs to our GitHub board where we keep all contributions: this is how we keep track of what is ongoing. The ZDS team then meets once a week to groom contribution tickets and to provide updates.
#learnings:
- Keep the process quick and easy, ask only for the information you really need. Help contributors help themselves by explaining the process beforehand and what is expected from them.
- Always note down communications on the GitHub ticket, so it’s easy to recap what happened. Anyone can check in on progress and understand the decisions made.
Kick-off
For medium and heavy contributions, we schedule a kick-off meeting with the team who submitted the ticket. During this meeting we agree on the scope of contribution, discuss the involvement from the teams, and confirm timelines.
#learning:
- It’s important to understand the problem space and make sure to involve the right stakeholders. This not only ensures that the process runs as smoothly as possible but ultimately delivers the right solution for the customer.
Collaboration
Once the contribution kicks off, it will either be driven by the ZDS team itself or by the contributing team. During this phase, designers and developers will go through design iteration until reaching a result they’re satisfied with and then move on to implement the new patterns in the design system codebase.
Everyone collaborates differently and everyone has their own ways of working, but there are a few things that go a long way when collaborating together:
- Buddy up developers and designers to avoid tech debt down the implementation line.
- Speak a common language and use a consistent naming in design and developer documentation.
- Have a design sign-off checklist that includes accessibility.
- Document all communication (even when face to face) on the GitHub contribution ticket, to keep stakeholders up to date and the process transparent.
#learning:
- Feature teams designers are the experts in their team domain, so have design system designers pair up with them when designing for specific requirements.
Review
When reviewing a design proposal, one thing that has drastically enhanced our work is ZDS hosting what we call, Open House. This is essentially open office hours three times a week. It’s a 30-minute, face-to-face meeting and the sessions can include anyone. It’s best to make sure the right people are in the meeting and to leave with action items and a conclusion. For example, if the question is about accessibility, make sure your accessibility expert is in the meeting.
#learning:
- Have a dedicated note-taker. Doing this allows for continuous, uninterrupted conversation and documentation.
Publication (and communication)
Merge the contribution Pull Request and you’re done! Just kidding. There still are a few very important things that need to be done. For instance:
- Update the design system documentation portal and design files to make sure that everyone uses the latest documentation and design assets when designing new features.
- Showcase the contribution changes during the design system weekly demo.
- Communicate with the contribution stakeholders to inform them about the successful outcome of the contribution and to celebrate the effort.
- Send out an email newsletter to inform the broader audience about changes in the design system.
#learning:
- Your design system audience can be diverse, so remember to tailor the communication for both the design and the developer audience: for example by including a technical changelog so developers know what to expect when updating the design system library version, or by providing a link to both the design and the developer documentation pages.
The benefit of a design system’s shared ownership
By treating the design system as a product and sharing ownership across teams, we enabled our team to design and build new features faster. Give it a try and see how it works for your team!
Creative technologist, Leonardo Lanzinger, and product designer, Madeline Rogier, work in Zalando’s Product Design team. Want to be part of our design community? Check out our open positions and meet the team.
