Last revision: 9 January 2024.

As digital products and services have matured over the years, the tools and structures supporting them have become increasingly complex. That is particularly true in larger organisations dealing with multiple products or services across multiple platforms.

As a service designer working with delivery teams, I have been interested in understanding and defining how the concept of design systems scales horizontally across product teams and vertically across products and services. This article is part of an ongoing attempt to frame this.

Whenever we talk about design systems, we typically talk about design systems for interfaces that focus on collections of patterns, reusable components and code snippets, guided by principles, and used to build user interfaces of digital products.

Design systems are for interfaces:

• Design systems care about content as it pertains to user interfaces.
• Design systems care about accessibility as it pertains to user interfaces
• Design systems care about personalization as it pertains to user interfaces.
• Design systems care about voice and tone as they pertain to user interfaces.
• Design systems care about brand as it pertains to user interfaces.
• Design systems care about performance as it pertains to user interfaces.
• Design systems care about code standards as they pertain to user interfaces.
• Design systems care about internationalization as it pertains to user interfaces.
• Design systems care care about personas as they pertain to user interfaces.
• Design systems care about _________ as it pertains to user interfaces.

– Brad Frost, Design systems are for user interfaces, 15 Nov 2021

Having “only” a design system for your interfaces is typically not enough to create cohesive and harmonious experiences for a brand that has a portfolio of services.

After all, the design of digital products extends beyond interfaces, just as the design of (digital) services extends beyond the interaction with a single product.

UI patterns and components alone cannot fully convey the entire story behind how they came to be and why things work and look as they do. This is likely one of the reasons why it’s been so tempting to include more than interface-related content under the umbrella of “THE” design system before.

“ A design system is a multi-faceted layer cake, and also operates as part of other layered systems within an organization.” — Brad Frost, 2021

Just as we recognise that a design system for interfaces is a complex system of interrelated subsystems, it’s important to understand that the design system itself is just one part of an even larger, overarching design mega system. If an “interface design system” is only one entity within a mega ecosystem, what are the other ones?

Part 1: Exploring a topology of design systems

An attempt to make sense of higher-level design systems

Organisations are, more often than not, complex. A multitude of people are involved with different levels of expertise, at different moments, on different things. So when it comes to delivering (digital) products and services, it’s common to have many product or delivery teams as well.

Every team might be using the same interface design system, but it doesn’t guarantee a harmonious, coherent and consistent overall experience within one product. Not every organisation has a team dedicated to ensuring user journeys and service-level experiences, or processes that enable teams to connect effectively to ensure the re-usability of different components of a user journey. Team members and product managers often self-organise and attempt to harmonise features, journeys and experiences. In an organisation with several products (customer-facing, or internal-facing), experiences can also be wildly different between products despite adhering to the same interface design system.

It can be hard to get a grasp of what user journeys exist, who owns them and how reusable they might be. This often leads to duplication of journeys — teams recreating existing journeys because they don’t know what else is out there. Or maybe there’s no clear guidance on how to surface a specific micro-service to end-users, or guidance on whether re-using existing user journeys is appropriate. Journeys are typically not in the scope of design systems — they’re often not considered patterns…but maybe they should be.

Doesn’t this sound somewhat like the early days of design systems of interfaces? Back when teams often created new UI components without considering what already existed and unintended visual anarchy? This similarity exists at different levels where the design capability is involved.

This isn’t new. We’ve just been focusing on one part of the system: design systems for interfaces have dominated the “design system” conversation, they’re not the full picture.

Different types of systems

The notion of a design system for interfaces naturally infers the existence of design systems with ever-large scope, sort of nested within each other.

Over the last few months, I’ve been toying with the idea of 5 different levels or types of design systems, each with a different scope.

5 levels (a work-in-progress model):

