--- title: "Hvilke komponenter bør du ha i komponentbiblioteket ditt?" url: "https://www.bekk.christmas/post/2024/17/hvilke-komponenter-bor-du-ha-i-komponentbiblioteket-ditt" authors: ["Marlin Hjallum"] published: "2024-12-17" updated: "2024-12-22T15:24:14Z" language: "nb-NO" type: "article" tags: ["Designsystem"] keywords: ["designsystem", "komponenter", "ui-komponenter", "komponentbibliotek", "design tokens", "design"] series: "Designsystem" --- # Hvilke komponenter bør du ha i komponentbiblioteket ditt? Et godt komponentbibliotek er en av de mest sentrale bestanddelene i et designsystem for å bygge effektive og konsistente digitale produkter. Men hvilke komponenter bør egentlig inkluderes for å dekke behovene til sluttbrukere, utviklere og designere? Og hvordan skal man prioritere implementeringen av dem? ## Kort fortalt Et godt komponentbibliotek samler de mest grunnleggende byggeklossene i et designsystem, som typografi, ikoner, støttekomponenter, knapper, lenker, skjemaelementer, navigasjon og tilbakemeldinger. Mer komplekse komponenter som modaler, tabeller og avanserte inputfelt bør komme senere, etter at grunnstrukturen og de viktigste brukerhandlingene er på plass. - **Passer for:** Designere og utviklere som jobber med designsystemer _Generert med KI_ ## Hvorfor trenger man egentlig et komponentbibliotek? Komponenter i digitale grensnesnitt er gjenbrukbare byggeklosser, som knapper eller inputfelt, som nettsider og apper er bygd opp av. Disse byggeklossene gjør det raskere og enklere å lage digitale produkter som ser like ut og fungerer på samme måte på tvers i en organisasjon. Et komponentbibliotek er en sentralisert samling av disse byggeklossene, designet og utviklet én gang for å kunne brukes igjen og igjen. Ved å bruke komponenter fra et slikt bibliotek kan designere og utviklere spare tid ved å unngå å lage de samme elementene fra bunn av hver gang. Endringer og vedlikehold gjøres ett sted og oppdateres automatisk overalt hvor komponenten er brukt. ## Hvilke komponenter inngår typisk i et komponentbibliotek? Komponentbiblioteket i et designsystem bør inneholde de mest grunnleggende og ofte brukte komponenter i de digitale flatene til en organisasjon. Det omfatter gjerne kjernekomponenter som knapper og typografi, og mer komplekse komponenter som tabeller og modaler. For å gjøre biblioteket enklere å navigere i, velger noen å organisere komponentene i overordnede kategorier utifra hvilken funksjon de har slik som knappeelementer, navigasjonselementer, skjemaelementer, layoutelementer og feedback-elementer. Andre igjen skiller mellom kjernekomponenter _(du har kanskje hørt uttrykket «core components»?)_ og sammensatte komponenter _(såkalte «nested components»)_. Slike inndelinger kan være nyttige for å strukturere biblioteket og gjøre det enklere for brukerne av designsystemet å finne det de trenger, men er ikke nødvendigvis et krav. Her må man gjøre det som passer best for organisasjonen og gir mest mening for de som skal bruke biblioteket. I denne artikkelen vil komponentene forklares og inndeles på bakgrunn av funksjonen deres, for å gjøre det enklere å få et overblikk over hva som bør inngå i et komponentbibliotek, og hvorfor. ### **Knappeelementer** Knappeelementer er interaktive komponenter som utløser en spesifikk handling eller setter i gang en prosess når brukeren klikker på dem. De er essensielle for å la brukeren utføre en funksjonell oppgave. **Avatar** En avatar-komponent brukes til å representere en brukerprofil ved å vise enten et profilbilde, initialer eller et ikon. **Button** Knapper lar brukeren utføre en handling og ta valg med et klikk. Knapper finnes i flere varianter og størrelser, slik som for eksempel primærknapp, sekundærknapp og ikonknapp. **Chips** Chips er små og kompakte knapper med tekst og ikoner som brukes for mindre sentrale handlinger hvor det ikke passer å bruke vanlig knapp. **Link** Lenke-komponenten er en knapp som navigerer brukeren til en annen del av tjenesten eller til en ekstern nettside via en URL. Eksterne lenker bør ha et ikon som tydelig viser at de tar brukeren til en ekstern nettside. ![Eksempelvisning på komponenter som gjerne betegnes som knappeelementer](https://cdn.sanity.io/images/ah2n1vfr/bekk-blogg-prod/e6412970eb57548411c63a1433ac479a619491bf-5400x1260.png) _Eksempelvisning på komponenter som gjerne betegnes som knappeelementer_ ### **Navigasjonselementer** Navigasjonelementer er komponenter som hjelper brukeren med å finne frem og bevege seg rundt til ulike deler i en digital tjeneste. Slike komponenter bidrar til en effektiv og oversiktlig brukeropplevelse. **Breadcrumb** Brødsmulesti er en navigasjonskomponent som viser hvor på nettsiden brukeren befinner seg, og lar dem enkelt finne veien tilbake til tidligere nivåer. **Drawer** En drawer er en skjult meny som skyves inn fra siden av skjermen for å vise navigasjonsvalg eller tilleggsinformasjon, som en skuff. **List** Listekomponenten er en vertikal liste med elementer som tekst, ikoner eller handlinger. **Navigation Menu** Navigasjonsmeny er en global meny som gir brukeren en oversikt over alt innhold på nettsiden som kan navigeres i. Den kan være plassert enten horisontalt på toppen eller vertikalt på siden. **Overflow Menu** Overflow menu består av en ikonknapp (ofte vist med tre prikker) som utløser en liste med “skjulte” valg når brukeren klikker på den. **Dropdown Menu** Dropdown menu, eller nedtrekksmeny, er en menykomponent som åpnes i en popover ved klikk og viser en liste med valg eller alternativer relatert til en spesifikk handling. **Pagination** Paginering brukes for å fordele innhold på over flere sider og lar brukeren navigere mellom dem med “forrige” og “neste” knapper, slik at brukeren ikke blir overveldet av for mye innhold eller data samtidig. **Tabs** Tabs er en komponent som organiserer innhold i egne paneler eller faner, slik at brukeren enkelt kan navigere mellom relatert innhold ved å bytte mellom ulike seksjoner. **Toggle** Toggle er en knapp bestående av to valg som lar brukeren skifte mellom to tilstander. **Toggle Group** En toggle group er en gruppe av toggle-knapper som er sammenhengende der brukeren kan velge mellom flere alternativer, hvor enten ett eller flere valg kan være aktivert samtidig. **Switch** Switch er en type toggle-funksjon som ser ut som en fysisk bryter for å slå av eller på en funksjon. Den brukes ofte i innstillinger der man raskt vil endre mellom en aktivert eller deaktivert tilstand. **Search** Søkekomponenten lar brukeren søke etter spesifikt innhold ved å skrive inn nøkkelord eller setninger som leter frem det mest relevante innholdet. ![Eksempelvisning på komponenter som gjerne betegnes som navigasjonselementer](https://cdn.sanity.io/images/ah2n1vfr/bekk-blogg-prod/f502bef606e29d5f07ef62309e31d7f24d87be5d-4140x4244.png) _Eksempelvisning på komponenter som gjerne betegnes som navigasjonselementer_ ### **Skjemaelementer** Skjemaelementer omhandler de komponentene som samler inn data fra brukeren, ofte gjennom skjemaer hvor brukeren kan legge inn informasjon. Disse er sentrale elementer i brukerflyter som registrering, innlogging, søk, kjøp og andre former for dataregistrering. **Checkbox** Sjekkbokser lar brukeren velge ett eller flere alternativer fra en liste med mulige valg, der det vises en hake når noe er valgt. Sjekkbokser brukes også gjerne når brukeren må bekrefte noe. **Combobox** Combobox kombinerer et tekstfelt og en nedtrekksliste (dropdown), og lar brukeren skrive direkte i tekstfeltet eller velge fra listen med alternativer. Det finnes flere varianter av combobox, blant annet singleselect hvor det kun er mulig å velge ett alternativ eller multiselect hvor brukeren kan aktivere flere alternativer samtidig. **Fieldset** Fieldset er en «beholder» som grupperer skjemaelementer som hører sammen under en felles betegnelse. **File Upload** Filopplaster er en komponent som lar brukeren laste opp filer fra enheten sin, slik som bilder, vedlegg eller annen dokumentasjon. **Radio** Radio er en sirkulær knapp som lar brukeren velge ett alternativ blant flere valg. Når et valg er tatt kan det ikke fjernes. Da kan det kun byttes med et annet alternativ. **Textfield** Textfield er et klassisk tekstfelt som gir brukeren mulighet til å skrive inn korte tekster eller tall, som navn, e-post eller telefonnummer. **Textarea** Textarea er et større tekstfelt som gir brukeren mulighet til å skrive inn flere linjer med tekst, ofte brukt for kommentarer eller beskrivelser. ![Eksempelvisning på komponenter som gjerne betegnes som skjemaelementer](https://cdn.sanity.io/images/ah2n1vfr/bekk-blogg-prod/6b008276f2b07faa440d9f67933bfc29ef98f498-5400x2254.png) _Eksempelvisning på komponenter som gjerne betegnes som skjemaelementer_ ### **Layoutelementer** Med layoutelementer mener vi komponenter som hjelper med å organisere og strukturere innhold på en flate. De sørger for at innholdet er lett å lese og oversiktlig å navigere i. **Accordion** Accordion er komponenter som kollapser og ekspanderer innhold i et utvidbart panel, slik at brukeren kan se eller skjule informasjon etter eget behov. **Card** Kortkomponenten er en «beholder» som løfter frem og grupperer informasjon eller handlinger om et emne. **Calendar** En kalenderkomponent viser datoer i en kalenderstruktur, ofte brukt for å la brukeren velge en spesifikk dato eller tidsperiode. **Date Picker** Datovelgeren lar brukeren skrive inn eller velge en eller flere tilgjengelige datoer eller perioder. Datovelgeren kan brukes med eller uten kalenderkomponent. **Divider** Divider er en enkel skillelinje som deler inn innhold eller seksjoner så det blir mer oversiktlig. **Image** Bildekomponenten viser et bilde, rett og slett. **Media Card** Media card er en variant av kortkomponenten som inkluderer media i form av bilde, video eller annen grafikk for å forsterke det tekstlige innholdet på kortet. **Table** Tabeller brukes til å organisere og vise data i rader og kolonner. De kan være enkle med få rader og kolonner, men de kan også være komplekse og innholdsrike med sorterings- og filtreringsvalg og annen interaksjon. **Time Picker** Tidsvelgeren er en komponent som lar brukeren velge eller skrive inn et bestemt klokkeslett, ofte gjennom en dropdown. ![Eksempelvisning på komponenter som gjerne betegnes som layoutelementer](https://cdn.sanity.io/images/ah2n1vfr/bekk-blogg-prod/64ad7f9c46a2d889e2e26e15dd24a5b2d94b0332-4140x3249.png) _Eksempelvisning på komponenter som gjerne betegnes som layoutelementer_ ### **Feedback-elementer** Feedback-elementer handler om komponenter som gir brukeren en indikasjon eller tilbakemelding på en handling som er utført av brukeren. De kan informere, advare eller bekrefte at en handling har blitt utført. Disse er viktige for å veilede brukeren gjennom interaksjoner og gi en bedre og mer intuitiv brukeropplevelse. **Alert** En alert eller varselmelding er en kort, viktig beskjed til brukeren. Det kan være ren informasjon, suksessmelding, advarsel eller en feilmelding. **Badge** Badge er en liten visuell merkelapp som viser status eller små oppdateringer i form av tall. De blir ofte brukt for dynamisk informasjon som uleste meldinger eller varsler. **Modal** En modal er et midlertidig vindu som åpnes for å presentere informasjon eller en oppgave som brukeren må ta stilling til for å gå videre. Modalen fanger brukerens fokus ved å avbryte brukerflyten, samtidig som konteksten beholdes. **Helptext** Hjelpetekster er en kort tekst som gir brukeren en skriftlig veiledning eller ekstra informasjon om et spesifikt element eller handling. **Loader** Loader er en visuell tilbakemelding på at et innhold laster eller er i prosess, gjerne gjennom en animasjon. Selv om brukeren får lite informasjon om hva som skjer, får de likevel en forsikring om at noe skjer. **Popover** Popover er et lite, skjult panel eller informasjonsvindu som legger seg over andre elementer og viser ekstra informasjon når brukeren klikker på det. **Progress Bar** Progress bar er en lastekomponent viser fremdriften til en handling eller prosess, og brukes for å gi beskjed om at en prosess er i gang og eventuelt hvor lang tid denne prosessen tar eller har kommet. **Skeleton** Skeletons er en lastekomponent som viser placeholdere for innhold som er i ferd med å laste inn. Skeletons gir indikasjon på hvordan innholdsoppsettet vil se ut når det er ferdig innlastet, som et slags skjelett. **Stepper** Stepper brukes for å indikere hvilket steg brukeren er på i en prosess. Stepperen kan brukes som navigasjonsmønster mellom steg, eller som en visuell guide på progresjon. **Tag** Tags er visuelle merkelapper med tekst som kan brukes til å kategorisere elementer eller kommunisere status eller egenskaper. Til forskjell fra badge, er tags statiske tekster og mer beskrivende. De kan ikke klikkes på. **Toast** Toast er en midlertidig melding som vises i en viss tid på skjermen for å gi brukeren umiddelbar tilbakemelding om en utført handling. **Tooltip** En tooltip er en liten tekstboks som dukker opp når brukeren holder musen over et element. Tooltip brukes til å beskrive eller forklare et interaktivt element eller handlingen som elementet gjør. ![Eksempelvisning på komponenter som gjerne betegnes som skjemaelementer](https://cdn.sanity.io/images/ah2n1vfr/bekk-blogg-prod/fc91e88466004343f7eb97adf2cdd6bbd463eb38-4140x4244.png) _Eksempelvisning på komponenter som gjerne betegnes som skjemaelementer_ ### **Andre sentrale elementer** Utover dette bør også utilites (støttekomponenter), ikoner og typografi defineres som komponenter i et grunnleggende komponentbibliotek, ettersom de er sentrale elementer i et grensesnitt. **Typografi** Typografi-komponenter definerer hvordan tekst skal se ut og oppføre seg på tvers av digitale produkter. De skal sørge for at ulike tekststiler brukes konsekvent og i henhold til et visuelt hierarki. Eksempler på typografi-komponenter kan være overskrifter (headings), brødtekst (body), labels, lenker og sitater. **Ikoner** Ikon-komponenter er symboler som representerer brukerhandlinger eller konsepter. De brukes for å forbedre navigasjon og som støtte til tekst for å gjøre det enklere å forstå og interagere med digitale tjenester. Eksempler på ikon-komponenter kan være søkeikon, lukkekryss, menyikon (det såkalte hamburger-ikonet) og navigasjonspiler. I motsetning til løse SVG-ikoner vil ikon-komponenter bidra til konsistens i uttrykk og størrelse, og gjør det enklere å vedlikeholde siden oppdateringer gjøres sentralt. **Støttekomponenter** Såkalte «utilities» eller støttekomponenter er grunnleggende byggeklosser man trenger for å bygge gjenbrukbare layouter og struktur i grensesnittet på en fleksibel og konsistent måte, som for eksempel grid eller containere. ## Hvordan prioritere implementasjon av komponentene? Ethvert designsystem og organisasjon har sine egne behov og bruksmønster, så det _vil_ variere fra sted til sted hvilke komponenter som er relevante å inkludere i et komponentbibliotek. Prioriteringen av utviklingen av komponenter bør reflektere dette, samtidig som man bør ta hensyn til kompleksiteten i komponentene og bruksmønster. Likevel er det noen prinsipper som kan være til hjelp i arbeidet med å prioritere rekkefølgen for implementeringen i komponentbiblioteket ditt. ### **1. Start med de mest grunnleggende komponentene som brukes for å bygge opp andre komponenter** Det er naturlig å starte med å bygge de komponentene som er byggesteiner for andre komponenter igjen slik som typografi, ikoner og utilities som grid, spacing og marginer, da det legger fundamentet for resten av biblioteket. I tillegg bør du starte med å implementere de mest essensielle komponentene som brukes på tvers av sider og ulike funksjoner. Dette er for eksempel knapper og lenker som er blant de mest brukte modulene i ethvert digitale grensesnitt. ### **2. Identifiser de mest brukte brukerhandlingene og bygg komponenter som trengs for disse** Etter man har de mest grunnleggende komponentene på plass, bør du kartlegge hvilke handlinger som brukerne av produktene dine gjør oftest og bygge de komponentene som trengs for å utføre disse handlingene. Eksempelvis vil inputfelter og andre skjemaelementer som checkboxer, radioknapper og combobox ofte være viktig å ha på plass tidlig i et komponentbibliotek, siden disse er essensielle elementer i alt fra brukerregistrering og søk, til å fylle ut skjemaer. Husk å ta hensyn til validering ved implementasjon av slike elementer, slik at brukeren kan skrive inn informasjon på en enkel og feilfri måte. ### **3. Prioriter komponenter for navigasjon og tilbakemeldinger** Videre bør man prioritere komponenter som hjelper brukeren å navigere og gjør det lett å finne frem til ting, slik som menyer, brødsmulestier og paginering. Varsler og tilbakemeldinger som hjelpetekst og lasteelementer er også viktig å ha på plass tidlig i et komponentbibliotek for å gi brukeren informasjon og status på hva som skjer eller har skjedd - enten det er en suksessmelding, feil, advarsel eller annen visuell hjelp. ### **4. Bygg mer avansert funksjonalitet og mønstre når grunnleggende funksjoner er på plass** Når grunnfunksjoner er på plass, kan du jobbe med mer komplekse komponenter og funksjonalitet som trengs for mer spesifikke bruksmønstre slik som accordions, modaler og tabeller. Avanserte inputfelter som multiselect og datovelgere kan nedprioriteres og implementeres på et senere tidspunkt hvis de ikke er nødvendig og kritisk for produktet. #### **Oppsummert kan en anbefalt rekkefølge for implementering være:** 1. Grunnstruktur: Typografi, ikoner og støttekomponenter som grid og spacing 2. Kjerneinteraksjon: Knapper, lenker og skjemaelementer 3. Navigasjon og tilbakemelding: Menyer, paginering og varsler 4. Kompleks funksjonalitet og mønstre: Modaler, tabeller og avanserte komponenter som kalendere. Helt til slutt, her er fire fine tips som være til hjelp for å bestemme hvilke komponenter som bør inngå i deres komponentbibliotek, og hvordan du kan prioritere implementasjonen av dem: - **Identifiser behov** ved å samle innsikt fra teamene om hvilke komponenter som er mest kritiske i løsningene deres. - **Bruk design tokens** når du designer og utvikler komponenter for å muliggjøre rask endring og støtte for ulike moduser, temaer og varianter. - **Jobb modulært** ved å bygge små, fleksible deler som kan videreutvikles til større, mer komplekse komponenter senere. - **Jobb iterativt** ved å implementere komponenter og teste dem kontinuerlig i reelle kontekster for å sikre god funksjonalitet og brukeropplevelse.