Designsystem for nettsider: når det lønner seg
Et designsystem er et felles sett visuelle beslutninger og gjenbrukbare komponenter. Godt laget fremskynder det alt påfølgende arbeid. Feil dimensjonert blir det et parallelt prosjekt som spiser tid og blir utdatert.
Denne guiden viser hva du skal ha med, når det lønner seg, og hvordan du starter uten å bygge et bibliotek ingen kommer til å bruke.
Hva det inneholder, fra vesentlig til tilbehør#
Start øverst på listen. De første punktene løser størstedelen av problemet.
| Lag | Innhold | Prioritet |
|---|---|---|
| Fundament | Farger, typografi, avstandsskala | Vesentlig |
| Elementer | Knapper, felt, lenker, merker | Vesentlig |
| Mønstre | Skjemaer, kort, navigasjon, tabeller | Høy |
| Maler | Komplette sidelayouter | Middels |
| Skriveretningslinjer | Tone, etiketter, feilmeldinger | Høy og ofte glemt |
| Bruksregler | Når man bruker hvilken komponent | Middels |
| Levende dokumentasjon | Eksempler som kjører ekte kode | Avhenger av omfang |
Skriveretningslinjer er det mest undervurderte laget. Inkonsistente etiketter og meldinger skader opplevelsen like mye som inkonsistente komponenter.
Når det lønner seg#
Et designsystem koster å lage og å vedlikeholde. Det lønner seg når det er nok gjentakelse til å nedskrive det.
- Flere produkter eller sider som skal se ut som samme merke.
- Et team der mer enn én person designer eller bygger grensesnitt.
- En stor side med mange maler og forventet vekst.
- Utskifting av leverandører, der konsistens henger på dokumentasjon.
- Lønner seg ikke: en bedriftsside på ti sider med én ansvarlig.
- Lønner seg ikke: når siden uansett bygges om innen et år.
- I de tilfellene holder en stilfil med farger, skrifttyper og knapper til fulle.
Å starte smått#
Den mest pålitelige måten å få et designsystem er å trekke det ut av det som allerede finnes, i stedet for å designe i abstraksjon.
- Lag en opptelling: fang alle knapper, felt og kort fra dagens side.
- Du finner for mange varianter. Velg én av hver og fjern resten.
- Definer tokens: farger, skrifttyper, avstander, radier, skygger — som navngitte variabler.
- Bygg de fem til ti komponentene som opptrer overalt.
- Dokumenter hver med tilstander og en merknad om når den brukes.
- Anvend på en ekte mal før du går videre; anvendelsen avslører hva som mangler.
- Først deretter utvider du, og bare når en komponent trengs mer enn to ganger.
Et system trukket ut av den ekte siden blir brukt; et system designet i abstraksjon ser pent ut i dokumentasjonen og ignoreres i praksis.
Slik dør designsystemer#
Feilmåtene er forutsigbare og nesten alle organisatoriske.
| Feilmåte | Tegn | Forebygging |
|---|---|---|
| Ingen er ansvarlig | Slutter å bli oppdatert | En eier med avsatt tid |
| Ute av takt med koden | Dokumentasjonen lyver | Generer fra ekte kode |
| For rigid | Team går utenom | Tillat dokumenterte unntak |
| For stort | Ingen finner noe | Start med ti komponenter |
| Manglende oppslutning | Duplikate komponenter utenfor systemet | Involver brukerne fra start |
| Kun design, ingen kode | Utviklere implementerer for hånd | Ekte komponenter, ikke bare skjermer |
Ofte stilte spørsmål
Trenger jeg et designsystem til en liten side?
Nei. For en bedriftsside med én ansvarlig holder en stilfil med farger, typografi, avstander og noen komponenter, og den fyller samme funksjon. Et formelt system lønner seg først når flere personer eller flere produkter skal holde sammen.
Hvor lang tid tar det å lage?
En brukbar første versjon — tokens pluss ti komponenter — tar to til fire uker. Et komplett system med dokumentasjon, kode og retningslinjer tar måneder og blir aldri riktig ferdig, fordi det følger produktet. Start smått og anvend tidlig i stedet for å sikte mot komplett før bruk.
Skal jeg bruke et eksisterende bibliotek?
Ofte ja, særlig i interne applikasjoner der visuell identitet betyr mindre enn tempo. Et modent bibliotek gir deg tilgjengelige og testede komponenter med én gang. Tilpass det med dine tokens i stedet for å bygge alt fra bunnen — å bygge tilgjengelige komponenter fra null er mer arbeid enn det ser ut til.
Hvem skal være ansvarlig for designsystemet?
En utpekt person med reelt avsatt tid. Uten eier blir systemet utdatert på måneder og blir en hindring i stedet for en hjelp, fordi dokumentasjonen slutter å svare til produktet. Dette er den vanligste feilmåten, og den er organisatorisk snarere enn teknisk.
designsystemkomponentbibliotekdesigntokensstilguidevisuell konsistensgjenbrukbare komponenter
