voxcog: a design system in code, and user testing
The studio’s relationship to the client
voxcog is a product Torn Studio built and holds a stake in. The studio ran product management, architecture and the build through to handover in August 2026.
Short answer
Torn Studio built voxcog’s interface on a design system in code, with OKLCH tokens and a documented rule set. A research round produced seventeen findings; eleven held, one held partly, and five fell when checked against the code. Twelve changes shipped.
The brief
voxcog needed an interface that held together across some forty views built by one person in a few months, and needed to know which of the reported problems were real before anything was rebuilt.
What made it hard
- An interface built at speed by one person drifts visually when every view is free to pick its own colours and spacing.
- A research round delivers real defects mixed with wishes, and building everything reported is the fastest way to build the wrong things.
- The product had to be launch-ready, which means empty states and legal surfaces are finished work.
Figures a reader can count
- 17findings in a research round
- Eleven held, one partly, five fell when checked against the component each named. The assessment is still in the repository with the reason for every rejection.
- 12changes shipped from that round
- The five rejected ones stay in the document with their reasoning, so the next reader sees what was tested and dropped.
- 373test files
- Placed next to the code they cover. The agent evaluations sit among them and run as their own commands.
- 300line ceiling per file
- The rule that keeps components splittable. It sits in the repository’s own instruction file and applies to everything new.
How it was done
Tokens as the only visual source
Colour, typography, radii and shadows are declared as tokens in OKLCH and used through variables. The rule was written down as its own reference, so a new view inherits the system and takes its values from there.
Every finding checked against the code first
The seventeen findings from the April 2026 round were read one at a time against the component each named. Eleven held, one held partly, and five turned out to describe something that already worked or a feature that did not exist.
Empty states that give direction
The thin empty states were rewritten as short guides explaining what the surface is for and offering a next step. Toolbars are hidden entirely while a list is empty, so a first-time user meets an instruction.
Data fetching as one pattern
All client-side reading moved onto a shared caching layer with a query-key factory and common error handling. The refresh buttons came out, because the lists now know for themselves when they are stale.
Stack
- React 19
- Next.js 16
- Tailwind CSS v4
- shadcn/ui
- OKLCH
- TanStack Query
- Playwright
The limits of this proof
This shows an interface that holds together and a method that separates real problems from wishes. It shows no conversion figure: voxcog was handed over before launch, so there is no traffic to measure against.
Evidence
What this article rests on — a measurement we took, a dated source, or a decision we made and what it cost.
- Measurement
How many of seventeen reported interface problems were real
Measured on: voxcog’s app, the research report of 2 April 2026
Method: Each finding was read against the component it named before any code was written, and the outcome recorded as holds, partly or falls.
Result: 11 held, 1 partly, 5 fell
- Decision
The five rejected findings were written down together with the reason for the rejection.
What it cost: The round shipped twelve changes where seventeen were asked for, and the report’s own feature ideas were left out as hypotheses.
- Decision
Everything visual is expressed as tokens in OKLCH and used through variables.
What it cost: A one-off cost at the start and a rule to hold: a new colour needs a new token before it can be used.
Common questions
- Why check user findings against the code before building?
- Because a research round mixes real defects with wishes and with things that already work. Five of seventeen findings in this round fell on inspection, and building them would have cost time and made the interface worse.
- What is the difference between a design system and a component library?
- The library is the components. The system is the rules deciding what may exist: which colours are available, which spacings are allowed and what happens when something is missing. The rules are what hold a fast-growing product together.
- Why OKLCH as the colour space?
- OKLCH is perceptually uniform, so a scale with even steps also looks even and contrast can be calculated. A dark variant becomes a redefinition of lightness inside the same system.
- What does it mean for an empty state to give direction?
- That the surface explains what it is for and offers a next step when there are zero rows to show. A first-time user meets an instruction, and search and filter controls stay hidden until there is something to search.
- Can you build a design system for our existing product?
- Yes. The work starts by inventorying the values already in use, collecting them into one token set and then moving view by view. The system ships as code in your repository and as a written reference.
- How many views did the interface work cover?
- Around forty views across chat, documents, signals, tasks, workspaces and a public interview surface. They all share one token set and one component library.
Tell us what you want to build
Thirty minutes, free of charge, and a straight answer on whether we are the right studio for it.