how to make it actually work
A multi-product design system should ensure consistency across all of a company's products, as well as speed up and reduce the cost of their development. However, in real life, we see something different: multi-product design systems only partially perform their functions and, in addition to their advantages, have a number of significant disadvantages.
The main disadvantage is the inability to satisfy all the needs of all products (especially when it comes to dozens and hundreds), which inevitably results in forks, proprietary developments and other discrepancies that gradually move products away from a single design system.
So, it turns out that multi-product design systems work, but with big caveats. Can they be made to work better?
My name is Anastasia Kabalkina, I am the head of design for the FinOps department at VK Tech. In this article, we will analyze the problems of multi-product design systems and try to solve them with a small revision of the architecture. And if not solve them, then at least minimize them 🙂
Five Problems with Multi-Product Design Systems
Problem one: “There are many of you, but I am alone,” or the impossibility of meeting the needs of different products with one design system
This problem lies in the very idea that there should be one design system for everyone.
If a company has many products that differ significantly from each other in their purpose, functionality and positioning (and this is usually the case), then the design system is simply physically incapable of satisfying the needs of all products and fully providing them with uniform UX/UI patterns, fonts, icons, styles, components and so on.
It is impossible to keep everything in one design system, so it includes the most basic (general methodological recommendations on visual language and editorial policy, grids, typography, basic palette, design tokens, atomic and molecular level components, etc.), and the rest is left to individual products.
As a result, the product develops its own UX/UI patterns, organism-level components and screen templates, and even entire functional modules.
At the same time, if we develop the idea of saving design and development resources, then truly tangible savings begin at the moment of reusing large entities of design and code – organisms and templates for which a single design system, as a rule, is not responsible or is responsible only to a very limited extent.
Problem two: inefficiency of processes for working with components
The standard process for processing a request to create a new component or improve an old one seems complex and inefficient. But the worst thing is that it does not always result in the inclusion of the component into a single design system.
If the design system has a contributing process (inner-source development), then the product that needs the component develops/modifies it itself directly into the design system.
Contributing is more effective than developing/refining a component by the design system team, but if we are talking about a component that is used in dozens or hundreds of products, then the risks that the requirements for its functionality from different products will be contradictory, and the component will become too “sprawling”, increase greatly.
Problem three: a permanent increase in the workload of the design system team
If there are many products, the flow of requests to the design system team at some point becomes unbearable. It becomes increasingly difficult for products to wait for a response from the design system and communicate with its team, and an ever-increasing budget is required to expand the team itself and support its work.
Problem 4: Loss of product expertise at the design system level
A multi-product design system and the team behind such a design system do not have expertise in each of the company's products, because it is physically impossible to cover all the product nuances, especially if the number of products is in the tens and hundreds.
At the same time, product expertise is extremely important: often the appearance and functionality of a component are determined purely by product requirements.
Problem 5: It is difficult, expensive and painful to implement a multi-product design system in companies with a developed product line
Typically, the decision to create a unified design system is made when a company already has several developed products and needs to ensure their consistency and speed up development.
Transferring an existing product to a new design system is associated with a number of serious challenges: breaking changes, supporting two solutions, lengthy refactoring, possibly changing the approach to writing styles and the stack of technologies used.
If, by the time the decision is made to switch to a new design system, the product already had its own design system or a UI Kit implemented in the code, then in addition to the above, the product faces the loss of its developments and a decrease in efficiency. In essence, the product temporarily loses the efficiency of development, in order to later restore it to the previous level, but using a new design system.
It should also be noted that creating a unified design system for an existing product line is a non-trivial task, and the more products there are, the more non-trivial the task. It takes a lot of resources to analyze current patterns, styles, and components, find common areas and differences, agree with all products, bring them to a common denominator, and survive many years of refactoring until the moment of complete replacement of components. And even successful completion of these processes will still not eliminate the first four problems.
Hierarchical design system
The solution (or at least minimization) of the problems listed above is to change the architecture of the multi-product design system to a hierarchical one.
The first level is subsidiary design systems (DDS)
At the level of child design systems, several regular design systems are placed.
Child design systems differ significantly from each other in the set and/or functionality of components, in the subject matter of products, in the stack of technologies used, and in any other parameters or set of parameters. For example, child design systems may include design systems for:
B2B products;
B2C products;
products of a separate thematic line – for example, financial products, social networks;
products with native components;
websites/landing pages, etc.
There should not be many child design systems, but there should be enough of them so that each child design system fully covers the needs of the products related to it.
A child design system, in addition to simple components, can contain organism- and template-level components, standard interfaces, and also be responsible for its own UX/UI patterns, standard entities (notification texts, errors, etc.) and other elements depending on the thematic and technical features of the product line for which it is intended.
The second level is the meta level (parent design system)
The meta-level of the hierarchical design system contains everything that is common to all subsidiary design systems: a unified system of tokens, fonts, methodology and principles of functioning of subsidiary design systems, approaches to optimization, systematization, typification of various entities, requirements for accessibility, adaptability, principles of layout in design and on the frontend, principles of interaction between design and frontend development, approaches to documentation, automation, etc.
The meta-level may also contain components that are truly common to all child design systems, if any (mostly these are components at the atomic and molecular level).
Managing a Hierarchical Design System
The management structure is determined by the structure of the design system itself and includes three levels: the meta-level, the level of the subsidiary design system, and the product level.
Meta level (parent design system level)
The meta-level of management is the people responsible for key areas of design and development within a hierarchical design system. A rough structure might look like this:
leader in brand, visual language and communication;
Design and UX leader;
research leader;
leader in development, testing and automation;
leader in the ideology and principles of building and operating a design system.
In addition to the roles listed above, a collective management body can be created at the meta-level – a committee that includes both leaders of key areas and leading representatives of subsidiary design systems (designers, developers, testers) – to resolve issues related to the exchange of information and experience between products, as well as the development, testing and movement of components between levels of the design system.
Child Design System Level
At the level of the subsidiary design system, the roles of lead designer, lead developer, and tester are distinguished.
These roles are key, since it is at the level of the subsidiary design system that the main operational work takes place: design and implementation of components, templates and standard interfaces, formation and reuse of product UX/UI patterns, as well as organization of interaction and exchange of information with the meta-level of the design system.
Individual product level
At the product level, there may be roles of lead product designer, lead product developer, and tester (if there is a production need for them) who are directly involved in designing the product interfaces using the subsidiary design system and developing it by contributing to both the design and the code.
The roles listed above do not necessarily have to be performed by different people: a product designer/developer can be simultaneously a designer/developer of a child design system, a designer/developer of a child design system can be a direction leader in a parent design system, etc.
The configuration of the control system depends on many factors and may vary depending on the needs and size of the company.
Pros and Cons of a Hierarchical Design System
Pros
A hierarchical design system solves, or at least minimizes, the problems of conventional multi-product design systems:
A structure of multiple child design systems is more likely to accommodate the diverse needs of products than a single design system, without overriding product initiatives or causing unsystematic development at the individual product level.
The unity of the code base can be ensured by the efforts of child design systems, including in terms of organism-level components and page templates, which contributes to greater efficiency of both design and front-end development than simply reusing atoms and molecules.
Due to the fact that similar products belong to one subsidiary design system, it is possible to maintain product expertise at its level and take product features into account when designing components.
The subsidiary design system covers only a part of the products, so it receives many times fewer requests for improvement or creation of components. At the same time, the similarity of the products facilitates decision-making on the final functionality of common components.
By having multiple child design systems, the design team working on a hierarchical design system becomes more distributed, allowing them to respond more quickly to product needs and make decisions using product expertise.
The process of contributing at the level of a child design system seems more efficient, since there are fewer and more homogeneous requirements for components, which makes it easier for developers to work together to develop and maintain components.
The hierarchical structure allows us to monitor the contribution and parallel development of child design systems, raise best practices and truly common entities to the meta level and distribute them back to all products through the child design system level.
It is easier and cheaper to implement a hierarchical design system: if you take the design systems that already exist in the company as the basis for subsidiary design systems, then the products that use them will not suffer during the transition and will not lose their effectiveness (or will suffer in the part where it will be necessary to bring the design system to the state of “subsidiary”).
The task of merging existing design systems is simplified: the merging occurs not in one design system, but in several subsidiary design systems, which reduces the total volume of tasks for merging and allows them to be distributed between several teams of subsidiary design systems.
The process of expanding the product line with products that are not standard for the company becomes less painful: it is possible to allocate a specialized subsidiary design system without making changes to the meta-level and without affecting other products.
Not minuses, but not pluses either 🙂
The transition to a hierarchical design system requires revising the management structure, implementing new processes, and solving a number of complex problems. But strictly speaking, these are hardly disadvantages. Rather, they are the price that must be paid to implement a hierarchical design system and work effectively with it:
Some complication of the management structure.
The need for constant monitoring of the parallel development of subsidiary design systems.
The need to organize the process of information exchange between the meta-level and the level of subsidiary design systems and control over it.
When connecting existing products to child design systems, there will still be, albeit to a lesser extent, challenges in merging components and code bases.
There remain standard tasks related to general analysis and systematization (to form a meta-level), and the need to spend time and effort on the transition to a hierarchical design system.
Conclusion
In this article, we examined the problems of conventional multi-product design systems, considered a non-standard solution to them – the creation of a hierarchical multi-product design system – and tried to objectively evaluate its pros and cons.
In our opinion, the evolution of a conventional design system and its transformation into a hierarchical one is a natural stage of development in accordance with the law of transition of technical systems into a supersystem*, and the advantages listed in the article are proof of the prospects of such a transformation.
In addition, the proposed approach is very flexible: depending on the characteristics of a specific company and specific products, you can formulate your own rule for distinguishing subsidiary design systems, revise the structure of the meta-level or the management system.
The idea of creating a hierarchical design system is experimental, so if you have similar experiences, arguments for and against, ideas for a better name (instead of “hierarchical design system”) or just interest in this topic, please share them in the comments.
P.S. While thinking about the hierarchical design system, we also designed a smooth (though not very fast) process for gradually connecting products to child design systems. If you are interested in looking at it and discussing it, write about it in the comments, and we will prepare a separate article.
—
* This refers to the law formulated in the theory of inventive problem solving (TRIZ), according to which monosystems, having exhausted their resources at the monolevel, are combined into bi- or polysystems. This helps to increase the efficiency of the systems both due to the very fact of unification and due to the increase in the difference between the elements included in them (in our case, between the subsidiary design systems).
Acknowledgments
Thanks to the managers, designers and front-end developers of VK Tech for their attention to such an interesting topic, Sasha Shatalov for human and technical support in all endeavors, Matvey Bryksin for good ideas and real examples confirming the correctness of the hypotheses put forward, and my team (Nastya Mikhalkova, Karina Mulkamanova, Nata Nefedeva and Olya Ostanina) for their help in preparing this article.
