semantic tokens, rendered from the source of truth
The Problem
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.
Most design systems stop at buttons and forms. This one needed a vocabulary for how AI earns trust.
The Approach
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+ accessibility-compliant components built in React + CSS. Storybook is the single source of truth, with a synced Figma library — every designer and engineer builds 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. What I don’t have is the harder measure. 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. Usage not yet instrumented.
1 / 11Tokens to templates to the AI module
Key Decisions
A token architecture that separates intent from value
Four layers — base → semantic → component → dark-mode. A designer picks text.primary or surface.elevated; the system handles the rest.
Modules, not a monolith
Seven independent bundles — tokens, theme, forms, data, charts, navigation, ai — so a product pulls only what it needs. The library shrank from 169 MB to 261 KB between releases: a 99.85% reduction.
AI as a first-class module
Most design systems treat AI as someone else’s problem. This one ships a dedicated AI module — chat threading, reasoning chains, citation panels, related-question suggestions, explainability surfaces.
Storybook as the single source of truth
The coded component is the canonical component. A synced Figma library keeps design and engineering looking at the same thing; token-aware linting catches hardcoded values in PR review.
Extended into AI prototyping
Replit and Perplexity skills integrations, a guide, and a prompt library let product teams generate on-brand prototypes fast.
The Modules
M-01 · Tokenscolors, spacing, typography, shadows, easing — the foundation every module rests on
M-02 · Themetheme objects, CSS-variable generation, light + dark modes
M-03 · Formstext fields, comboboxes, file upload, rich text — built for dense, regulated workflows
M-04 · Datadata table, transfer list, tree view — three density modes for how enterprise reads tables
M-05 · Chartsline, bar, area, pie, scatter, radial, composed — brand spectrum for distinction, semantic for status
M-06 · Navigationtop nav, sidebar shell, breadcrumbs, drawer — the bones of every Trinity product
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 Figma library, mapped to the same names as the code
parity tracked in the open: the icon page names its own gaps against the React source
Building With AI
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 stops being a library you have to know how to use, and becomes an instruction the tool already understands.
the agent guide, shipped inside the design system itself
setup written per tool, with the instructions downloadable or copied in one click
Outcome
99.85%bundle-size reduction between releases — 169 MB → 261 KB
100+accessible UI and AI components in React + CSS, with 74+ interactive Storybook stories
~80%test coverage held as a contract — with token-aware linting and visual regression on every change
86components mapped component-for-component between code and Figma, with coverage checked in CI
3prompt files that let a non-designer build an on-brand Trinity app in the AI tool they already use
8+products building from one governed foundation
The system is the reason a small design practice can set direction across a portfolio — and the reason Trinity’s AI products share one coherent language of trust.
What I’d Validate Next
Every number in the outcome above measures what the system is. None of them measures whether it’s working. These four would.
Is adoption real or nominal?
Imports are easy to count and easy to misread. I’d instrument component usage against forked copies and one-off overrides in each product repo — because the override rate, not the install count, is the honest adoption metric.
Does Storybook-as-canon survive a deadline?
Governance holds until a release is late. I’d track how often teams ship a local variant under pressure and treat every instance as a gap in the system rather than a failure of someone’s discipline — the system should be the fast path, not the virtuous one.
Does the Figma bridge stay synced?
86 mapped components is a snapshot, and the real question is drift six months on. CI coverage checks catch structural breaks but not semantic ones — a component that still maps but no longer means the same thing in both places.
On-brand, or merely on-brand-looking?
A non-designer generating a Trinity app is the strongest claim on this page. I’d have people outside the design team build something with the prompt files, then review the output against the system myself — the gap between those two judgements is the real result.