• Level 5: Design systems for interfaces which relate to how an organisation designs and builds its interfaces (based on the definition framed by Brad Frost in 2021). This could be a digital interface, but also another channel or medium if your services include physical touch points.
• Level 4: Design Systems for products which relate to how an organisation designs their products, whether consumer-facing or not.
• Level 3: Design Systems for services which relate to how an organisation designs and orchestrates its services. By services, I mean here large(r) end-to-end services in the economic/business sense (e.g. “online food delivery platform”) rather than functional microservices (e.g. “authentication/logging in”)
• Level 2: Design Systems for brands which relate to how an organisation envisions, designs and shapes their brand(s). Design systems for brands might include components and guidelines on how to create new (sub)brands but in many cases, there’s only 1 brand at play. Thus the design system might focus on the different expression and direction of the brand, and all related guidelines. Brands might be internally-facing or externally facing to customers.
• Level 1: Design approach of the organisation which relates to overarching design-related guidelines that transcend every design system level.

Each level influences the next, with assets/principles being inherited from one to another. Conceptually, as we go from high-level to lower level the scope becomes narrower and the content of the design system becomes more specific and concrete.

The higher the level, the more abstraction is present. The next level then inherits relevant assets/principles and translates them into other materials relevant to its specific scope, often adding more details and dimensions. The lower the level, the more specific the content of the design system tends to be.

If you are familiar with object-oriented thinking, this is similar insofar as it’s about applying the concepts of abstraction and encapsulation to the notion of “design system” levels.

For example, here are some things that might sit at each level and how they get passed on to the next:

• Level 1 (highest level): An organisation has a vision and mission, some of those might directly dictate the overarching approach about how it works (or want to work), what attitude it might have towards design and delivery as a practice or strategy
• Level 2: The organisation’s brand(s) likely take elements of the vision & mission to inform its overall branding. From logo to typography and colour scheme, brand principles strategy, tone of voice, visual art direction and more. Often, brand elements will become tokens that are passed down to design systems for interfaces.
• Level 3: How the company operates, what the brand strategy and principles are,…those influence how it will operate and deliver its services. The higher-level guidelines are distilled further to define, among other things, what are the service principles. Think of service-level agreements, customer experience promises, multi-channel service approaches, etc…
• Level 4: Specific guidelines and approaches that the organisation’s digital product(s) follow, specific digital product principles and strategies that influence user journey patterns, and more…all informed and influenced by service principles alongside elements of the levels above
• Level 5 (lowest level): At last, UI components manifest the series of decisions encapsulated in each level above. The style, usage and rationale of each component are informed (in part) by the “why” from other levels.

Of course, the reality is messier. Things usually aren’t as clear-cut.

Conceptually, each design system level might exist but whether they are created as separate systems depends on teams and organisational needs. Some levels might not make sense for some organisations — maybe the product and service levels could be combined. In practice, it could very well be 1 nominal design system, structured in a way that creates conceptual layers. Sometimes organisations have multiple brands, multiple services, products and interfaces…which might warrant different design systems altogether because the audiences and needs are just too different from each other.

An ecosystem of design systems

Our design systems are a series of independent systems, sometimes nested within each other or co-existing in the same planes, yet they influence each other. Disruption to one might lead to more or less impact on another one. Or maybe a catastrophic event disrupts all of them at once.

To illustrate the idea, let’s imagine our ecosystem of design systems as being a series of restaurants, their set menus, recipes and ingredients.

Suppose each of those restaurants belongs to the same organisation…or part of a franchise. They share a common philosophy, certain values and vision, and brand elements. They tap into the same playbook of guidelines and objectives to drive their individual offering. Yet each restaurant manifests itself differently: maybe they have different themes and specific variations based on factors like their location.

Each restaurant has its own brand identity, and its way of applying the playbook. Distinct yet part of a whole.

They have their own brand and guidelines, operate somewhat independently, and have different values and principles.

Say each restaurant offers different 3-course set menus. Because they belong to the same mother organisation, they might be sharing knowledge and recipes with each other. Some of them might offer the same menu…albeit with a small variation to match their brand and story.

Menus are composed of different dishes. A given dish might be featured in several menus, or only in 1 menu. If repeated across menus, they might be subject to variations to match the menu and restaurant that serves it. Each dish has its own purpose in the dining experience, designed with consideration about how it is plated, what it looks, tastes, smells and feels like; how you might interact with it.

