Building a Design System of Systems

Design systems are gaining popularity to help enterprises go to market quickly. The benefits of design systems are well documented:

What happens when an organisation manages multiple brands? Suddenly the effort required to build a design system seems muted because only a subset of the organisation will benefit from the investment. The complexity grows further when considering design systems that should deliver a consistent user experience across multiple platforms.

While working as a consultant embedded in a team in a large corporation, the team was faced with the above challenges. In order to overcome these challenges, the team built a platform for creating branded design systems within the organisation. It was called a design system of systems. Rather than imposing strict ways of working, the design system of systems provides a common language and work processes to allow teams to collaborate.

This article describes some of the key challenges to consider when building a design system of systems.

A design system of systems is the agglomeration of a toolchain, set of work processes, and a governance model for building and maintaining brand-specific design systems. The team considers these to be the three pillars of the design system of systems triangle.

Figure 1: Design system of systems pillars

The toolchain is a series of supporting tooling that lets brands develop and grow their design system. This includes the tooling that allows transforming human-readable design options and decisions into something that can be consumed by the various supported platforms. Designer and developer experience is a key value of the system. This is why the team dedicated a point of the triangle to the toolchain. If teams find the system of systems as an impediment, adoption will suffer.

Work processes establish how designers, developers, and teams work together. Designers need to work within the bounds of the established design system in order to deliver reusable designs that can be translated into the design system. Developers should prefer reusing and contributing changes back to the system of systems so that all teams can benefit. The end goal is to maximise the development velocity while minimising the time to market. In order to organise the chaos of parallel workflows, clear work processes need to be established.

Governance allows the organisation to establish ownership and responsibility. While working as a consultant, I always promote a democratic development and contribution culture (with open-source or inner-source). Empowering and encouraging employees to contribute to the greater good of the system. Maintainers and trusted committers should be nominated and empowered to make decisions that have real impact on the project.

However, most organisations will need some hierarchy to delegate the strategic vision of the organisation to initiatives that ensure investments help to realise the vision. This is why a minimal governance model is needed to establish the owners and responsibilities of the various aspects of the design system of systems. The shallowest hierarchy possible is always preferable in order to maximise the democratic empowerment of individuals in the organisation.

Channels have multiple dimensions: brand experiences, supported platforms, and user roles.

Figure 2: Multichannel matrix

The first dimension is the brands of the organisation. The system of systems is designed to provide a rich brand experience for all brands of the organisation. The second dimension is platforms. This could include web, mobile native, IoT, and others.

The third dimension is a crucial detail that can be easily overlooked: each brand may support multiple user roles. This is the difference between customer end user-facing applications, internal applications for members of the organisation, and B2B applications interfaces.

A customer end user-facing application will have a strong brand identity, allowing customers to identify with the brand. In web design, this is often achieved with careful use of whitespace to emphasise the aspects of the brand. On the other side of the spectrum, a B2B application will still need to adhere to the brand identity, but will often have a more utilitarian user experience.

For example, having tighter spacing and less whitespace allows the business end-user to be productive with the application. Further down the spectrum is an internal application. Here the brand identity will typically be less important, with productivity being the most important aspect. Members of the organisation want to get something accomplished with the application and nothing more.

Taking the three dimensions into consideration, multichannel quickly becomes a complex problem. Attempting to build a design system that works for all channels requires careful consideration of the combination of channels that will be targeted.

While implementing the multichannel design system, the team used React Native to build a themeable component library that works on both web and mobile native platforms. React Native is incredible for this reason. However, careful consideration of the required channels must be considered when building a multichannel design system.

Web applications and the possibility of progressive web applications should be considered before reaching for React Native. A React Native toolchain adds significant complexity to multiple layers of the system of systems. If a modern, progressive web application can solve 90% of the application requirements, there may be no need to add the complexities for React Native.

To summarise, React Native is great. At NearForm, we use it for many projects and have a lot of in-house React Native expertise. Organisations should simply consider the long-term trade-offs that come with building React Native in-house. Especially if web applications will meet the majority of required use cases.

After building the multichannel design system, adopters faced a lot of confusion about the difference between a multiple brand design system and a multi-brand application. A multiple brand design system provides the freedom for brands to create separate and unique user experiences. An application that is multi-brand requires tight coupling between brands and constrains the user experience within those bounds. A multi-brand application is often referred to as white-label.

The team is building both. However, it’s important to understand that a single application can’t be both. The rich user experiences that allow end-users to identify with the brand can’t be abstracted into something generic. The user flows and interactions will be inherently different. Diffusing this understanding into an organisation is a challenge. There is no silver bullet that allows write-once and use-everywhere with a rich and unique brand experience.

In order to break down the silos between designers and developers, both parties need to agree to speak the same language. Design tokens provide this common language both in a figurative and literal sense. Design tokens represent the design options and design decisions.

To put this another way, design tokens provide the options to stay on brand and the decisions for a particular design. Figuratively, the design tokens represent the common language to communicate a design and literally, design tokens represent the actual machine-readable design decisions that should be implemented.

For example, the design tokens can be broken down into types or categories. Here are some common design token types:

Figure 3: Design token types

Given colours, the design options consist of all the possible colours that are allowed. These will typically be aligned with the given colour scheme of the brand.

Figure 4: Design option

Design decisions consist of determining which options should be applied to styling a given component. For example, the diagram below illustrates all of the tokens that could be used to style a button. For each token, a design decision will be made to assign an option to that token.

Figure 5: Design decisions

The magic of the design system is the component library that accepts the decisions to allow them to be styled. In React , design decision tokens can be passed as properties to the components. This allows the component library to be themed for different brands. The design tokens must be abstract enough that they are not bound to a single platform, such as css for web. In order to be truly cross-channel, they need to be capable of also being bound to native platforms. This makes theming with design tokens different from other common component theming libraries.

Furthermore, the design tokens should also be compatible with the tools that designers use, such as Figma . Only then can designers and developers be speaking the same language: design tokens. When designers create a new design, they need to work within the bounds of the brand design options. The design work becomes an exercise in making the design decisions. The design system toolchain will then transform these design decisions into a theme that is compatible with the component library. There is lots of exciting work happening in the Figma ecosystem. Ideally, the system of systems toolchain should be able to synchronise tokens to Figma.

Building a multiple brand and multiple channel design system provides huge benefits in terms of increasing efficiency and reducing frustration between parts of an organisation. The complexities, as described in this article, are just as vast as the potential benefits.

The key lessons and values that the project adhered to are that the system should be inclusive and not restraining. Teams, organisational units, and individuals should be given the freedom to work in a manner that is best suited to their needs. The design system of systems should provide the framework and guidance for working efficiently rather than imposing certain ways to work.