Design Systems Decoded
What to build, what to share, and what your team can realistically maintain.
A team agrees to build a design system. The designer starts organising a Figma library. An engineer expects a versioned component package. The marketing team wants clearer brand rules. The product manager expects future features to ship faster.
Everyone has agreed to the same phrase. They have agreed to different work.
This is where many design system conversations become expensive: before anyone draws a component, the team has already made conflicting assumptions about the deliverable.
The names matter because they help us discuss those assumptions. But knowing the names is only the beginning. The more useful question is:
Who needs to share which decisions and who will keep those decisions useful as the product changes?
This article offers a practical framework for answering that question. We will separate the assets from the system, examine the scope different teams need, and work through the decisions that turn a library into something people can depend on.
1. Separate four decisions that often get bundled together
“We need an enterprise design system” sounds specific. It leaves several important questions unanswered. Does the team need shared visual foundations, production components, cross-product patterns, or a process for coordinating all three?
A useful way to unpack the request is to consider four dimensions. This is a working framework, not an official industry classification.
Maturity cuts across all four. A focused product system with reliable releases and well-tested patterns can be more dependable than a large library with unclear ownership.
There is no universal naming rule that makes a UI kit a small design system or an enterprise system a large one. Component count tells you very little about whether teams can trust what they are using.
2. Understand what each deliverable actually promises
These terms overlap between organisations. Treat the distinctions below as questions to clarify with your team, rather than definitions to police.
Brand guidelines explain how an organisation expresses itself: identity, logo usage, imagery, voice and tone. Their reach can include packaging, campaigns and physical spaces as well as digital products.
A UI style guide documents visual conventions such as typography, colour, spacing and layout. It helps people make consistent visual choices. It may provide no reusable implementation.
A UI kit gives designers reusable assets for composing interfaces. It can be sophisticated and well documented. Its existence alone does not tell you whether matching production code exists or who will maintain that relationship.
A component library provides reusable interface elements. A design library represents their appearance and states; a coded library implements behaviour and an API. Some teams use the term for one, others for both. Ask which is included.
A pattern library explains recurring solutions to user problems. “Filter a long list” is a pattern; a select control is one possible component within it. A useful pattern describes context, behaviour, content and trade-offs — not just a screenshot.
A design system connects shared foundations, reusable implementation and guidance with the people and processes that keep them coherent. Its precise contents depend on the experiences it supports.
These are not six stages on a maturity ladder. Brand guidance does not become obsolete when a component library appears. Patterns do not replace components. The pieces answer different questions and can work together.
3. Follow one experience beyond the component
Consider entering a delivery address. The interface contains familiar elements: labels, text fields, an error message and a button. A polished library can supply every one of them while leaving the experience unresolved.
When should validation happen? What happens to the other fields when one entry fails? How does a keyboard user reach the error? Does the message explain how to recover? What changes for a country with a different address format?
The component defines the field’s supported states and behaviour. The pattern explains how fields work together in a task. Content guidance helps the team write useful instructions. Product logic decides whether the address is deliverable. Accessibility testing checks whether people can complete the assembled journey.
This distinction helps prevent two common problems: a component that accumulates every business rule, and a collection of attractive components that leaves each team to reinvent the same interactions.
For a reusable address pattern, document the decisions another team would otherwise have to rediscover. Preserve valid entries after an error. Explain the trigger for validation. Specify how errors are associated with fields. Identify where country-specific rules belong. Include examples of recovery, not only the successful submission.
The value lies in the decisions a team no longer has to make from scratch.
4. Tokens give shared decisions a usable vocabulary
Repeated values are easy to collect. Their meaning is harder to preserve.
If several interfaces use the same grey, are they expressing the same decision? One may be secondary text, another a border, and another a disabled control. Linking all three to a single “grey” value can make a future change unexpectedly broad.
Tokens give decisions names that can travel between tools and implementations. Atlassian’s token guidance illustrates how named decisions support consistent application and changes such as theming. [1]
A common approach distinguishes raw values from their intended roles. A component-specific layer can be useful when a component needs an independent contract, but every system does not need every layer.
These names are illustrative, not a prescribed standard. Too many layers can make a simple change difficult to trace; too few can couple unrelated decisions.
The Design Tokens Community Group’s 2025.10 format defines an interchange format for token data. It is a Final Community Group Report, explicitly not a W3C Standard. It helps tools exchange decisions; it does not decide your naming architecture or governance for you. [2]
Similarly, creating variables in Figma does not automatically establish a reliable token pipeline. Decide where changes originate, how design and code stay aligned, and how consumers learn that a mapping has changed.
5. Choose scope around the work people do
A product design system can focus deeply on one product’s workflows. For a fleet platform, that might include vehicle status, alert triage and tracker setup. Its strength comes from solving those recurring tasks well. A small audience does not remove the need for ownership, accessibility or maintenance.
An organisation-wide system supports shared needs across products and teams. The additional challenge is coordination: a change useful to one product may disrupt another. Releases, contribution decisions, support and migration become part of the offering. “Enterprise” may also describe the customers a product serves, so clarify what the label means in your context.
A shared core with local extensions gives teams common foundations while allowing domain-specific solutions. A logistics application and a finance application might share form controls without sharing the same operational patterns. Several connected systems may be described as a “system of systems”; the phrase alone does not define their dependencies.
A multi-brand system separates what brands can share from what must remain distinctive. Themes may handle colours and typography. They may not handle different navigation models, content structures or interaction requirements. Test the differences before promising that a token switch can express every brand.
A marketing or web system supports publishing and branded communication. Editorial layouts, campaign modules, navigation, content modelling and CMS integration can matter as much as buttons and inputs.
These descriptions can overlap. A multi-brand system may have a shared core and product extensions. A product system may sit inside an organisation-wide programme. Naming the scope should make the boundaries clearer.
6. What Red Hat’s systems help us understand
Red Hat provides a useful example of designing for different kinds of work within one organisation.
The Red Hat Design System (RHDS) supports branded digital experiences through its design language, elements and developer resources. PatternFly, also supported by Red Hat, is an open-source system for enterprise product interfaces, with resources for tasks involving forms, tables, filtering and other application interactions. [3] [4]
The lesson is about purpose. Someone exploring a company’s offering has different needs from someone managing operational data all day. Their interfaces may share brand conventions while requiring different structures, densities and patterns. This does not imply that the systems must be entirely separate or cannot evolve towards greater alignment.
Public systems such as IBM’s Carbon and Adobe’s Spectrum are valuable references. Carbon documents contribution and readiness practices; Spectrum provides a shared language and resources for Adobe experiences. Their public documentation offers ways to reason about a system, not a requirement to reproduce their entire infrastructure. [5] [6]
7. Decide what belongs in the shared core
Imagine a commerce business with a customer storefront, a merchant administration tool and a marketing website. This is a hypothetical example, but the decisions are familiar.
The three experiences could share typography conventions, focus treatments, basic inputs and some semantic colour decisions. The storefront needs checkout and delivery selection. The administration tool needs inventory filtering and bulk editing. The marketing site needs editorial modules and campaign flexibility.
Get Tauseef Rubab’s stories in your inbox
Join Medium for free to get updates from this writer.
Putting every specialised pattern into one central package creates a large maintenance obligation. Sharing almost nothing makes teams repeat useful work. The boundary needs evidence.
Before promoting something into the core, ask whether multiple consumers have the same underlying problem, whether the behaviour is stable enough to support, and whether someone can maintain it across those contexts.
Two screens that look alike may have different requirements. Conversely, two differently styled screens may share the same interaction problem. Reuse should follow those requirements, not visual resemblance alone.
The GOV.UK Design System’s contribution criteria provide a useful precedent: proposals need evidence of usefulness and uniqueness; published additions are assessed for usability, consistency and versatility. [7]
A local solution can therefore be the right starting point. Use it, test it, and learn which decisions repeat. Promote the stable common behaviour when the evidence supports it. Document intentional exceptions so they do not look like accidental inconsistency.
8. Consider adoption before building infrastructure
Once the scope is clear, decide how much you actually need to create.
Start with any system your organisation already maintains. If you are considering an external foundation, evaluate it against real work: your platforms, accessibility requirements, interaction complexity, visual flexibility, licensing and the team’s ability to update it.
A useful trial is a representative journey with difficult states. Include an error, a loading condition, a narrow viewport and keyboard use. A library that makes the happy path quick may still create considerable work around the edges.
Adopt when the foundation fits and supported configuration covers your needs. Adapt when a stable foundation can support a clear layer of your own decisions. Build the parts whose requirements are genuinely unmet and whose maintenance your team can fund.
These choices can coexist. A team might adopt accessible interaction primitives, maintain its own visual components and create domain patterns locally. Keep the boundary explicit so an upstream update does not become an unexpected redesign.
9. Ownership becomes real when a change is requested
Governance diagrams are easy to agree on. A request to change a widely used component reveals whether the arrangement works.
Suppose the merchant team needs bulk selection across several pages of inventory. Selecting visible rows is different from selecting every result that matches a filter. The distinction affects the interface, confirmation content and implementation.
Who investigates whether another product needs this? Who decides if it belongs in the shared table pattern? Who reviews keyboard behaviour? Who supports existing consumers if the API changes?
A dedicated system team can make those decisions consistently, but may become a queue if every domain question depends on it. Distributed product contributors bring context, but need allocated time and someone responsible for resolving conflicts. A combination can work when the core team maintains shared contracts and product teams contribute with clear review expectations. These are the practical trade-offs behind centralised, federated and hybrid ownership models. [8]
For the bulk-selection request, write down the route from proposal to support. Name a maintainer. Record the user problem and affected consumers. Prototype the behaviour in its original context. Review broader applicability. Publish with migration instructions if existing usage changes.
“Everyone owns it” is incomplete unless someone has the authority and time to make the next decision.
10. Accessibility and maintenance belong in the definition of done
Accessibility is partly a shared infrastructure concern and partly a responsibility of the assembled experience.
A component can provide appropriate semantics and keyboard behaviour. The product team still chooses labels, content order, page structure and how interactions fit together. Those decisions can introduce barriers even when every individual component has been tested.
WCAG 2.2 provides testable, technology-neutral accessibility criteria. The WAI-ARIA Authoring Practices Guide offers informative implementation guidance; it stresses that adding an ARIA role does not supply the expected keyboard behaviour. Use native controls where appropriate, and test the resulting experience rather than treating a role or checklist as proof. [9] [10]
For each maintained component or pattern, define what consumers can rely on: supported states, interaction behaviour, accessible usage guidance, implementation, examples, known limitations and ownership. Testing should cover relevant browsers and assistive technologies as well as automated checks.
Readiness should also be visible. Carbon’s component checklist distinguishes stages of readiness and covers design, code and documentation expectations. Carbon Labs provides space for exploratory work. The useful principle is that consumers should understand the support and stability they are choosing. [5] [11]
Once something is released, explain what changed, who is affected and how to migrate. Decide how long older versions will be supported. If a pattern is retired, provide a route forward. Without that work, a system gradually becomes a catalogue of decisions nobody feels safe changing.
11. Measure whether the system helps people work
A larger library is not automatically a better outcome. Neither is a high download count: a dependency can be installed and barely used.
Choose measures that connect to the problem you set out to solve. For a pilot, compare how teams handle the same kinds of work before and after adoption. Keep task complexity and context in view.
- Adoption: Of the eligible interfaces or teams, how many use the supported solution? Define “eligible” so intentional exceptions do not distort the result.
- Friction: Where do consumers need workarounds, repeated support or undocumented overrides?
- Quality: Are recurring accessibility and interaction defects being resolved at the shared source?
- Change: Can teams adopt updates without disproportionate migration work?
- User outcomes: Does the assembled workflow help people complete their task?
These measures answer different questions. Faster implementation does not prove better usability. Better task completion may result from several product changes, so avoid attributing every improvement to the system.
Use the evidence to change priorities. If teams repeatedly bypass a component, investigate the unmet need before enforcing adoption. If an elaborate pattern has no consumers, its maintenance may not be justified.
12. Turn the decision into a small, explicit commitment
At this point, “Which type of design system do we need?” should become a more concrete conversation.
If your immediate goal is exploring a prototype, reusable design assets may be sufficient. If a live product repeatedly implements the same interactions, aligned design and production components deserve attention. If several products are diverging on shared decisions, define a common core. If brands differ, test whether themes can express those differences before committing to a multi-brand architecture.
Write a short system charter before planning a large inventory. Here is one possible starting point for the hypothetical commerce team:
This is a more actionable commitment than “build a system like Adobe’s.” It tells the team what to make, what to leave local, how to judge progress and when to expand.
Start by auditing a few representative journeys. Talk to the designers and engineers who would consume the work. Find the decisions they repeatedly make, then test a shared solution in a real product before expanding the catalogue.
A design system earns trust when teams can use its decisions, understand its limits and change it without losing their way. The right scope is the one that solves recurring problems and has people ready to maintain it.
Before building the next component, agree on the promise your system is making and who will keep it.
Sources and further reading
The vocabulary and decision framework in this article are practical interpretations, not a universal taxonomy. Product scenarios and interface illustrations are conceptual. Sources were reviewed on 28 October 2026.
- Atlassian Design System — Design tokens
- Design Tokens Community Group — Format Module 2025.10
- Red Hat Design System
- PatternFly
- Carbon — Component contribution checklist
- Adobe Spectrum
- GOV.UK Design System — Contribution criteria
- zeroheight — Design system governance models
- W3C — Web Content Accessibility Guidelines 2.2
- WAI-ARIA Authoring Practices Guide — Read this first
- Carbon Labs
