Design System Governance

Teams kept watching their screens drift apart within six months of shipping a design system. A design system pulls everything from color and spacing values to buttons and input fields under one shared standard. Everyone follows that standard at first. The trouble starts the moment someone needs a screen the system doesn't cover.

At that point one of two things gets said. Either "can I add this to the system?" — asked into a room where nobody is responsible for answering, so the person quietly builds a button inside their own file — or the opposite, where a single person owns every change and a two-week queue pushes everyone else to work around them. The outcome is identical either way. Parts start living outside the system, and a year later the product has four different button heights.

Building parts well and keeping those parts on one standard turn out to be different skills. Governance handles the second one. It moves the judgment calls out of individual diligence and into a written rule.

Five things need deciding. A single page is enough, as long as that page answers these questions.

1. Who decides. Two shapes are common: a central model where a dedicated pair judges every change, and a federated model where representatives from each team decide together. Below about 50 people, this is usually one designer and one engineer working as a pair.
2. Where requests arrive. One channel, one form. The form asks which screen needs the part and why the existing parts don't cover it. Filling that in filters out the cases an existing variant already handles — a variant being one of the several forms a single part takes depending on its role.
3. What qualifies for inclusion, written as a number. For example, a part enters the component library only when two or more separate teams need it and it will appear on at least three screens. The component library is where the buttons, modals and other screen parts get built once and kept. Without a stated bar, the answer depends on who is asked and what kind of week they're having.
4. How changes get announced. Editing the color or padding of an existing part changes every screen already using it. So separate the changes that only swap a value from the ones that change how something looks, and give the second kind a notice period. Changing the value behind a design token — the named smallest unit for a color or spacing value — belongs in this category too.
5. How exceptions work. Someone will build outside the system to hit a deadline; that isn't preventable. Instead of banning it, attach an expiry. Anything built as an exception goes on a list and either joins the system or disappears by the end of the next quarter. The list matters more than the rule: it's the only record of what the team has quietly agreed to owe itself.

Once those five are set, check once a quarter whether they actually held. An exception list that keeps growing instead of shrinking is a sign the rules don't match how the team really works.

There's a point where this becomes worth writing down: roughly when two or more teams use the system and the part count passes twenty. On a team with two designers and one product, asking the person next to you is the governance, and a document is dead weight. With three products and six teams and no rules, the same part gets built three times — three date pickers that behave differently, each with its own bugs to fix.

Pick the model by request volume rather than headcount. Two or three requests a month move fastest through a central pair. Several a week need judgment distributed, or the pair becomes the bottleneck. And once requests queue up behind one person, teams don't wait — they route around.

The limits are worth stating plainly. Heavy rules don't survive contact with deadlines: a ten-field request form and a two-week approval means everyone builds quietly in their own file. Without protected time, only the document survives; unless someone's week explicitly includes a few hours for this, their own product schedule wins every time. And governance says nothing about whether a part is any good. It settles who changes what and when, while whether the part itself holds up is a question for the component spec — the document listing a part's properties, states and rules — and for review.

"Only one team needs this, so keep it in their file instead of the library."

The inclusion bar was applied, and this part didn't clear it.

"It's a token value change, so I'll announce it and ship it in two weeks."

The change touches every screen, which is why it gets a notice period.

"Fine to build it as an exception, but please add it to the list."

Let it through now, and record it as something to clean up later.

At Pagedeck the problem surfaced about a year after the system launched. Three teams used the parts Noa had built, every request arrived as a direct message to Noa, and during busy weeks replies slipped by three days. Teams that got tired of waiting built their own near-copies, and six months later the product had five kinds of input field.

Noa and Theo wrote a single page and pinned it. Requests come through one channel. A part enters the library only when two teams need it. Exceptions go on a list and get cleared quarterly. The two of them judge together, and they answer within two days. After that, Mia stopped having to ask who to talk to when a new screen needed something.

The most common misreading is that governance is an approval gate. The word sounds like control, and someone is in fact assigned to decide, so the impression is understandable. But the point is to open a path, not to block one. Rules that only block get routed around, and once that becomes habit, more parts live outside the system than inside it. A promise to answer within two days does more work than ten lines of approval criteria.

The second is thinking the document is the job. A rule is alive only while it's being applied. If nobody reads the exception list, in six months that list is an itemized statement of design debt — the cleanup cost that accrues from postponing consistency. Thirty minutes a quarter spent reviewing the list beats any amount of time spent polishing the wording of the rules.