The 4 Iterations of Personio’s Design System Governance Models
How we made the design system work for everyone.
Intro
Design systems exist to liberate teams from thinking about the user interface (UI) so they can concentrate on the user experience (UX). It’s an easy statement to make, but much more difficult to make it a reality — especially at scale. With the scale of business, more and more teams will interact with the design system, and its maintenance team can easily lose track of the needs of their customers. In this article, I’ll delve into why we believe the governance of the design system evolution should keep pace with the growth of the business, and share how we have been applying this mindset to our very own Personio design system.
The Big Picture
The design system at Personio is almost three years old, and throughout its life has gone through four iterations of its governance model:
- Centralized model: the Design System team defines rules and boundaries for the rest of the business
- Request-base model: the DS team gives the opportunity to its consumers to request changes or contribute them directly back to the DS.
- Council-based model: Other Personios can play a more active role in making design decisions
- Sandbox model: A fully federated and free-to-access governance model
Each iteration was designed for a specific scale context at Personio. Let’s dive deeper into the context of each of them and discuss the learnings in detail.
Iteration One: Centralized Model
Like many design systems out there, the initiation of the design system at Personio was also a grassroots movement. At the time, when the company was smaller, a few front-end engineers got together to initiate a shareable UI library based on their day-to-day requirements to solve the problem of unnecessary, inconsistent duplications. As a small scaled product development department, almost everyone used to work closely with each other in person and could spot the highly reusable elements of their work: buttons, form elements, et cetera.
The beginning of the project was easy: we had a UI library in Sketch and a fully functional set of React components in its repository. Both Sketch and React elements were fully published and ready to reuse in production. Unfortunately, those days didn’t last long! With the product’s growth, the organization, the teams, their size, and the complexity of their domains also grew. As a result, we ended up with subject matter expert teams loosely coupled with each other, the same for the Design System team.
At this stage, an inevitable lack of cross-domain awareness in the design system and its consumer teams became evident. We needed to address this quickly by reestablishing the missing awareness channel between teams, which kicked off our second iteration: the request-based model.
Iteration Two: Request-Based Model
Among many possible solutions, we thought that giving people a way to request a feature or contribute their suggestions directly would solve a big part of the problem. To implement the idea, we created a few processes: a form to submit the request, a definition of ready for the proposals, a training for our teammates on how to process them, and, most importantly, defining how to support contributions individually (e.g., design and code reviews) to make sure they met the DS quality bar.
After spreading the word constantly in the organization, we progressively found ourselves processing many requests and contributions within the team. It was really great to see everyone’s interest in the Design System, even if finding the balance between being creators and enablers was a tricky skill to learn.
However, the process had a severe flaw: when it came to reviews, we on the Design System team were deciding about the viability, vision alignment, and correctness of the proposals. We often found ourselves discussing internally on topics like if proposal X aligned with the design system visions, or if team Y should use an already existing component or pattern instead.
However, the Product teams are always the closest layers to the end users, and our own lack of end-user understanding made us a significant bottleneck in the organization. After doing a few user surveys and interviews, we noticed that our gut feelings were true, and other teams also felt that our point of view was not inclusive and informed enough regarding their areas of expertise.
Therefore, it was clear to us that a change was needed: bringing representatives of product teams into the decision-making process.
Iteration Three: Council-Based Model
The name “council” is one of the most misleading and sometimes funny terms we have ever introduced. The first image that comes to mind when we hear it is a secret group of super opinionated people in suit-n-tie who decide about the finest details of other teams’ designs. In reality, however, the idea was simple and accessible: a group of people representing a few product teams that brought their subject matter expertise and enabled us to make decisions in a more informed manner.
The new council members were chosen by rotation, meaning that at each phase the representatives of different teams were involved in making decisions. This approach was meant to enrich and diversify our point of view. The council was constituted to support the DS team in processing the feature or contribution requests, and to bring their domain knowledge to the table.
The public announcement of the new approach excited the teams, and the number of contributions started to increase again. However, not long after, the council itself got overloaded by requests to process, including a few that were so complex or too product-specific for us to make an objective decision on. The requests and contributions started to reduce again, andmany requests were still piled up in the backlog waiting to be processed. It was indeed a sign that we were a bottleneck again, and the results of the surveys and retrospectives proved it to us.
The survey results were primarily that the council was too strict and not well enough informed about each team’s context and the problems they were trying to solve. The results were bitter but true, and it was clear that the organization’s size, context variety, and problems were too big to be covered by a council of representatives. We needed to get out of the way of other teams and start learning from them instead of making decisions on their behalf..
Iteration Four: Sandbox Model
We took a step back to look at what we currently had: a design system with a UI library, and a reporting tool to count how many times teams adopted it. The UI library had an entire infrastructure around it: publishing both Figma and Web components to assets and NPM. So not only were its elements globally accessible, and everyone knew what was offered, but their usage was also monitorable.
And Personios loved having the opportunity to contribute components to the library themselves! They knew that if their components get published, they would not only help others avoid reinventing the wheel, but also contribute to increasing the consistency of the end product. We reflected deeply on those facts and realized that if we got out of their way, the teams would share and reuse their artifacts automatically!
Of course, without gatekeeping, the contributions could become too product-specific and have a lower overall quality. But, on the other hand, their solutions would be much more visible to the whole organization than if they were kept hidden in local places.
The solution was, therefore, already there: giving the teams the best of both worlds!
We duplicated the UI library and all its infrastructure and reporting tools, called it the “sandbox,” and gave everyone access to contribute to it and publish freely without any review from the Design System team. Such an idea brings not only publishing and visibility features to the table, but also liberates teams from uninformed decision makers.
Now, as a result, each time a Personio wants to create a new variant or element, they can take a look at this single place to see if someone else has already solved the problem. Also, thanks to the reporting tool that monitors the sandbox usage, we in the DS team will be able to prioritize the highly-used components and review them periodically. With each review, we will be able to assist teams in improving the quality of their solutions to make them highly reusable and, therefore, eligible to be a part of the central, official UI library.
Is this the very best solution possible? We’re still not sure! It’s a bleeding edge solution requiring many trials, feedback, and surveys. However, like any iteration at Personio, we seek excellence and know we’ll continue to learn and iterate along the way!
Sound like the type of team you’d like to join? We’re hiring! Head to our careers page to check out our open roles.
