Beyond design systems for interfaces: a mega system of design systems

Marie Lu Vinh
12 min readMay 21


Full(er)-stack design systems. A service design perspective.

Over the past few years, it’s been exciting to see the increasing adoption of design systems and the shift towards a design systems mindset within organisations with digital products. What was once a collection of design style guides has evolved into dynamic systems aiming for parity with front-end development. There are a lot of exciting efforts happening, however there’s still a lot of work for design systems to reach full maturity still. Many organisations are on a journey to create and grow their own systems, and the design system framework itself continues to evolve.

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

This explicit focus on design systems for “interfaces” was articulated by Brad Frost in order to reduce confusion during a time when “design system” became a catch-all term for any design-related guidance within a company.

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.

Having a design system for your interfaces is typically not enough to create cohesive and harmonious experiences.

After all, the design of digital products extends beyond interfaces, just as the design of (digital) services extends beyond the one product end-users might interact with.

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. 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.

“ 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 system, 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 a multitude of 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 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.

In many organisations it’s 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 — with teams recreating existing journeys because they don’t know what else is out there. 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.

These thoughts were fuelled by my experience working as both a service designer shaping larger services and UX designer within delivery teams. Over the years, I have had the chance to work on service design patterns during my time at BT, to set up and contribute to different design systems while freelancing in different organisations, and also to focus on designOps and knowledge management at adidas. 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.

A work-in-progress model of different kind of design systems levels, each connecting to the next.

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.

For the purpose of illustrating the idea, let’s imagine our ecosystem of design systems as being a series of restaurants and their set menus.

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 own 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 own 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 recipe with each other. Some of them might offer the same menu…albeit with a small variation to match their brand and story.

Each restaurant serves a pill-shaped menu but with some variations suitable for their own brand.

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 has an influence on 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 of course 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 in relation to 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 its scaling — while maintaining a reasonable level of independence when necessary.

All of this thinking is a work in progress, and I have yet to figure out in practice how the maintenance cycle and interdependencies might work.

For that, I wonder if we can take inspiration from software engineering practices and how they handle package and library dependencies. Tooling has a huge impact on what might be possible in terms of processes and ways of working. With the current state of design tools, we will most probably face sub-optimal workarounds for a while.

To figure out how things connect together, we first need to understand the scope and boundaries of each design system. 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.

Part 2: design systems for products & services

Coming soon



Marie Lu Vinh

Designer with a love for technology. Currently freelancing, based in Amsterdam (NL), available globally. Previously: futurice, Idean (now frog), adidas