Building a design system without pausing the roadmap.

Every developer had built their own version of everything.

HR Duo had grown feature by feature, and each feature had been built by whoever owned it. That meant buttons designed independently in a dozen places, several typefaces in use with no rule about which went where, tables that shared no behaviour, and type sizes chosen per screen. There was no brand guidance to fall back on either — not a thin design system, but no reference point at all.

None of that was carelessness. It's what happens when a product ships continuously and nobody owns the layer underneath the features. Each decision was locally reasonable; the cost only appeared when you looked across them.

The audit wasn't a phase. It was what became obvious while building features.

I didn't get a discovery period, and I wouldn't have asked for one. Working across features surfaced the inconsistencies faster than a dedicated review would have, because I was hitting them as problems rather than cataloguing them as observations.

What mattered was writing them down in a form specific enough to argue about. Nobody funds foundational work on the basis of taste, and "the UI feels inconsistent" is an opinion. The list below is a set of defects.

It started as a dashboard redesign, not a systems project.

Nobody was going to approve twelve months of foundational work with no visible output. So the system didn't begin as a proposal — it began as the main dashboard, which was already on the roadmap and already needed rebuilding.

That screen is where the primitives got decided: the colour palette, the typeface and the scale, the spacing, the first real buttons. Choosing them for a specific screen rather than in the abstract meant every decision had to survive contact with actual content on day one. And because the dashboard was the screen everyone saw first, the argument for the rest of the system had a working reference instead of a deck.

Components crossed feature boundaries. Ownership didn't.

Each developer owned their own feature. But the same button, table and form field appeared across several of those features at once — so no component could be changed inside one person's work without landing in someone else's.

That's the reason rollout took over a year, and it's the thing I'd underestimated. I'd assumed the hard part would be agreeing what good looked like. Agreement was quick. Propagation was slow, because every change had to find a moment in someone else's schedule to arrive.

What changed.

What I'd do differently.

I designed components speculatively. Some were built because they looked like things a system ought to have, not because anything in the product was asking for them. They sat unused. I now promote a pattern into the system only after seeing repeated demand for it — the second or third time a problem appears, not the first time I anticipate it.

I set ownership rules too late. The question that needed answering early was a simple one: at what point does a local pattern become a system pattern, and who decides? Without that, similar solutions evolve independently in different corners of the product, and by the time you notice you're not adding a component — you're reconciling three.

I'd fix that now with lightweight contribution criteria and a design–engineering review at the point of promotion, introduced while the library is small enough for the rules to still be cheap.

My tokens carried role, but not usage. The families were organised by intent — R was error, O was warning — so a colour told you which family it belonged to. What it didn't tell you was what to do with it. R-500 doesn't say whether it's a background, a border or text, so the decision about which step to reach for still lived in the designer's head instead of in the system.

I learned the layer above it afterwards, at Sim Local: naming by usage rather than by family, so surface-danger and text-danger carry their intent through handoff and a contrast fix happens in one place instead of everywhere the colour appears. HR Duo was my first design system, built while I was also introducing myself to the team. Given the same brief now, that's the layer I'd add.

Documentation came last and should have run alongside. Every undocumented component generated the same question repeatedly, and answering it in person doesn't scale past about four people.