Design System governance, between centralized and federative models

We can't emphasize enough the benefits of having a design system. It means perfectly ordered components, well thought-out guidelines, complete documentation... and, ultimately, real time savings for the user team.

Overlord versus team

Years ago, a 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 make do. He was the sole decision-maker.

This organization is no longer relevant.

The big structures now work with hundreds of designers who work on the websitesnative applications, business tools, thecustomer experience or employee experience, and many other aspects.

Product managers get their hands dirty. They work in teams spread throughout the company, and there's no longer any question of them being told what to do. 

One thing is certain: the governance and distribution of teams around a Design System will be crucial to its evolution.

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

Centralized or federative model?

This is not to say that one model is better than the other. The choice will - in fact - depend on the organization of the structure and the time that can be allocated by each person.

In a centralized model, a dedicated team manages the system and keeps it evolving. This team needs to be in close contact with the other teams, to ensure that all needs are covered, and to be close to their day-to-day issues. 

‍

Other teams can make proposals for new components or patterns, but the final decision on whether or not to integrate them into the system will always rest with the core team. 

Whether the team is entirely in-house or includes a team of consultants (agency designers at the origin of the project, for example), it's vital that the decision-making chain is transparent and that team involvement is complete. A tool that is not supported internally, but rather imposed, has little chance of becoming sustainable. 

The advantages of this model are twofold: 

• a lighter allocation of company resources (manpower and time);
• more easily controlled consistency of Design System elements. 

‍

In a federative model, members of several teams are in charge of the system and contribute to it. Adoption is often easier, but you need guarantors who have a transverse vision of the system to maintain overall coherence, and who remain available. 

It is also possible to test a combination of models. Salesforce, for example, has dedicated a central team to the "Lighting" system, supported by contributors throughout the organization.

Google design opted for the federative solution. A small - and growing - group of designers formed what became Material Design, using a committee-by-experience approach.

These committees are made up of designers and decision-makers appointed to collaborate on the system for a given period of time.

‍

‍

They make decisions collectively, building and communicating via a medium of their choice (and the choice is wide).

Note that not everyone participates or has the opportunity to express themselves. The group communicates its decisions to the other production teams, who either improve their results or ignore them at their peril.

There are many advantages to putting together such a team: 

• increase the relevance of numerous platforms and production lines
• limit bias by representing many different points of view
• facilitate circulation of the system between teams by multiplying the number of "evangelists".

‍

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

In addition, the designers and developers who participate in this model must be able to transcend service issues in a convincing manner for the benefit of the user journey path.

Finally, a federative model like this also brings with it a real challenge when it comes to decision-making. Discussions will inevitably arise on a design point when decisions are communicated. The team must balance the need for decision-making and project progress with breaks where the degree of involvement will be greater, to meet everyone's need to have their say.

‍

How do you put together a team that is consistent with the design system? 

There are many dimensions to consider when building such a team. These include: Who is available? For how long? When is the design system due for completion? Who has the skills to identify and build the essential elements?

But whatever the organizational model chosen, the roles to be taken on board from the outset are :

• Designers (Product Designers and specialized profiles),
• Developers,
• one or more Product Managers,
• other asset users (e.g. marketing, communications, etc.),
• a sponsor to support the initiative (essential for unearthing and motivating the company's dormant talent).

It may be a good idea to appoint a Design System manager to oversee the creation and maintenance of the system, and to evangelize its value to the organization. 

‍

The governance process

As well as allocating dedicated resources to the Design System, governance is essential to ensure that the system can adapt to change. 

So the first step is to answer some questions about how to manage changes: who validates modifications to the system? What happens when bugs or regressions are detected? How are requests for new components handled? 

Indeed, if users don't find what they're looking for in the Design System, it's likely to quickly become obsolete and thus abandoned.

This is why it's so important for teams to set up an extremely clear and comprehensive governance process. It must enable users to know exactly what to do if - among other things - they can't find the right component for their needs, or if they have questions about the design system.

The problem is all the more acute for large organizations, whether international or not, with multiple locations, subsidiaries, products and teams.

Brad Frost, for example, has created a governance process map for his customers. In the end, it looks like an improved logiform, where each case is studied and a solution found.

The job of the production team is to design new products. So far, nothing new. Ideally, they'll find in the design system the component they need to meet all their requirements. This is the famous time-saver mentioned above.