03 — Case study
All workDesign System
SRIIO UI — a design system designed and built from scratch, now at v2.0.0. Twenty-six components and more than forty UI blocks, fully typed, dark mode throughout, and no runtime dependencies at all: styling is Tailwind classes, so there is no CSS bundle to ship and nothing to pay for at runtime. It installs from npm as @sriio/ui and imports straight into any project. It also generates a Markdown reference for a given project, which puts the rules for building consistently next to the code rather than in a document nobody opens.
01
The problem
For the business
SRIIO runs several developers and several designers, and every one of them was reaching for different components and different elements. No flow was consistent with any other, nobody could hold to a brand guideline, and the software was worse for it. Then the teams started generating UI with AI, and the drift got faster rather than slower — every generation invented its own version of something that already existed.
For the people using it
This had to serve the developers and designers building the next screen, and increasingly the model they were building it with. Without a system a button is a decision every time; with AI in the loop it is a fresh decision on every generation. What came out then needed fixing and revising, and every round of that burned tokens on a question that should never have been open.
02
Constraints
What limited us
- Zero dependencies was itself the hardest constraint. Everything had to come out of Tailwind classes the host project already compiles — straightforward for a button, genuinely awkward for a date picker, a modal or a drawer
- Dark mode on every component meant every decision was made twice. Nothing could be designed for one surface and adapted to the other afterwards
- Adoption was a constraint rather than an afterthought. Developers already had a way of working, and a system only earns its place if using it is easier than carrying on as they were
- I was doing all of it — the design, the code, the documentation site, the package and the Markdown generation — so everything had to be scoped to what one person could keep maintaining
What we were aiming at
- One set of components and elements across every team, so the product could be built to an industry standard instead of to whatever each person reached for
- Make the brand guideline something a project follows by default rather than something people are asked to remember
03
My scope
What I owned
- Designed and built the system from scratch — components, tokens and the library itself
- Published it as an npm package, so any project installs it and imports components directly
- Built the Markdown generation, so a project can produce its own consistency reference
- Wrote the documentation site that ships with it — installation, theming, and every component with its variants, live
- Decided what belonged in the system and what did not — a judgement rather than a written rule, and after several years designing products, not the part of this that took the thinking
What I didn’t
- Nothing here was outside my scope — I designed it, built it, packaged it and documented it
04
Research
What we found
- The signal did not arrive as a design problem. I am the product manager here as well, and the team kept asking for a bigger AI subscription because the quota kept running out. That complaint is what sent me looking
- The cost was underneath the UI. Every team was generating interfaces with AI from a different starting point, so what came back needed fixing and revising — the tokens were going on the same question being answered again and again
Where it hurt
- Nobody could hold to a brand guideline, because nothing inside a project carried it
- No flow was consistent with another, and the drift arrived faster once AI was generating the screens rather than slower
05
Decisions
Decision 01
A component library that arrives with its own runtime is a tax on every project that installs it — a CSS bundle to ship, a theme layer to learn, and a dependency that has to be kept alive.
Chosen
Zero runtime dependencies. Every component is styled with Tailwind classes the host project already compiles, so nothing extra ships and a team themes it with the tools it uses anyway. Fully typed, dark mode throughout, and each component copy-pasteable as well as importable.
Rejected, and why
Nothing was weighed against it, and I would rather say so than invent a shortlist. I designed and built this one alone, end to end, so there was no argument to have — the decision and the consequences of it sat with the same person. Zero dependencies was the shape it had from the start, not a position defended against others.
Decision 02
The system answered the token problem, and a second one surfaced behind it: teams still could not hold to a brand guideline, because nothing inside a project carried it. Documentation that lives away from the code loses that race every time — and this had a reader who will never open a documentation site at all, which is the model generating the UI.
Chosen
A feature added after the system was already running: it generates a Markdown file into the project itself, and manages it. A team drops it in, and everything downstream — person or model — works from the same components, the same elements and the same design language. The documentation site, with every component and variant rendered live, is for the reader who is human.
Rejected, and why
Nothing was weighed against this one either. The Markdown file exists because of what the problem turned out to be — the AI needed context and the design needed consistency, and one file sitting in the project answers both at once. It was not picked over Storybook or a Figma source of truth; those were never the question being asked.
06 — The work
06 screens
desktopScreen name — what it does, and the decision it reflects
07
What happened
Measured
- The AI subscription used to run out ten to twelve days before the month was over. It no longer runs out inside the month at all. Nobody was measuring a precise figure, but that is the before and the after
Knock-on effects
- Every team converged on the same components and elements, and the product started being built to an industry standard
- Token burn fell. Generated UI needed fewer fixes and fewer revisions, because a model that can import a component never has to invent one, and never has to reason about the design language at all — and tokens saved are money saved
- Projects got materially faster, which is the outcome sitting underneath all the others
08
In hindsight
What it taught me
- How to find the problem a team actually has. Nobody here described this as a design problem — they asked for a bigger AI subscription — and the useful part was taking that complaint seriously enough to go and look underneath it
- The build came with it. The code, the packaging and the documentation are things I now know how to ship, not only to design
Next — 04