Design Systems as Governance, Not Just Component Libraries…

What building one alone, for a service-based company juggling very different clients, taught me about the word nobody wants to say out loud: governance.

I still remember the Teams message that started it. One of our developers, working late to match a client’s deadline, sent me a screenshot of three different “primary buttons” living in the same live product. Three different corner radii. Two different shades of blue that were both, technically, “brand blue.” None of them wrong on their own. All of them wrong together.

I was the only designer at Tedekstra, a service-based company that took on very different clients at the same time — a B2B fintech dashboard for one client, a B2C mealtech app for another, a booking platform for a third. No design team to lean on, no second opinion two desks away. Just me, moving between projects that had almost nothing in common except that I was the one designing all of them, and a rotating cast of developers who each inherited whatever decisions I’d made under deadline pressure.

For a long stretch, my process looked like most solo designers’ does: a fresh Figma file per project, a component built here, a slightly different version rebuilt there, and a quiet assumption that consistency would just… happen, because I was reasonably careful and had reasonably good taste.

It doesn’t happen. Not on its own, and definitely not across three unrelated client codebases. That Teams message was the moment I stopped believing it would.

One product, fourteen ‘primary’ buttons — none of them wrong alone, all of them wrong together.

The word I kept avoiding: governance

Somewhere early on, I’d absorbed the idea that a “design system” meant a tidy component library — buttons, cards, a color palette, sitting neatly in a shared file. So that’s what I set out to build. It took maybe three weeks of actual client work before I realized the library wasn’t the hard part. The hard part was deciding who was allowed to change what, and when — especially when “who” sometimes meant a different developer on a different client project every single week.

Nathan Curtis, a design systems consultant who’s spent years advising teams on exactly this problem, describes a system as something closer to a shared language and a framework for making design decisions across an organization — not merely a UI kit. That distinction rewired how I approached the whole thing. A button component doesn’t govern anything by itself. A rule for who decides when a new button variant is genuinely needed, versus when someone’s just impatient on a Friday deadline, governs something.

Once I stopped thinking “component library” and started thinking “decision-making framework,” the actual questions I was asking changed. Not “what should this dropdown look like,” but “when a client’s brand guidelines conflict with our accessibility standards, who has the final call, and how do we document that so I’m not re-litigating it on the next project?”

The real work: building it with developers, not just for them

Here’s the part I’m proudest of, and also the part that nearly didn’t happen: the system only worked because I built it alongside our developers, project by project, not as a polished handoff document I threw over a wall and hoped would be followed.

I started with something almost embarrassingly simple — an audit. I opened every live product I’d shipped across our different clients and just counted. Fourteen button styles across three unrelated codebases. Nine different spacing values that were all “supposed to be” the same 8px grid. Multiple separate implementations of a date picker for booking flows, each with its own bugs, each requiring its own QA pass every time a client asked for even a small tweak.

That audit became my argument. Not “trust me, a design system will help” — a hard sell to any developer under deadline pressure — but a literal spreadsheet showing how many engineering hours were being spent rebuilding the same dropdown for the fifth time, for three different clients who’d never even talk to each other.

Same button. The difference is who decides, and when.

Chris Jacobs, a principal product designer who’s spoken about this exact dynamic, put it simply: once engineers and designers are finally speaking the same language, it changes how a team ships, not just how a file looks.

That was precisely it. My design system’s real success metric was never “does it look cohesive in Figma.” It was: how many messages do I not have to send anymore, explaining to a new developer which shade of blue is actually correct.

Get Shreyasi Dutta’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Together, we built tokens for color, spacing, and typography that lived in code, not just in a design file — so “primary blue” was one value, referenced everywhere, changeable in one place regardless of which client project pulled from it. We agreed on a lightweight rule: any new component needed one real usage case from an actual project, and a quick sign-off between me and whichever developer would be maintaining it. Small governance. Not bureaucracy — just enough friction to stop the fourteen-button-styles problem from quietly happening again.

What changed, concretely

Within about four months, the effect was hard to argue with:

• New client work started faster, because the first sprint stopped being “design fifty basic components from zero” and started being “adapt the existing system to this client’s brand.”
• QA time dropped noticeably, because a bug fixed in the shared date picker component was fixed everywhere it was used — not re-discovered client by client.
• Handoffs got shorter and less personal, because disagreements stopped being “I think your button looks better than mine” and became “does this fit our documented spacing scale, yes or no.”
• New developers rotating onto a project ramped up faster, because there was finally one place — not scattered emails, Teams messages, and my own memory — that explained why things were built the way they were.

That last one surprised me the most. I hadn’t set out to build an onboarding tool. But a real design system, done with any rigor, ends up teaching whoever joins next the reasoning behind decisions, not just the decisions themselves — which mattered enormously when I couldn’t rely on a stable team to carry that context forward.

The page that finally explained why — not just what.

The book that named what I was actually building

I found Brad Frost’s Atomic Design a little after I’d already stumbled into most of these lessons the hard way, and reading it felt like someone had been quietly watching over my shoulder the whole time. His advice for getting a system adopted inside a real organization, rather than left to rot in an unused Figma file, is refreshingly unglamorous: make a thing, show that it’s useful, make it official. No grand governance rollout on day one. No permission slip. Just proof, first.

That’s almost exactly the order I stumbled into by accident — the audit spreadsheet, then the first shared button component quietly saving someone real time, then, only after people wanted it, the lightweight contribution rules. Governance that gets imposed top-down before anyone’s felt the pain it solves tends to get quietly ignored. Governance that shows up right after everyone’s already annoyed at the chaos tends to stick — even when “everyone” is just you and whichever developer is on call that week.

If you’re a solo designer about to build one

A few things I’d tell the version of myself who got that Teams message about three different primary buttons:

1. Start with an audit, not a component. You need the evidence before you need the solution — it’s what gets developers on your side, especially when you don’t have a design team to back you up.
2. Decide who owns decisions before you decide what the decisions are. A beautiful button library with no clear owner will drift back into chaos on the very next project.
3. Build the governance rules as light as they can possibly be. Enough friction to prevent chaos; not so much that a busy developer routes around you.
4. Treat developers as co-authors, not downstream recipients. As a solo designer, they’re often the only continuity you have across projects — the system only survives if they actually believe in it too.

The three buttons eventually became one component with clearly documented variants. More importantly, the conversation changed — from arguing about a shade of blue, to agreeing on who gets to decide the next time a genuinely new shade is needed. That’s not a component library. That’s governance. It just happens to be wearing a Figma file as a disguise.