voxcog: designsystem i kode og brukertesting
Studioets forhold til kunden
voxcog er et produkt Torn Studio har bygget og eier en andel av. Studioet hadde ansvaret for produktledelse, arkitektur og bygging fram til overleveringen i august 2026.
Kort svar
Torn Studio bygget voxcogs grensesnitt på et designsystem i kode med tokens i OKLCH og et dokumentert regelsett. En brukerstudie ga sytten funn; elleve holdt, ett delvis og fem falt da de ble prøvd mot koden. Tolv endringer gikk i produksjon.
Oppdraget
voxcog trengte et grensesnitt som holdt sammen over rundt førti visninger bygget av én person på noen måneder, og trengte å vite hvilke av de rapporterte problemene som var reelle før noe ble bygget om.
Det som gjorde det vanskelig
- Et grensesnitt bygget i høyt tempo av én person driver visuelt fra hverandre når hver visning står fritt til å velge sine egne farger og avstander.
- En brukerstudie leverer reelle feil blandet med ønsker, og å bygge alt som rapporteres er den raskeste måten å bygge feil ting på.
- Produktet skulle være klart for lansering, noe som krever at både tomme tilstander og juridiske flater er ferdig arbeid.
Tall som lar seg telle
- 17funn i en brukerstudie
- Elleve holdt, ett delvis, fem falt da de ble prøvd mot komponenten de pekte på. Vurderingen ligger igjen i kodebasen med begrunnelsen for hver avvisning.
- 12endringer i produksjon fra studien
- De fem avviste ligger igjen i dokumentet med begrunnelsen, så neste leser ser hva som ble prøvd og forkastet.
- 373testfiler
- Plassert ved siden av koden de dekker. Evalueringene av agenten ligger blant dem og kjøres som egne kommandoer.
- 300linjers tak per fil
- Regelen som holder komponentene delbare. Den står i kodebasens egen instruksjonsfil og gjelder alt nytt.
Slik ble det gjort
Tokens som eneste visuelle kilde
Farge, typografi, radier og skygger deklareres som tokens i OKLCH og brukes gjennom variabler. Regelen ble skrevet ned som en egen referanse, så en ny visning arver systemet og henter verdiene sine derfra.
Hvert funn ble prøvd mot koden først
De sytten funnene fra runden i april 2026 ble lest ett om gangen mot komponenten hvert av dem pekte på. Elleve holdt, ett holdt delvis, og fem viste seg å beskrive noe som allerede virket eller en funksjon som ikke fantes.
Tomme tilstander som gir retning
De tynne tomme tilstandene ble skrevet om til korte veiledninger som forklarer hva flaten er til for og gir et neste steg. Verktøylinjer skjules helt mens en liste er tom, så en førstegangsbruker møter en instruksjon.
Datahenting som ett mønster
All klientsidig lesing ble lagt om til et felles hurtigbufferlag med nøkkelfabrikk og delt feilhåndtering. Oppdateringsknappene kunne fjernes, fordi listene nå vet selv når de er utdaterte.
Teknologi
- React 19
- Next.js 16
- Tailwind CSS v4
- shadcn/ui
- OKLCH
- TanStack Query
- Playwright
Hva beviset rekker til
Dette viser et grensesnitt som holder sammen og en arbeidsmåte som skiller reelle problemer fra ønsker. Det viser ingen konverteringstall: voxcog ble overlevert før lansering, så det finnes ingen trafikk å måle mot.
Grunnlag
Hva denne artikkelen hviler på — en måling vi gjorde, en datert kilde eller en beslutning vi tok og hva den kostet.
- Måling
Hvor mange av sytten rapporterte grensesnittproblemer som var reelle
Måleobjekt: voxcogs app, forskningsrapporten fra 2. april 2026
Metode: Hvert funn ble lest mot komponenten det pekte på før noe kode ble skrevet, og utfallet notert som holder, delvis eller faller.
Resultat: 11 holdt, 1 delvis, 5 falt
- Beslutning
De fem avviste funnene ble skrevet ned sammen med begrunnelsen for avvisningen.
Hva det kostet: Runden leverte tolv endringer der sytten ble etterspurt, og rapportens egne funksjonsideer ble holdt utenfor som hypoteser.
- Beslutning
Alt visuelt uttrykkes som tokens i OKLCH og brukes gjennom variabler.
Hva det kostet: En engangskostnad i oppstarten og en regel å holde: en ny farge krever en ny token før den kan brukes.
Vanlige spørsmål
- Hvorfor prøver dere brukerfunn mot koden før dere bygger?
- Fordi en studie blander reelle feil med ønsker og med ting som allerede virker. Fem av sytten funn i denne runden falt ved kontrollen, og å bygge dem ville kostet tid og gjort grensesnittet dårligere.
- Hva er forskjellen på et designsystem og et komponentbibliotek?
- Biblioteket er komponentene. Systemet er reglene som avgjør hva som får finnes: hvilke farger som eksisterer, hvilke avstander som er tillatt og hva som skjer når noe mangler. Reglene er det som holder sammen et produkt som vokser fort.
- Hvorfor OKLCH som fargerom?
- OKLCH er perseptuelt jevnt, slik at en skala med jevne trinn også ser jevn ut og kontrasten lar seg regne på. En mørk variant blir en omdefinering av lyshet i samme system.
- Hva menes med at en tom tilstand gir retning?
- At flaten forklarer hva den er til for og gir et neste steg når det finnes null rader å vise. En førstegangsbruker møter en instruksjon, og søk og filtrering holdes skjult til det finnes noe å søke i.
- Kan dere bygge et designsystem for produktet vi allerede har?
- Ja. Arbeidet starter med å kartlegge verdiene som allerede er i bruk, samle dem til ett tokensett og deretter flytte visning for visning. Systemet leveres som kode i kodebasen deres og som en skrevet referanse.
- Hvor mange visninger omfattet grensesnittarbeidet?
- Rundt førti visninger fordelt på chat, dokumenter, signaler, oppgaver, arbeidsflater og en offentlig intervjudel. Alle deler samme tokensett og samme komponentbibliotek.
Fortell hva du vil bygge
Tretti minutter, kostnadsfritt, og et ærlig svar på om vi er riktig studio for oppdraget.