Hvordan jeg strukturerer et designsystem fra dag én
Et designsystem er ikke et komponentbibliotek. Det er et felles språk. Her er hvordan jeg bygger det opp fra starten, uten å over-ingeniøre det.
De fleste designsystemer begynner feil. Ikke fordi intensjonen er dårlig, men fordi de starter med komponenter i stedet for beslutninger.
Et komponentbibliotek uten et token-fundament er et kortspill uten regler. Alle vet hva kortene ser ut, men ingen er enige om hva de betyr.
Lag tokens først. Alltid.
Farger, typografi og spacing er ikke stilvalg. De er beslutninger som skal tas én gang og gjelde overalt. Jeg starter alltid med tre lag:
Primitive tokens: de faktiske verdiene (blue-500: #3B5BDB). Semantiske tokens: hva de betyr (color-action-primary: blue-500). Komponent-tokens der det trengs (button-bg: color-action-primary).
Tre lag. Ikke mer. Går du dypere enn dette på dag én, bruker du tid på arkitektur i stedet for design.
Navngi for utvikling, ikke for Figma
Den vanligste feilen er å navngi tokens slik de ser logiske ut i Figma, ikke slik de implementeres i kode. Bruk de samme navnene som utviklerne bruker. Om de kaller det surface/default, kall det det i Figma også.
Et designsystem som ikke matcher kodebasen er et dokumentasjonssystem. Det er ikke det samme.
Bygg komponenter nedenfra og opp
Atom, molekyl, organisme. Det er ikke bare en metafor, det er rekkefølgen du faktisk bør bygge i. En knapp skal fungere alene før den sitter i en form. En form skal fungere alene før den sitter i en modal.
Bygger du ovenfra og ned risikerer du at basisen endrer seg halvveis, og alt over må redefineres.
Dokumenter beslutningene, ikke bare resultatet
«Primærfargen er blå» hjelper ingen. «Primærfargen er blå fordi den arves fra merkevaren og brukes på alle interaktive primærelementer» er nyttig. Fremtidige deg, og fremtidige kollegaer, trenger å vite hvorfor, ikke bare hva.
Når er du ferdig?
Aldri. Men du er klar til å bruke det når du kan bygge en ny skjerm uten å ta en eneste ny fargebeslutning. Det er det første målet.