Case studyCycode Design System · Enterprise SecuritySenior Product Designer · Owner

The design system: one source of truth

Cycode's product had a design system on paper and chaos in practice — one component existed in a hundred variants. I rebuilt it from zero: atomic, tokenized, governed, and wired into both Storybook and an AI design workflow. I own it.

Product

Cycode — enterprise application security platform (ASPM)

My role

Senior Product Designer & design system owner. Sole creator, maintainer, and reviewer

Scope

Every component rebuilt atomically · tokens & variables · light + dark themes · Storybook · docs · governance

Reach

Source of truth for the whole product org — designers and front-end alike

100→1

variants collapsed into a single component with props — repeated across the whole library

Component architecture

~1h→10m

to build a typical page, after unification — my own estimate, not an analytics figure

Estimate · design + front-end

WCAG

contrast, focus, hit-area, read-only and sizing baked into every component

Accessibility, by default

The problem

There was already a design system. That was the problem. It had grown the way most systems grow when nobody owns them: one button became a hundred near-identical buttons, each hand-made, each slightly different. Designers duplicated instead of reusing, front-end guessed at sizes, and every new screen re-litigated decisions that should have been settled once.

A hundred variants of a component isn't a rich system. It's a system with no rules — and no source of truth. The job wasn't to add to it. It was to tear it down to atoms and rebuild it so that there was exactly one right way to do a thing, and it was the easy way.

A hundred versions of one thing

Components were built as separate variants instead of one flexible component. Change anything and you changed it in a hundred places, or missed ninety-nine.

No governance

Nothing stopped designers or front-end from inventing a new variant whenever they wanted. The library grew faster than anyone could maintain it.

Inconsistent primitives

Even icons came in mixed sizes. Spacing, colour and dimensions were decided per-screen, by hand, over and over.

Slow, question-heavy handoff

Front-end asked constantly — what size, what gap, what colour — because the answers lived in someone's head, not in the system.

The calls I made, and what they cost

Rebuilding a live system means changing the tyres on a moving car. Two decisions defined how.

Decision 01

A hundred variants — or one component that flexes?

The existing library expressed every difference as a new component. The tempting fix is incremental: clean up the worst duplicates and move on. But that leaves the underlying model — "difference means new component" — untouched, and the duplicates grow back.

✓ What I chose

One component, props and variants, rebuilt atomically

I collapsed each family of a hundred variants into a single component driven by props, customisable within the bounds of the product. Built from atoms up — down to standardising icon sizes when parameters change. Using Figma's appearance and variables, with strict styles that pull sizes, gaps, colours and parameters automatically, so a component is correct by construction, not by discipline.

✕ What I rejected

Tidy up the existing variants

Faster and safer this quarter. But it treats the symptom. The model that produced a hundred variants would just produce a hundred more. Cleaning without changing the rules is maintenance, not a fix.

What it cost

A full rebuild is slow up front and touches everything — every screen eventually has to move onto the new components. I accepted a heavier initial investment in exchange for a system that stops degrading instead of one that degrades a little slower.

How it holds

Strict, auto-pulling styles mean a component can't drift off-spec by accident. Correctness is enforced by the system, not left to whoever's in a hurry.

Decision 02

Give everyone freedom — or constrain the variants on purpose?

Once components were flexible, a new risk appeared: if anyone can customise anything, you're back to a hundred variants within a month. Freedom feels generous. Here it was exactly what broke the old system.

✓ What I chose

Bounded customisation — governance by design

I capped the number of variants a component allows, so designers and front-end can customise within the product's limits but can't proliferate freely. The system permits what's healthy and quietly makes the unhealthy path impossible. My components are the source of truth — everything downstream references them.

✕ What I rejected

Full freedom to override

More flexible in the moment, and the exact thing that produced the chaos I was hired to fix. Some freedom is debt with a delay on it.

What it cost

