---
title: "voxcog: designsystem i kode og brukertesting"
description: "Hvordan voxcogs grensesnitt fikk et designsystem i kode og en brukerstudie der fem av sytten funn falt da de ble prøvd mot koden."
url: https://torn.studio/no/arbeid/voxcog-designsystem-og-brukertesting
locale: no
published: 2026-08-31
updated: 2026-08-26
---

# voxcog: designsystem i kode og brukertesting

> **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.

**Kunde:** voxcog · **Levert:** 2026-08-26

**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.

## 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

| Tall som lar seg telle | | |
| --- | --- | --- |
| 17 | funn 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. |
| 12 | endringer i produksjon fra studien | De fem avviste ligger igjen i dokumentet med begrunnelsen, så neste leser ser hva som ble prøvd og forkastet. |
| 373 | testfiler | Plassert ved siden av koden de dekker. Evalueringene av agenten ligger blant dem og kjøres som egne kommandoer. |
| 300 | linjers 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.

## 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.