A Design System Needs Someone to Look After It

A component library can contain a well-designed button, form field and navigation menu without telling a product team which version to use, who will support it or how to request a change. Those questions become pressing when a component enters a live service.

The first implementation is relatively easy to admire. The more revealing moment comes later: a developer finds an accessibility issue, a new product needs a different interaction, or the design file and production code no longer match. The value of the system depends on how the organisation responds.

Design system governance is the set of decisions that makes that response possible. It establishes who can approve a shared change, what evidence is needed, how users learn about it and who maintains the result. For an SME, this can be a modest arrangement. It still has to exist.

IBM's description of Carbon includes code, design resources, guidance and a contributor community. That illustrates why a system extends beyond the inventory of components. It does not imply that a smaller business needs an equivalent organisation.

Begin with the work the system is meant to support. A single product and a closely connected team may need a different model from a business with several products and external delivery partners. The practical objective is the same: make shared decisions dependable enough that teams can use them without reopening the entire discussion each time.

A useful system makes the approved path easier to follow and the exceptional case easier to resolve.

“The design team owns it” may sound sufficient until a change requires design, engineering and content decisions at once. Ownership should identify who can bring those considerations together and make sure the outcome reaches the product.

Give one person or a small group responsibility for the system's direction and backlog. Then make maintenance responsibility clear for its implementation. The same individual can cover several responsibilities in a small team, provided the work is recognised and time is available.

An owner should be able to answer practical questions. Is this pattern ready for production? Which version is supported? Does the proposed change solve a shared need? Would it break an existing use? Who will update the documentation and help teams adopt it?

Ownership also includes the authority to decline work. A component requested by one project may be too specific for the shared library. It can remain local while the team learns more. Admission to the system creates an ongoing obligation, so the decision should consider future support as well as immediate usefulness.

Make that distinction visible through status. A proposed pattern, an experimental implementation and an approved production component should not be presented as equally dependable. Explain what each status means in the team's context, rather than creating labels that nobody uses.

The owner does not need to personally design or build every contribution. Their responsibility is to ensure that a contribution has evidence, a clear decision and someone accountable for its continued usefulness.

A contribution process should start with a user or delivery problem, not a finished component demanding acceptance. A proposal becomes easier to judge when it identifies the existing pattern, explains why it is insufficient and shows where the new approach is needed.

The GOV.UK contribution criteria ask whether proposed components are useful and distinct, then consider evidence of usability, consistency and support. Those are examples of decision criteria, not a process every company must reproduce.

For a small team, a short contribution record may be enough:

• The task or problem the change addresses.

• The existing approach and why it does not meet that need.

• The proposed behaviour, including errors and accessibility considerations.

• Evidence from relevant use or testing.

• The owner, affected products and expected maintenance.

Imagine an internal purchasing tool that needs an attachment control. One team requires a single file; another needs several supporting documents. The useful question is whether the underlying upload behaviour can be shared while the business rules remain configurable. Combining the two without examining those rules could produce a complicated component that serves neither task well.

Allow the proposal to be refined or rejected. If the evidence is incomplete, document what would resolve the uncertainty. If the need is local, explain why it should remain local. Contributors are more likely to understand a clear decision than an unexplained delay.

The process should improve the quality of the shared decision without making every small correction wait for a formal committee.

A component is not adopted because it has been uploaded to a library. The people expected to use it need to find it, understand it and fit it into their delivery process.

Document the intended use with enough context to make a decision. Show the supported states, the content it expects and the situations where a different approach is needed. Keep the design asset and implementation connected so a team does not unknowingly combine an old specification with new code.

The DWP's design-system guidance makes an important qualification: shared patterns still need to be examined in the context of the service using them. Reuse is a starting point, not proof that every application will work.

Introduce the system through real product work. Choose a suitable feature, support the team implementing it and record where the documentation or component falls short. That feedback can improve the shared asset before more teams depend on it.

Changes need a similar level of care. Explain what changed, which uses are affected and whether a migration is required. A fix that alters field behaviour may require product testing and content changes; it is not simply a new design-file version.

For businesses serving several markets, include localisation requirements in this process. A shared control may need to handle longer labels, different reading directions or legitimate local formats. Record these as requirements and tested limitations. Leaving each regional team to discover them independently undermines the purpose of sharing the work.

The size of the library is a poor measure of success. A smaller set of trusted, well-supported patterns can be more useful than an extensive collection whose status is unclear.

Review whether components are actually used and whether teams repeatedly work around them. A workaround may reveal missing functionality, confusing guidance or a pattern that no longer fits. Investigate before treating it as a failure of discipline.

Retire obsolete components deliberately. Mark the replacement, explain why the old version is being withdrawn and decide how existing uses will be handled. Avoid leaving two apparently approved approaches in circulation indefinitely.

Also review the cost of governance itself. If a minor correction takes excessive coordination, simplify the path for low-risk changes. If unreviewed changes repeatedly break products, strengthen the decision and release process. The operating model should respond to the consequences of the work.

Include those responsibilities when scoping a design system project. A delivery plan should name the first product that will adopt the patterns and the person responsible for maintaining them after handover.

Before commissioning the next library expansion, ask who will use each proposed asset and who will support it after the project ends. Those answers reveal whether the business is building a dependable system or adding another collection that teams will eventually have to interpret for themselves.