Back to blog

The governance of a Design System

Thomas Huber

February 9, 2021

8 min of reading


We cannot say enough about the importance of a structure having a design system. It allows for perfectly ordered components, well thought out guidelines, complete documentation ... and ultimately a real time saver for the user team.

Overlord versus team

Years ago this design system could still be produced by one man, reigning supreme. If you couldn't find what you were looking for in the component library, you had to deal with it. He was the sole decision maker.

This organization is no longer relevant. Large structures now work with hundreds of digital designers who work on the web or native apps, the desktop, the customer or employee experience, and many other aspects.

Product managers are getting involved. They work as a team spread throughout the company and there is no longer any question of forcing them what to do. One thing is certain, the governance and the distribution of teams around a Design System will be structuring for its evolution.

There are several models (detailed by Nathan Curtis) but two of them seem to be the most common: centralized model and federative model.

Centralized model or federative model?

This is not to say that one model is better than the other. It will - in fact - be chosen according to the organization of the structure and the time that can be allocated by each.

In a centralized model, a dedicated team manages the system and makes it evolve. This team must be in close contact with the other teams in order to be sure to cover all the needs and to be close to their daily problems.

The other teams will be able to make proposals for new components or new patterns, but the final choice of whether or not to integrate them into the System will always be up to the central team. Whether the team is entirely internal or includes a team of consultants (agency sytem designers at the origin of the project, for example), it is essential that the decision chain is transparent and that the teams' involvement is complete. A tool that is not carried internally but imposed has little chance of becoming sustainable.

The advantages of this model are twofold:

  • a lighter allocation of company resources (man and time)
  • a more easily controlled consistency of the elements of the Design System

In a federative model, members of several teams are in charge of and contribute to the system. Adoption is often easier but you need guarantors who have a transversal vision of the system in order to maintain overall consistency and who remain available. It is also possible to test a combination of models. Salesforce, for example, has a central team dedicated to the “Lighting” system that relies on contributors across the organization, while Google design has opted for the federative solution. A small - and now growing - group of designers form what has become Material Design using an experiential committee approach. These committees are made up of designers and decision makers appointed to collaborate on the system for a set period of time.

They collectively make decisions, build and communicate via a medium of their choice (and this choice is wide).

Be careful not everyone participates or has the opportunity to express themselves. The group communicates its decisions to other production teams which improve their results or ignore them at their own risk.

There are many interests in forming such a team:

  • increasing the relevance of numerous platforms and production
  • limiting bias by representing many different
  • facilitate the circulation of the system between the teams by multiplying the number of “evangelists”

On the other hand, this option requires a lot of work and rigor.

Moreover, the designer who participates in this model must be able to transcend in a way convincing service issues for the sake of the most coherent user journey.

Finally, a federative model like this also entails a real challenge at the decision-making level. Discussions will inevitably arise on a point of design when the decisions will be communicated. The team must then balance the need for decision-making and project progress with breaks where the degree of involvement will be greater in order to meet everyone's need to give their opinion.

How do you form a team that will know how to stay consistent with the designed design system?

There are many dimensions to take into account when building such a team. This includes: Who is available? For how long ? When is the design system due to be completed? Who has the skills to identify and build the essential elements? But whatever the organizational model chosen, the roles to be taken on from the start are:

  • Designers (Product Designers and specialized profiles)
  • Developers
  • One or more Product Managers
  • Other users of the assets (e.g. marketing, communication, etc.)
  • A sponsor supporting the initiative (essential to find and motivate the dormant talents of the company)

It may be relevant to appoint a Design System manager, head of orchestra of its creation and its maintenance, which will know how to evangelize on its interest within the organization.

The governance process

Beyond the allocation of resources dedicated to the Design System, the establishment of governance is essential to ensure that the system can adapt to changes.

So, you have to start by answering some questions about how to manage changes: who validates the changes made to the system? What happens when bugs or regressions are found? How are requests for new components handled? Indeed, if users do not find what they are looking for in the Design System, it risks being quickly obsolete and therefore abandoned.

This is the challenge of the implementation by system designers of a process extremely clear and comprehensive governance. It should allow users to know exactly what to do in cases where - among other things - they cannot find the component suited to their needs, or if they have questions about the design system. large organizations, international or not, which have a multiplicity of locations, subsidiaries, products, teams.

Brad Frost, for example, has created a map describing the governance process for its clients. It is finally presented as an improved logiform where each case is studied and a solution provided. The job of the production team is to design new products.

Until now, nothing new. Ideally, they will find in the design system the component they need and which meets all their requirements. This is the famous time saver mentioned above.

Snowflake or Design System

But not everything always turns out ideally. If the team is not happy, the first step will be a discussion between the product team and the design system team.

This exchange will help to better understand the needs and perhaps guide the production team towards an existing solution that she had not seen at first glance and that meets needs and requirements.

If this is not the case, a fundamental question must be asked: is this need punctual and useful for a specific product (snowflake) or, on the contrary, is it an element to be added to the Design System because it is valid? and can be used for all products (a navigation element for example).

In the first case, the element must be added to the product backlog while of course respecting the principles laid down in the Design System. Then the product team will take care of it.

The corollary will of course be the obligation to create such principles within the Design System to allow simple and rapid management of these specific components. In the second case, if the teams have come to the conclusion that the new element should be an integral part of the Design System, the Design System Backlog will be implemented.

Determining who will be in charge of working on this component will depend on several factors including urgency, importance and the resources available. to meet all requirements. The new component will be added and the API code and documentation will also be finalized.


In addition to this aspect of a new component to be created, the design system will have to undergo regular updates anyway.

Here again the design team will have to determine the best channel to inform about these updates, but also detail how to manage them. possible bugs.

Each governance process can be different and must be adapted to the organization to which it is dedicated. The focus can be on quality, prioritizing feedback from developers, etc.

Ultimately, the main points to remember are the following:

  • the obligation to create a sustainable and involved governance
  • the mix in this team of doers and decision-makers
  • the drafting of a guideline made available to all users who use them

Sources : 

articles de Nathan Curtis

articles de Brad Frost

articles de Audrey Hack

blog de Virginie Coux

You may be interesed by