Harbor Design System

I was hired in February 2024 to build The Trade Desk's first design system. There was no system, no team and no name. Two and a half years later it was ninety-seven components carrying 2.76 million live instances, and 99.9 percent of the time a designer inserted one, they used it exactly as it came.

The product was carrying four design languages at once: Classic, Megagon, Solimar and Kokai. They were not competing proposals. Each had been layered on top of the last, and nobody had ever gone back to clean up the one underneath.

So an engineer who needed a button had several versions to choose from and no way to tell which was right. A designer who needed something the languages did not cover built a one-off, and that one-off became the fifth version of whatever it was. Every new feature took longer to ship than the one before it, and was harder to maintain after it shipped.

That is the whole problem, and it is not a taste problem. Nobody was arguing about how a button should look. They were picking from a shelf where five things had the same label.

The job was to build one source of truth and retire the other four. Not a new language for the languages to agree on, and not a layer on top of what was already there, because a layer on top is exactly how the company got four.

Three constraints made that harder than it sounds. The product could not pause, because seven feature teams were shipping in parallel the whole time. There was no design system organization to inherit, so I was building the team, the process and the components at once. And engineering ownership sat in a different group, which made this a two-sided product from the first day: anything we defined had to land in design and in code, run by two teams with two release cadences.

I ran the workshop that gave it the name. Harbor.

Then foundations before components: color, typography, icons, elevation, and a spacing scale in multiples of eight. That order is unglamorous and it is the only one that works. Every component reads from the primitives, so if you start with the components you are building the same inconsistency again in a nicer font.

Brad Frost's line was on my whiteboard from day one:

He is right, and that is not a complaint about product teams. It is the thing to design around. A system that depends on other people caring about it as much as you do will not survive its first hard deadline.

So we wrote the governance model before we had enough components to need one. Ownership was named, so nobody had to ask who decides. Every component got a two-week feedback window, so review was a scheduled part of the work rather than a favor somebody had to chase. And publication was a ritual rather than an event: the changelog, the channels and the newsletter, every time, in the same order. Publishing a component is not the same as telling anyone about it, and the second one is the part that gets skipped.

The nesting is the argument. Governance is not a process that sits beside the design system, it is the thing the design system lives inside. Everything in the middle is what people mean when they say design system, and none of it survives without the layer around it.

Three designers were assigned to me at hire. One left, one transferred, and I hired a replacement. Four contractors came through at various points, never more than one at a time, all reporting to me. So the working shape of Harbor for most of its life was three people maintaining a system for seven product teams, and that constraint is behind nearly every decision on this page.

The partner program is the piece I would take to any system I build next. Three designers cannot sit in seven teams' planning, so we built a network of cross-functional advisors, one set of eyes per consuming team, who saw a component before it shipped rather than after. It cost the program almost nothing and it did two jobs: it caught the problems that only show up in a team's real context, and it meant that by the time a component published, somebody on each team had already seen it and had a reason to use it.

Access was a governance decision rather than a license. Documentation access was request-based and I approved every request myself, scoped to UX and engineering, to hold us at the ninety monthly actives we had licensed. 873 people asked and were approved. About 92 were in it in a given month. Those two numbers answer different questions and the ratio between them is not an engagement rate: 873 is demand, and 92 is sustained use.

And the roadmap ran on measurement. I built a usage reporting cadence on top of Figma's component analytics: what is being inserted, what is being detached, what has gone dormant. Detach data turned out to be the most useful thing in it. A detached instance is a designer pulling a component off the library because it would not do what they needed, which tells you more, and faster, than an interview would.

Read the detach rate first. 188 detaches against 164,725 insertions means that 99.9 percent of the time the component was used exactly as it came, and 89 of the 97 components were in active use rather than sitting in the library being counted.

Component count says what you built. Detach rate says whether anybody believed you.

The forty-hour hypothesis asks one question: what if each of the seven teams had built its own library instead?

Three assumptions, all of them arguable and all of them stated: forty hours to build one component from scratch, seventy-five dollars an hour, seven teams.

The arithmetic is deliberately visible. Change any of the three assumptions and every number moves, which is what a model is. I put it after the detach rate on purpose: the detach rate is a measurement, this is an argument.

Governance is the product. The components are the obvious deliverable. The durable value is the process: who decides, who reviews, who tells people. When teams trust the process they stop building workarounds, and a workaround is where the fifth button comes from.

Adoption is a campaign, not an announcement. Publishing a component does not mean anybody finds it. We were standardizing a 30, 60 and 90 day adoption ritual by the end, and it should have existed on the first day.

A two-sided product needs two-sided rituals. Getting the design changelog aligned to engineering's release cadence took real work, and it is the difference between a design system and a Figma library.

Two years in, the whole visual language changed. Harbor had to wear a new one, across ninety-seven components and millions of live instances, without asking anyone to go back and rewrite their work.

This is the short version. The full case study carries the documentation architecture, the screenshots and that second story, and it is password protected.