Constraint occasionally frustrates an edge case that genuinely needs something new — that now has to go through me and into the system, rather than being hacked in locally. That's the point, but it's a real cost in the moment.

Related call

I also cut features that didn't earn their place — for example, letting widgets be overridden on pages where they shouldn't appear at all. Less surface, less to maintain, fewer ways to go wrong.

The system

Atomic components, tokenized

Every component rebuilt from atoms up, driven by tokens and variables. Sizes, gaps, colours and parameters pull automatically from the token layer, so a change at the token level ripples everywhere correctly. Two fully tokenized themes — light and dark — from the same source. I even rebuilt the icons as box-icons with uniform sizing, because inconsistent icon sizes were one more thing deciding themselves per-screen.

Component architecture — one component, props and variants

Accessibility, built in — not bolted on

Every component is fully WCAG-compliant by default: contrast, sizing, colour, focus states, read-only states and hit-areas all accounted for at the component level. Accessibility isn't a checklist someone runs at the end — it's a property of the primitives, so anything built from them inherits it.

Accessibility states — focus, read-only, hit-area

Storybook, docs, and governance

The system is integrated with Storybook. I wrote the guidelines, documented usage and variations, and personally reviewed every component — the front-end implementation was refined against my review until it matched. There's global documentation, versioning, logging and audit. Nothing about this is informal: it's a governed system with a single owner and a clear source of truth.

Wired for AI — from code, not Figma

The system carries MD files written for AI, so design can be produced through Claude against the real system. We integrated Claude Design with our design system from the code, not from Figma — meaning AI-assisted work references the actual source of truth, not a drawing of it. This is what makes the AI design workflow (a separate case) trustworthy: it's grounded in the same governed system everything else uses.

Why this counts

Most "design systems" are a Figma library and good intentions. This one is a governed source of truth with tokens, enforced constraints, accessibility by default, Storybook parity, audit, and a code-level AI integration. Building that from zero — and owning it for a whole product org — is the core of what I do.

Mentoring

I mentor a designer on the team — much of it hands-on through the system: how to build components correctly, when to extend versus reuse, how to stay inside the governance. The system isn't just a library; it's how I level up the people working in it.

Impact

I'll separate what I can measure from what I can estimate, because they're not the same thing.

100→1

variants collapsed per component family — a structural fact, not an estimate

fully tokenized themes from one source of truth

WCAG

compliance built into every component by default

Honest about the numbers

The one efficiency figure I'd quote — page build time dropping from roughly an hour to about ten minutes after unification — is my own estimate from working in the system, not a tracked analytics metric. What I can state without hedging: tables and pages became faster to assemble, front-end asked fewer questions and made fewer errors, and there's now exactly one correct way to build a thing. The speed-up is real; the precise multiplier is an estimate, and I'd rather say so than pretend it came from a dashboard.

The durable result isn't a number anyway — it's that the system stopped degrading. Governance means it can't quietly rot back into a hundred variants, accessibility means new work is compliant by default, and the code-level AI integration means the whole thing is usable by both people and Claude against a single source of truth.

Reflection

A requirement I under-clarified

One task shipped working, but I hadn't pushed hard enough on requirements up front — so a lot of edge cases surfaced afterwards and turned into a long tail of revisions. Nothing broke, but "it works" and "it's fully thought through" turned out to be different states. Now I dig into requirements and edge cases harder before I start, because the cheapest place to handle them is before the first component, not after review.

Governance is a feature, not a restriction

Early on it's tempting to leave components open "for flexibility." That flexibility is exactly what produced the hundred-variant mess I was rebuilding. Constraining the system on purpose — capping variants, enforcing styles — felt strict, but it's the single thing that keeps the system alive. I'd build in the guardrails even earlier next time.

Where this connects to AI

Building the system to be AI-legible from code — MD files, a code-level Claude Design integration — turned the design system into the foundation for a whole AI design-ops workflow. That's a separate case, but it started here: you can't automate design against a system that isn't a real source of truth. Getting the system right is what made the AI part possible.