Dishes are of course made from simple or complex components: base ingredients combined (or not) are of care made from complex or simple ingredients. Just like interfaces are built using components from the design system.

Each system influences the others. If the essence of one system-level changes, it might affect another one. This can be driven by internal change or external events. In our restaurant analogy, this could be events like the availability of some ingredients changes. Dishes must be adapted to maintain harmony but this sometimes means changing the flavour direction or presentation, and triggering and larger response or changes. Or maybe the brand direction and strategy change: restaurants are asked to target a different audience. Their menus, dishes and ingredients must be adapted to suit the new guidelines.

For organisations providing services and products, this could be new regulations or other market forces. It might not affect the company’s vision, the brand or the service experience…but maybe it will create significant changes in the services you can provide for some key user journeys or interfaces.

This restaurant analogy is not perfect, but I hope it helps clarify the essence of what I mean by levels of design systems. I’ve only chosen it to illustrate how intertwined different levels of systems might be.

In reality, the hierarchy between the levels may not be as clear-cut as in this example, where each level visibly operates on a different scale. For example, a service might feature several products, but a product might also make use of several services. More on this later.

Connecting design systems

Ideally, each level should be pointing to concepts or elements from other levels through some sort of token system or referencing methods. This might also help users, contributors and maintainers to understand where decisions came from and what might be affected downstream. This can also create connections between processes and make them more visible, fostering a shared understanding of the global design system of an organisation.

Of course, linking everything to everything can start becoming a dangerous rabbit hole. One may get carried away and start referencing every single decision or content. Nor should everything be so rigid that teams lose the room to experiment, iterate and innovate.

Teams will need to decide what is appropriate for their users and what delivers the most value without adding processes for the sake of documentation.

A functional and sustainable design system is typically made of 3 parts

• Assets (e.g. patterns, components, libraries, code snippets.. .)
• Documentation about itself and its assets (e.g. how and when to use what pattern, related insights,…)
• Processes about itself, its assets and its documentation (e.g. how and when to update a pattern,…)

If we are to establish the existence of multiple levels of design systems, we need to create intentional agreements and coordination between the teams governing each system. Design operations become even more important to help run everything smoothly. Without dedicated attention to operationalising processes and a willingness to test, learn and iterate, it will be easy for things to fall through the cracks, for design systems to duplicate work, overlap in scope and cause more harm than good.

If your organisation has a dedicated Design system team, they are typically responsible for the above with the design system for interfaces. A brand team might be in place to look after branding guidelines which by extension can become the brand design system. Design systems for products and services might fall under the responsibilities of dedicated teams. Either way, coordination is needed between the different responsible parties to support the adoption of the design systems, and their scaling — while maintaining a reasonable level of independence when necessary.

As said earlier: not every organisation will need multiple levels of design systems. Systems are living and evolving structures: they grow and shrink as per the needs of teams and organisations. Always start with the simplest implementation needed before adding more nuances and complexity.

Design systems aren’t one-size-fits-all. How each level connects to the next and how to define some of these boundaries are up to the specificities of each organisation and the needs of the team who will create, use and maintain the systems. To figure out how things connect, we first need to understand the scope and boundaries of each design system.

Part 2: design systems for products & services

https://uxdesign.cc/design-systems-for-products-services-ecosystem-of-design-systems-207ef1050442

The thoughts outlined above are a work in progress. They are fuelled by my experience working as both a service designer shaping larger services and as a UX designer within delivery teams. Over the years, I have had the chance to work on service design patterns, to set up and contribute to different design systems while freelancing in different organisations, and also to focus on designOps and knowledge management platforms and platforms. Each of those experiences helped me see different facets of a design system framework, how different the needs are for different purposes and yet how things seem to connect conceptually together.

If you’ve enjoyed this article, consider buying me a coffee as a thank you, fuelling my caffeine habit while I write more articles on service design & design systems.

Want to chat or bounce some thoughts on this topic? Feel free to reach out