Å bygge et designsystem handler om mye mer enn bare design og kode. Hvordan skal det dokumenteres, hvordan skal det vedlikeholdes og ikke minst, hvordan skal det bygges? En viktig, men ofte oversett del, er hvordan vi navngir komponentene. Dette kan virke som en liten detalj, men gode navn er avgjørende for at designsystemet skal være lett å bruke og forstå. Gode navn skaper tydelighet, reduserer forvirring og gjør det enklere for teamet å samarbeide – uansett om de er designere, utviklere eller andre i sjappa som vil ta det i bruk 💪🏼

Her kommer fem tips og råd for å navngi komponenter i designsystemer som forhåpentligvis kan komme til nytte for deg og ditt team 🙌🏼

1. Navnet bør si noe om hva komponenten gjør eller er – ikke hvordan det er implementert

Skal brukeren velge noe fra en liste? Da bør komponenten kanskje hete Select og ikke Dropdown. Et godt navn beskriver funksjonen, ikke formen eller hvordan den er bygget. Husk: målet til brukeren er ikke å falle nedover – men å velge! 😼

Når navn reflekterer brukerens mål, blir det enklere for alle, fra designere til utviklere, å forstå komponentens hensikt uten å måtte lese seg opp i dokumentasjonen.

2. Unngå navn med dobbelt betydning

Navn som kan tolkes på flere måter skaper forvirring. Ta for eksempel ordet Menu. Dette kan bety en hovedmeny for navigasjon, en kontekstmeny som dukker opp ved høyreklikk, eller en hamburgermeny. Slike navn gjør det vanskelig for teamet å forstå nøyaktig hva komponenten gjør. For å unngå dette, bruk eksempelvis mer spesifikke navn som NavigationMenu eller ContextMenu, avhengig av funksjonen av komponenten.

Ved å gi komponenten et unikt og presist navn reduserer du risikoen for misforståelser, og designsystemet ditt blir enklere å bruke og vedlikeholde. 🏗️

3. Bruk eksisterende konvensjoner

Det finnes utallige måter å navngi komponenter på, og minst like mange designsystemer der ute. Likevel er det noen konvensjoner som går igjen. Hvis du er usikker, kan det være lurt å se på etablerte designsystemer som Material Design fra Google, Designsystemet fra Digdir, og Human Interface Guidelines fra Apple. Disse gir et godt utgangspunkt og kan hjelpe deg å velge navn som er flittig brukt. Ved å bruke slike kjente konvensjoner blir designsystemet mer gjenkjennelig og enklere å navigere, særlig for de som har erfaring med andre systemer fra før.

Og hvis du ikke vet hvor du finner mer inspirasjon, anbefaler jeg Component Gallery og UX Norge sin artikkel om norske designsystemer for flere eksempler. 🤩

4. Unngå for mye teknisk sjargong

Brukerne av designsystemet er ofte mer enn bare utviklere. Unngå derfor altfor teknisk eller domenetungt språk. Det samme gjelder forkortelser som kan være uforståelige for mange.

Jeg foretrekker for eksempel at en komponent som brukes til innhold heter Card, ikke ContentWrapper. Det er enklere, mer tydelig, og lettere å forstå for tverrfaglige team. Jeg må også innrømme at jeg fortsatt ikke vet hva Kbd betyr. (Ja, jeg ser på deg, Chakra UI.) 😖

5. Hold deg til ett språk og ett format

Sørg for å holde deg til enten norsk eller engelsk – ikke begge deler. Selv foretrekker jeg engelsk, fordi det er det mest brukte språket i designsystemer og kjent for de fleste utviklere og designere. Det gjør systemet mer tilgjengelig, spesielt hvis teamet ditt vokser eller inkluderer internasjonale medlemmer.

Å blande språk, for eksempel å ha en komponent som heter Datovelger og en annen som heter Button, kan føre til forvirring og rot i koden og dokumentasjonen. Velg ett språk og hold deg til det. 💬

Og helt til slutt: Det finnes ingen regler uten unntak. Det viktigste er å finne en løsning som fungerer for ditt team og dine behov. Lykke til – og god jul! 🎄