Design System Governance: Ownership, Contributions and Safe Exceptions

A design system becomes hard to use when teams cannot tell who owns a component, how to request a change or whether a local variation is acceptable. Governance gives those decisions a clear route. It should help teams solve user problems without turning every unusual requirement into a permanent shared component.

Make ownership visible

Assign an owner for the system and for each shared component or pattern. The system owner maintains the contribution process, release schedule and decision record. Component owners keep guidance and implementation aligned, review defects and identify teams affected by changes. Contributors bring the user problem and evidence; they need not arrive with a finished component.

Put ownership where people use the system. A component page should show its status, maintainer, supported uses, known limitations and feedback route. Update it when responsibility changes. Otherwise, the listed owner may no longer be able to make a decision.

Define decision rights too. A product team can use a documented option without seeking approval. A change to shared behaviour needs review from the component owner and relevant design, engineering and accessibility colleagues. The system owner decides whether the result belongs in the library and when it can be released. The GOV.UK Design System contribution process shows one way to assign a contributor contact, review work and make a publication decision. A smaller team can use fewer steps while keeping those responsibilities explicit.

Start with the need

A request should describe the task, where the current system falls short and what the team has observed. Include the affected users and product, relevant screens, components already considered, accessibility concerns and any deadline. Mark assumptions clearly. “We need a new card” gives reviewers less to work with than a description of why people cannot compare two options using the available pattern.

Search the library and open requests before designing an addition. The gap may be an absent example, unclear guidance or a missing documented option. If several teams have local solutions, compare the user tasks and behaviours rather than their appearance alone. The GOV.UK Design System contribution criteria consider whether an addition helps multiple teams, differs from existing options and has sufficient evidence for publication.

Leave the outcome open. Reviewers may recommend an existing component, better documentation, a shared change or a local exception. This keeps the request focused on the user need instead of defending the first proposed solution.

Keep a small decision record beside the request. Note the options considered, the evidence used, who made the call and any question that remains open. If the decision changes later, add the new reason instead of erasing the earlier one. Teams can then see whether a pattern was rejected because it was unsuitable, insufficiently tested or simply outside the current scope.

Choose a proportionate response

• Configure an existing component when its documented options and states cover the task. Test the result with realistic content and preserve the component’s meaning and interaction.
• Propose a shared addition when the need recurs across products and the library cannot meet it safely. The addition might be a supported variant, a pattern or clearer guidance rather than new code.
• Document a local exception when the task is specific to one workflow or evidence for reuse remains weak. Give the exception an owner, narrow scope and review trigger.

For example, a team needing a compact status display should first check whether the existing component supports the required labels and states. If several products need the same new state, propose a shared change. If one specialised workflow gives status a different meaning, keep its treatment local while testing it. Similar appearance does not make unlike interactions interchangeable.

A shared component also brings maintenance: implementation, design resources, examples, tests, guidance and future migration. Include that cost in the decision. Forcing an unsuitable component into several products can create its own maintenance burden through local workarounds.

Prioritise requests by the harm caused by the gap and the number of teams affected, then check the work required to resolve it. A small documentation correction may unblock a team sooner than a large new component. An accessibility defect in a widely used pattern may need attention before a popular feature request. Publish the order of work and the reason for it so contributors know what to expect.

Review the work people will use

Agree review criteria before implementation. Check whether the proposal supports a defined task and works with realistic data. Examine content, keyboard interaction, focus, errors, narrow layouts and longer text where relevant. Record what was tested and what remains uncertain. Accessibility concerns need a resolution, not a label saying the work was reviewed.

Assess whether the addition fits existing tokens and conventions without losing behaviour the task requires. Can another team apply it without copying the original screen? Are its options understandable? Guidance should explain when to use it, when to avoid it and what consumers must provide, such as labels or error messages.

Keep proposal and release states distinct. The U.S. Web Design System component lifecycle separates proposal, development, release, deprecation and retirement. A simpler set of labels can work if each tells teams whether they can adopt a component and what may change. Finish each review with a recorded decision, reason and next owner. If more evidence is needed, name the unanswered question.

Record exceptions without creating new standards

An exception is a deliberate response to a constraint. Record the user need, why the supported option fails, where the exception applies, who owns it and what would prompt reconsideration. Link the record from the product work and relevant system guidance. Other teams can then see why the difference exists without assuming it is a supported variant.

Useful review triggers include a second team needing the same behaviour, a change to the shared component or new accessibility evidence. Some exceptions will remain local because the task is specialised. A date can prompt review, but a trigger explains what might change the decision.

Local solutions still need to meet the product’s accessibility requirements. If the shared component cannot support the task accessibly, tell its maintainer. Resolve any barrier in the proposed local solution before relying on it; approval of an exception does not resolve an interaction defect.

Release changes teams can follow

A shared change is ready for teams only when its implementation, guidance, examples and design resources agree. A release note should say what changed, who is affected and whether they must act. An added option, changed default and removed behaviour each require a different response.

For changes that may break existing uses, show the old and new approach and what teams should check in their products. State how long the old behaviour remains supported if that has been decided. Send the information through the channels teams already use for system updates.

Before release, test the documented examples against the shipped implementation. Check that names, options and states match across code and design resources, and that an existing consumer can follow the migration instructions. If a required check has not been completed, record that limit and decide whether the change is ready. A release label should reflect the evidence available to adopting teams.

Deprecation also needs a path. Explain why a component should no longer be chosen, identify a replacement where one exists and tell current users what to do. Keep guidance available while teams assess existing implementations. Remove the component after affected products and owners have a clear next step.

Keep the process usable

The operating flow can stay short: submit the need, check existing options, choose a route, review evidence, record the decision and publish any shared change with guidance. Let documentation fixes move quickly. Spend more review effort on behaviour, accessibility and migration risk.

Review open requests, local exceptions and components with uncertain status at regular intervals. Repeated requests may reveal missing guidance or a shared need; unused options may need simplification. Close each review with an owner and a decision so teams know what to use next.