voxcog: designsystem i kode og brugertest
Studiets forhold til kunden
voxcog er et produkt, Torn Studio har bygget og ejer en andel af. Studiet stod for produktledelse, arkitektur og udvikling frem til overdragelsen i august 2026.
Kort svar
Torn Studio byggede voxcogs brugerflade på et designsystem i kode med tokens i OKLCH og et dokumenteret regelsæt. En brugerundersøgelse gav sytten fund; elleve holdt, ét delvist og fem faldt, da de blev prøvet mod koden. Tolv ændringer gik i produktion.
Opgaven
voxcog havde brug for en brugerflade, der hang sammen på tværs af omkring fyrre visninger bygget af én person på nogle måneder, og skulle vide, hvilke af de rapporterede problemer der var reelle, før noget blev bygget om.
Det der gjorde det svært
- En brugerflade bygget i højt tempo af én person driver visuelt fra hinanden, når hver visning selv må vælge sine farver og afstande.
- En brugerundersøgelse leverer reelle fejl blandet med ønsker, og at bygge alt, hvad der rapporteres, er den hurtigste måde at bygge de forkerte ting på.
- Produktet skulle være klar til lancering, hvilket kræver, at både tomme tilstande og juridiske flader er færdigt arbejde.
Tal der kan tælles efter
- 17fund i en brugerundersøgelse
- Elleve holdt, ét delvist, fem faldt, da de blev prøvet mod den komponent, de pegede på. Vurderingen ligger stadig i kodebasen med begrundelsen for hvert afslag.
- 12ændringer i produktion fra undersøgelsen
- De fem afviste ligger stadig i dokumentet med begrundelsen, så den næste læser ser, hvad der blev prøvet og forkastet.
- 373testfiler
- Placeret ved siden af den kode, de dækker. Evalueringerne af agenten ligger blandt dem og køres som selvstændige kommandoer.
- 300linjers loft pr. fil
- Reglen der holder komponenterne delbare. Den står i kodebasens egen instruktionsfil og gælder alt nyt.
Sådan blev det gjort
Tokens som eneste visuelle kilde
Farve, typografi, radier og skygger erklæres som tokens i OKLCH og bruges gennem variabler. Reglen blev skrevet ned som en selvstændig reference, så en ny visning arver systemet og henter sine værdier derfra.
Hvert fund blev prøvet mod koden først
De sytten fund fra runden i april 2026 blev læst ét ad gangen mod den komponent, hvert af dem pegede på. Elleve holdt, ét holdt delvist, og fem viste sig at beskrive noget, der allerede virkede, eller en funktion, der ikke fandtes.
Tomme tilstande der giver retning
De tynde tomme tilstande blev skrevet om til korte vejledninger, der forklarer, hvad fladen er til for, og giver et næste skridt. Værktøjslinjer skjules helt, mens en liste er tom, så en førstegangsbruger møder en instruktion.
Datahentning som ét mønster
Al læsning på klientsiden blev lagt om til et fælles cachelag med nøglefabrik og fælles fejlhåndtering. Opdateringsknapperne kunne fjernes, fordi listerne nu selv ved, hvornår de er forældede.
Teknologi
- React 19
- Next.js 16
- Tailwind CSS v4
- shadcn/ui
- OKLCH
- TanStack Query
- Playwright
Hvad beviset rækker til
Det her viser en brugerflade, der hænger sammen, og en arbejdsmåde, der adskiller reelle problemer fra ønsker. Det viser intet konverteringstal: voxcog blev overdraget før lancering, så der er ingen trafik at måle mod.
Grundlag
Hvad denne artikel hviler på — en måling vi lavede, en dateret kilde eller en beslutning vi traf og hvad den kostede.
- Måling
Hvor mange af sytten rapporterede problemer i brugerfladen der var reelle
Måleobjekt: voxcogs app, forskningsrapporten fra 2. april 2026
Metode: Hvert fund blev læst mod den komponent, det pegede på, før der blev skrevet kode, og udfaldet noteret som holder, delvist eller falder.
Resultat: 11 holdt, 1 delvist, 5 faldt
- Beslutning
De fem afviste fund blev skrevet ned sammen med begrundelsen for afslaget.
Hvad det kostede: Runden leverede tolv ændringer, hvor sytten blev efterspurgt, og rapportens egne funktionsidéer blev holdt udenfor som hypoteser.
- Beslutning
Alt visuelt udtrykkes som tokens i OKLCH og bruges gennem variabler.
Hvad det kostede: En engangsomkostning i opstarten og en regel at holde: en ny farve kræver en ny token, før den må bruges.
Ofte stillede spørgsmål
- Hvorfor prøver I brugerfund mod koden, før I bygger?
- Fordi en undersøgelse blander reelle fejl med ønsker og med ting, der allerede virker. Fem ud af sytten fund i denne runde faldt ved kontrollen, og at bygge dem ville have kostet tid og gjort brugerfladen dårligere.
- Hvad er forskellen på et designsystem og et komponentbibliotek?
- Biblioteket er komponenterne. Systemet er reglerne, der afgør, hvad der må findes: hvilke farver der eksisterer, hvilke afstande der er tilladt, og hvad der sker, når noget mangler. Reglerne er det, der holder sammen på et produkt, der vokser hurtigt.
- Hvorfor OKLCH som farverum?
- OKLCH er perceptuelt ensartet, så en skala med jævne trin også ser jævn ud, og kontrasten kan regnes ud. En mørk variant bliver en omdefinering af lyshed i samme system.
- Hvad menes der med, at en tom tilstand giver retning?
- At fladen forklarer, hvad den er til for, og giver et næste skridt, når der er nul rækker at vise. En førstegangsbruger møder en instruktion, og søgning og filtrering holdes skjult, indtil der er noget at søge i.
- Kan I bygge et designsystem til det produkt, vi allerede har?
- Ja. Arbejdet begynder med at kortlægge de værdier, der allerede er i brug, samle dem til ét tokensæt og derefter flytte visning for visning. Systemet leveres som kode i jeres kodebase og som en skreven reference.
- Hvor mange visninger omfattede arbejdet med brugerfladen?
- Omkring fyrre visninger fordelt på chat, dokumenter, signaler, opgaver, arbejdsflader og en offentlig interviewdel. De deler alle samme tokensæt og samme komponentbibliotek.
Fortæl os, hvad du vil bygge
Tredive minutter, helt gratis, og en klar melding om, hvorvidt vi er det rette studio til opgaven.