August 2026 · 5 min
Promotion, not proliferation
You build a design system. You write the governance. You get adoption. Then the thing that undoes all of it is the place where your team explores.
The failure mode of an internal design studio is a second, undocumented design language. Not through carelessness, but through success. Prototypes get built, someone likes one, it ships, and a component nobody registered is now in production carrying conventions nobody validated. Repeat for eighteen months and you have two design systems, one of which has no owner.
The instinct that makes it worse
The usual response is to lock exploration down: prototype only with registered components. This fails in a predictable way. Exploration that can only use existing components can't discover that a new one is needed. You've protected consistency by disabling the thing that keeps the system relevant.
The studio has to be permissive. The path out of the studio is where the control belongs.
Four gates, default no
- Explore. Anything can be tried. It's flagged experimental, and it stays flagged.
- Validate. Evidence of a recurring problem, plus a working build.
- Standardise. Becomes a documented pattern, with states, accessibility and metrics.
- Componentise. Only if a genuinely reusable primitive is required.
Every promotion diagram I've seen shows things flowing left to right through the gates. That illustrates the wrong thing. Most candidates are supposed to stop. The rejects are the content. A funnel where everything reaches the end is a conveyor belt, and a conveyor belt from exploration into the design system is exactly what you were trying to prevent.
The word that carries the gate
Recurring. At the Validate gate the question isn't "did this work?" but "has this problem appeared more than once, in more than one place, for more than one team?"
One screen needing something is a screen requirement. Three screens needing it is a pattern. Almost all system bloat is a one-screen requirement that got promoted because it was well designed. Quality isn't the criterion. Frequency is.
Marked deviation beats forbidden deviation
The companion rule: if a prototype departs from the pattern library or the component system, the deviation is marked, with a reason.
That beats forbidding deviation for two reasons. It stays honest, because people will deviate anyway and the only question is whether you find out. And it produces what the system needs: a list of marked deviations is a ranked list of where the system is failing its users.
A studio with no deviations isn't a compliant studio. It's a studio nobody uses for anything hard.
Model the learning, not the artefact
One more choice makes the gates enforceable. Alongside the obvious objects (project, prototype, screen, version), four are first-class: evidence, decision, deviation and candidate pattern. Most prototyping tools model artefacts. Modelling these four means a prototype can't be separated from why it exists, the calls made inside it, where it broke the rules, and what it proposes. So the Validate gate has something real to check.
The summary
Design the incubator and its containment at the same time. An exploration environment without a promotion model is a slow leak in every system above it. And a promotion model that never rejects anything isn't governance. It's paperwork attached to a conveyor belt.