Design governance that designers actually use

That model creates consistency by delay. Squads arrive too late for useful challenge, reviewers become a bottleneck, and exceptions move into private channels. Designers learn to seek approval rather than improve the shared judgement behind a decision.

I think governance should work as a loop, not a gate. The test is not whether every design passed through a central room. It is whether teams can make sound, consistent decisions when that room is absent.

Why boards fail squads

Squad delivery is continuous, while boards are periodic. By the time a review happens, technical choices may be committed and research sessions booked. Feedback then either arrives too late or is reduced to visible details that can still change.

A board also lacks local context by design. It sees the proposed interface but not always the policy rule, operational exception or release constraint behind it. The squad, meanwhile, may not see how its local choice creates inconsistency elsewhere.

The answer is not to remove review. It is to move review earlier, make its purpose clear and connect local learning back to shared patterns. Governance should reduce repeated decisions while preserving scrutiny for choices that are hard to reverse.

Propose, review, adopt, measure

The loop begins when a squad proposes a pattern or a material change to one. The proposal includes the problem, evidence, intended scope, known constraints and examples where it should not apply. A working prototype is usually more useful than a polished specification.

Review brings the right disciplines together while options remain open. Design tests usability and coherence; engineering checks behaviour and cost; accessibility, content, policy or risk join when the pattern needs them. The group checks for one-way doors rather than giving broad permission to proceed.

Adoption turns the reviewed idea into something other squads can use. That may include a component, content guidance, interaction rules, examples and an explicit exception path. The release needs an owner, version and clear account of what changed.

Measurement closes the loop. I look for use across teams, support questions, exceptions, accessibility defects and outcome evidence from the journeys using the pattern. Those signals can confirm the pattern, narrow its scope or send it back for revision.

Ownership without a design police

A pattern needs one accountable owner, but ownership is stewardship rather than authorship. The owner maintains the evidence, convenes contributors, resolves changes and makes the pattern's status visible. They do not become the only person allowed to think about it.

The proposing squad owns the problem and remains involved through adoption. A design system or practice team owns the shared standard and its distribution. Product, engineering and relevant control functions share responsibility for whether it works in delivery.

I standardise when teams repeatedly solve the same problem, inconsistency creates risk or confusion, and the core behaviour survives different contexts. Common form behaviour, validation and permission states are good candidates. Shared evidence should be stronger than a preference for visual uniformity.

I leave decisions local when context materially changes the need, evidence is still emerging or the cost of variation is low. A specialised employee workflow may need room to develop before it becomes a standard. Premature consistency can preserve the first squad's assumptions at scale.

Coaching is part of the system

Documentation can explain a rule, but it rarely teaches judgement on its own. I use office hours, pairing and short critiques to work through live decisions. The aim is to show how evidence and constraints shaped a pattern, not recite its final form.

Coaching also gives the governance team an early warning system. Repeated questions may signal unclear guidance, a missing example or a pattern that does not fit delivery. I treat those questions as evidence about the system, not failure by the designer.

Over time, experienced designers can host reviews and coach others. This distributes both the workload and the reasoning. A central team can then focus on difficult cross-service decisions rather than checking routine application.

What working governance looks like

I do not measure governance by meeting attendance or the number of approved patterns. I look for fewer repeated debates, earlier proposals, shorter paths to a supported decision and fewer avoidable exceptions. Adoption matters, but so does evidence that teams reject a pattern when it does not fit.

The strongest signal is what happens without me. Designers reuse the pattern, explain the reasoning, contribute evidence and raise a change when the context shifts. Review becomes a normal part of making, not a performance staged for approval.

That is how governance scales judgement. It gives teams a tested starting point, a way to challenge it and a route for local learning to improve the whole system. The loop stays useful because delivery keeps changing it.