When you’re the founding designer at a company scaling toward an 8+ product portfolio, consistency isn’t a nice-to-have — it’s the only way one design practice can cover that surface area. Every product team building its own buttons, tables, and chat interfaces means duplicated effort, drifting quality, and an engineering handoff that starts from scratch each time.

Trinity also had a problem most design systems don’t address at all: its products are increasingly AI products. There was no shared pattern language for chat threads, model reasoning, citations, or explainability.

I framed the system as a product with its own users — engineers shipping screens under deadline, designers picking up new domains, PMs who need to know what’s possible. The question I optimized for wasn’t "what’s the right shade of blue?" It was "how do I make the right shade of blue the path of least resistance?"

Architecturally: a token architecture feeding modular bundles, feeding 100+ React + CSS components, 17 chart types, and 18 custom hooks, all distributed as one versioned npm package. Storybook is the single source of truth, with a synced Figma library — designers and engineers build from one foundation, and the handoff gap disappears.

On evidence: this is the one project where my proxy users were the real ones. The system’s users are Trinity’s own engineers, designers, and PMs — the people I sit with every day, whose complaints arrive unfiltered. Distribution is observable too: npm reports ~510 weekly downloads of the package across 38 releases. What I don’t have is the harder measure. A download is not a team, a component imported is not a component used as intended, and a forked copy in someone’s branch looks identical to compliance from the outside. The closing section names what I’d instrument.

Evidence base — daily contact with the system’s actual users · design critique · adoption review with product teams · npm download and release counts. Per-team usage not yet instrumented.

A synced Figma library is easy to claim and hard to keep true. Ours is held together by a mapping file: 86 components resolved from their Storybook story to a specific Figma node, so a component in code has one — and only one — counterpart in design.

The library is organised the way people actually build: atoms for single elements, patterns for Trinity-specific composites, templates for whole pages. A navigation guide turns the awkward question — "which page do I even open?" — into a lookup table from what you need to the exact component that provides it.

Drift is caught by CI rather than by memory. Scheduled jobs check Figma coverage against the component list, refresh snapshots, and inject design links back into Storybook, so the gap between the two shows up as a failing check instead of a surprise in review.

The people who most need a design system are often the ones least equipped to use it — a product owner sketching a concept, an engineer on an unfamiliar surface, anyone who needs something on-brand by Thursday. Component libraries don't help them much. Prompts do.

So the system ships an agent guide: a set of instruction files you load once into whatever AI tool you already use, plus prompts you paste when you want something built. Three files, one job each — system rules that stay loaded, a new app prompt, and a migration prompt for an existing codebase that needs to become Trinity.

Setup is written per tool, because that's where people get stuck: drop the file in the project root for Replit, save it as .cursorrules for Cursor, as .github/copilot-instructions.md for Copilot, or paste it as the first message in Claude or ChatGPT. There's a slimmer variant for chat windows where pasting a long file is painful.

The system is the reason a UX function of 3 senior designers plus 2 contractors can set direction across an 8+ product portfolio — and the reason Trinity’s AI products share one coherent language of trust.

Most numbers in the outcome above measure what the system is. The npm downloads are the exception: they show the package is being pulled, but not by which teams or how it’s used. None of them measures whether the system is working. These four would.