How to adopt and govern an enterprise design system: clear ownership, shared components, Arabic testing, and measuring value without borrowed ROI claims.
An organisation launches a new digital service every few months. Each team has a tidy Figma file, capable developers and a delivery schedule. Yet customers encounter three different ways to upload a document. One service explains the file limit in advance. Another reveals it after the upload fails. A third loses the information they have already entered.
The organisation has design talent. What it lacks is a shared way to resolve recurring decisions and carry those decisions into working products. This is where design system governance becomes a delivery question: who owns the common behaviour, how does it change, and who makes sure the change reaches users?
An enterprise design system can provide shared components, guidance and a process for maintaining them. Its value depends on whether teams can use that support in real services. To make the discussion concrete, we will follow a hypothetical organisation offering business registration, record renewal and support applications. The examples are proposed ways of working, not reported client results.
Find the repeated decision behind the inconsistent screen
In our example, all three services require documents. Their upload interfaces look different, but appearance is only part of the issue. Each team has made separate decisions about file limits, error messages, removal and recovery. A visual inventory alone would miss some of the most consequential differences.
People may have to relearn the task in each service, and a similar fix request may reach three teams, each analysing the problem and testing a solution again. These are plausible outcomes in the scenario, not measurements of any organisation. Their value is in showing where to look for duplication before proposing to standardise everything.
Start by comparing the task people are trying to complete. Record what they are told before uploading, what happens during processing and what they can do after failure. Review the service rules as well. Two similar screens may handle different decisions; two different screens may need exactly the same behaviour.
Bring support colleagues into the review. A recurring question can point to an unclear instruction that is easy to overlook in a design critique. Ask where the confusion occurs and retain the service context. This gives the team a specific problem to investigate before proposing a programme to standardise everything.
A component library needs an operating model
We suggest treating the system as connected responsibilities:
Design tokens describe shared values.
Components implement reusable interface elements.
Patterns explain how elements work together in recurring tasks.
Documentation makes decisions and limitations accessible.
Governance establishes how changes are reviewed, maintained and adopted.
For the upload flow, a file-picker button is insufficient. Teams need supported loading and failure states, instructions for removing a file and guidance on information to display before selection. They also need a boundary: checking whether a business document satisfies a particular service rule may remain the product team's responsibility.
Carbon's contribution guidance asks for component and pattern documentation covering usage, style, code and accessibility. It provides a useful example of documentation being part of a contribution, rather than an optional follow-up. Carbon contribution guidance
Use a practical test when reviewing your own library: can a team that did not build it choose and implement the right component without arranging another meeting? If essential knowledge still travels through private conversations, identify what needs to be made available at the point of use.
Connect design tokens to the version running in the product
A design token might represent spacing, a text colour or a type size. We recommend names that explain a value's role. When an error colour changes, the team should be able to identify affected uses without searching for a colour code scattered across files.
The shared value also needs a route into production. Specify the agreed source, how code receives the change and how teams identify the version their applications use. Updating a Figma library does not establish that a live service has adopted the same change. Treat that connection as work to be owned and checked.
Before extending the token collection, follow one small change through design, implementation and testing. Observe where people need clarification. If teams cannot tell what changed or how to verify it, resolve that delivery gap first. A larger collection of values will still depend on the same unclear process.
Give changes an owner and a review route
When a team requests a component change, someone must decide whether it belongs in the shared system. Someone must also assess the effect on other services. Name an accountable owner and involve design, engineering, content and research according to the decision. Every contributor need not attend every discussion.
GOV.UK's contribution criteria require proposals to demonstrate usefulness and avoid duplicating existing solutions. Before publication, contributions are considered for usability, consistency and versatility. These are that system's criteria; their logic can help an organisation formulate its own review questions. GOV.UK contribution criteria
In our scenario, support applications may accept several files while renewal requires one. Examine whether that is a clear option within the same component or a different task requiring its own pattern. Bring usage examples to the decision. A preference for fewer components is insufficient evidence either way.
Allow documented exceptions. An older integration may temporarily require different behaviour. Record the reason, an owner and a review point so that the constraint stays visible. This gives a product team a workable route forward while making the temporary choice easier to revisit.
Learn from other systems in their own context
For Saudi organisations, DGA's national design system initiative, Platforms Code, offers relevant local context. DGA describes shared foundations for government interfaces and a common language for designers and developers. Any requirements applicable to a particular organisation should be checked against the official guidance for its scope. DGA national design system overview
Shopify's Polaris documentation describes web components for building experiences within Shopify. That product context matters when considering what to borrow. A system built around a specific commercial ecosystem is not automatically a complete foundation for a government service or an internal platform. Shopify Polaris documentation
Compare candidates through decisions you actually need to make:
Platform support.
Contribution routes.
Usage guidance.
Maintenance demands.
Select a few representative tasks to examine. Separate what can be adopted directly from what needs adaptation and what falls outside your needs. Popularity alone cannot answer those questions.
Test Arabic and accessibility within the service
Include Arabic in the initial test cases. For the upload flow, try long Arabic filenames, messages containing English file extensions and layouts displaying file sizes or reference numbers. Examine reading order and whether errors remain clearly associated with the relevant control. These are suggested checks, not claims about defects in a particular product.
Test the full journey as well as the isolated component. A usable element can become confusing when surrounded by poor instructions or connected to inappropriate feedback. Include keyboard interaction and assistive technology relevant to the audience. Check whether people understand why a file was rejected and what they can do next.
W3C explains that no single tool can determine whether a site meets accessibility standards; tools support evaluation. A successful automated check on a component library therefore cannot establish that every service using it is accessible. W3C accessibility evaluation guidance
Route findings back to the right owner. A recurring error pattern may need a shared fix, while a service-specific rejection reason belongs with the product team. The system can support better behaviour across products, but the complete journey still needs evaluation where users encounter it.
Make design system adoption manageable
USWDS describes incremental adoption through principles, guidance and code. This is a useful reference when planning a transition that does not depend on replacing an organisation's interfaces at once. USWDS maturity model
Begin with one document-upload journey and a team willing to test it. Record the current behaviour, agree on the problem to improve and build the smallest shared solution that addresses it. Note where developers need extra explanation and where users still struggle before calling the trial successful.
Then try the solution in a second service with a different requirement. This is where assumptions about reuse become visible. If that team copies the component and changes it outside the system, investigate why. Missing functionality, unclear documentation and migration effort are all questions worth examining before describing the response as resistance.
Budget for receiving teams. They need time to read guidance, experiment, adjust integrations and test their service. Provide a clear contact during migration. A library that feels straightforward to its creators may require a different explanation for someone encountering it for the first time.
Usage counts tell you the solution reached the products; on their own, they do not prove it solved the user's problem.
Shared components stay consistent when every team knows its part in looking after them.
Measure design system ROI without borrowed promises
Start with measures tied to the original problem. For our example, proposed measures include:
Implementation time for a comparable upload case.
Repeated review findings.
Whether the form preserves entered data after an error.
Users' ability to complete the task.
These are measurement suggestions, not achieved outcomes.
Include the cost of building, documenting and maintaining the shared component, supporting adoption and migrating older implementations. Work saved by a product team may have moved to the system team. A fair assessment considers total effort alongside quality, rather than reporting only how quickly the first screen was assembled.
Define reuse before measuring it. Are you counting every interface element or only those supported by the system? Does use of an old version count? Keep the denominator and inclusion rules stable. Brief conversations with product teams can help explain a low adoption figure more usefully than the figure alone.
McKinsey's research links design performance with financial performance across its sample, but studies design more broadly than design systems. It does not establish that installing a component library will produce a particular revenue increase or cost reduction. McKinsey research on the business value of design
For a more useful internal comparison, record the complexity of the tasks being compared. A simple upload field and a regulated document review flow are not equivalent units of work. Note other changes during the trial, such as staffing or backend improvements, so that the team can describe what the evidence supports without attributing every improvement to the system.
Do not collect indicators just to fill a monthly report. Decide which decision each one will change. If adoption is low because migration is expensive, teams may need migration support. If adoption is high but complaints about the task continue, review the behaviour itself or the part that stayed outside the system. Usage counts tell you the solution reached the products; on their own, they do not prove it solved the user's problem.
Keep the baseline notes next to the trial results. Teams may remember the old state as worse, or better, than it was. A specific description and comparable steps support a calm discussion about continuing or adjusting, and tie the next budget request to clear learning.
Keep responsibility alive after the first release
Publish each component's support status and a route for reporting issues. When behaviour changes, explain the effect on existing implementations and the steps needed to move forward. A release announcement is useful only if teams can understand whether they need to act.
If the upload component receives a fix, track whether dependent services receive it. The corrected library and the live product may be on different versions. Following the change through to adoption makes the relationship between system work and user experience visible.
As teams use AI to generate interfaces, we recommend providing approved components and examples as references, then reviewing the output through the same process. Do not assume that recognising a system's name means using the right version or selecting an appropriate pattern. Faster generation still requires decisions about suitability and integration.
Decide what should remain outside the shared system
Not every repeated screen element needs to become a shared component. Similarity may be temporary or depend on a service rule that differs between products. In our example, upload progress can be shared while the decision to accept a company's document stays with the service. Bundling both together may burden unrelated products with specialised logic.
Ask contributors to describe the task, the gap in the existing solution and another relevant use case where available. Test the proposal in its original context. A limited experiment can remain outside the stable release while its usefulness and boundaries become clearer.
Apply the same distinction to content. The system can explain how an error message identifies a problem and offers a next step. The product team, working with the owner of the service rule, should supply the precise rejection reason. Shared guidance should help users understand meaningful differences between services.
When priorities conflict, examine the consequence of waiting. Which services are affected? Is someone prevented from completing a task, or is this a minor visual improvement? Could one team make a temporary local fix? Record what the next release will exclude and why, so that other teams can plan around an explicit boundary.
Fund a first outcome, then an ongoing responsibility
Before approving a design system programme, ask for:
A documented shared problem.
An initial journey.
An operating owner.
A way to assess progress.
Include support and maintenance in the budget. A long component backlog is less useful at this stage than a clear explanation of how one recurring problem will be addressed.
In our hypothetical business services, success means people understand what to upload and teams can implement and update the right behaviour. Similar-looking screens are only part of that outcome. A design system earns its place when the organisation can use it, question it and keep improving it as products grow.
Explore the report
The AZMX report introduces design systems, their constituent parts and related examples. Use it to begin a team discussion, and consult original sources when assessing figures or preparing a cost estimate.
