The Pilot Phase

Season 1 · Episode 4 · 8 min read

Every design system team wants to launch.

Not a component. Not a token. The system. All of it. At once. A full component library. A documentation site. A contribution model. A governance framework. A Slack channel. A launch email. With three exclamation points.

I have watched engineers receive a design system launch announcement with genuine warmth. Compliments in Slack. A few heart reactions. Comments about how much work clearly went into it. And then nothing. Because by the time the system was ready, many engineering squads had already shipped. The design system arrived in their inbox after the product had already left the building.

The friendship was real. The adoption was not. Both things were true simultaneously, and the launch metrics looked fine because nobody was measuring the right thing.

In large organizations, this is not an exception. It is the default pattern. Build first. Design after. The system is created in one timeline and handed to a team operating in a completely different one. The pilot — the deliberate, small, production-tested proof of concept — never gets tried. Not because it's a bad idea. Because the organizational structure never creates the conditions for it.

The Big Launch Is the Slowest Path to Adoption

The belief that a design system earns trust by being comprehensive is the most expensive mistake in this field.

Six months of work. One team. A documentation site that seventeen engineers visited. Fourteen bounced in under thirty seconds. Three filed requests for components that already existed.

The system had everything. Except credibility.

Credibility is not built in a launch. It is built in a sprint.

Trust is not earned by comprehensiveness. It is earned by reliability. And reliability requires evidence. One component. In production. Working exactly as promised. Worth more than two hundred components in a file nobody opens.

You do not earn adoption by building more. You earn it by proving the contract works.

What the Pilot Phase Actually Is

The Pilot Phase is the deliberate decision to start smaller than feels comfortable and prove something real before scaling anything.

Not a compromise. Not settling for less. The fastest path to the full system. Because the alternative — building everything before proving anything — has a known outcome. Seventeen visitors. Fourteen bounces. Three confused engineers.

The Pilot Product has three criteria. In this order.

Criterion 1 — Engineering Has to Want It

Not tolerate it. Not accept it. Want it.

Find the engineering squad that is actively solving a UI problem your system already solves. Offer to solve it for them. Not with a library. With one component. In their codebase. On their timeline.

If no engineering squad wants what you are building — you do not have a product problem. You have a discovery problem.

Criterion 2 — It Has to Ship Into Production

Not staging. Not a prototype. Production.

Where real users interact with it. Where real bugs surface. Where real performance constraints apply. Production is the only environment that tells you whether the contract between design and engineering actually holds.

Everything before production is rehearsal.

Criterion 3 — It Has to Be Measurable

After the component ships — you measure. How long did implementation take? How many design review cycles were needed? Did the component behave the same in the codebase as it did in the design file?

These numbers become your first evidence. The evidence you bring to the next engineering squad. The evidence that turns a design system from a belief into a business case.

Build With Them, Not For Them

Building for engineering means delivering something and hoping they use it. Building with engineering means co-authoring the thing they already need.

Co-authors don't abandon their own work. They advocate for it.

The Quick Win: One Question This Week

Identify one engineering squad. The smallest possible unit. Ask them one question:

"What UI component are you building right now that you wish already existed?"

That answer is your Pilot Product. Build it with them. Ship it into their production build. Measure it. That is your first evidence. Everything after that is scale.

The Argument

A design system that lives in Figma is a promise. A design system that ships into production is evidence. The pilot phase is how you convert one into the other — before you've built the whole thing.

Disagree loudly. Inspire boldly.

And remind me — falsely if needed — that somewhere a design system component shipped into production on the first try.

How did your design system first get used in production?