Designsystem eller UI-kit?

«Vi trenger et designsystem» er en av de vanligste og dyreste feilbestillingene innen digital design. Ofte er det et UI-kit man er ute etter, men noen ganger trengs det virkelig et helt system. Forskjellen handler om ambisjonsnivå, og når du forstår den, slipper du å betale for styring du ikke trenger, eller å bygge for tynt og måtte gjøre det om igjen.

Forskjellen i definisjon

Et UI-kit er et komponentbibliotek. Det er en samling ferdige, gjenbrukbare grensesnittdeler (knapper, skjemafelt, kort, menyer) som designere henter fra når de tegner. Nytten er konsistens og tempo: Ingen trenger å tegne en knapp fra bunnen av, og alle knapper ser like ut.

Et designsystem inneholder et UI-kit, men er mye mer. Det legger til fire ting:

• Prinsipper: de uttalte reglene og beslutningene bak komponentene slik at nye deler kan lages i samme ånd i stedet for etter magefølelsen.
• Designtokens: navngitte verdier for farge, avstand og typografi som lagres sentralt og deles av både design og kode.
• Kode: de faktiske, ferdigbygde komponentene som utviklerne bruker, ikke bare tegnede motstykker.
• Styring: noen som eier systemet, beslutter endringer og holder det levende over tid.

Kortversjonen: Et UI-kit er byggeklossene. Et designsystem er byggeklossene pluss reglene, koden og ansvaret for å holde dem i takt.

Modenhetstrappen

Forskjellen blir tydeligst som en trapp der hvert trinn koster mer, men gir mer sammenheng.

De fleste organisasjoner begynner øverst og trenger ikke å gå hele veien. Med en stilguide kommer et lite varemerke langt. Et UI-kit er nok for ett eneste produkt med et lite team. Først når flere produkter og team skal dele samme grunnlag, blir de nederste trinnene verdt kostnaden.

Tegnene på at det er tid for neste nivå

Hvordan vet du at du har vokst ut av et UI-kit? Signalene er konkrete og lette å kjenne igjen i hverdagen.

Den samme komponenten begynner å finnes i flere versjoner. En designer tegner en ny knapp fordi ingen fant den gamle, og plutselig finnes det tre nesten like knapper i produktet. Design og kode glir fra hverandre: Det som vises i verktøyet, stemmer ikke lenger med det som er bygget, og ingen vet hvilken versjon som gjelder. Flere team bygger parallelt og tolker den samme komponenten ulikt, og produktene begynner sakte å sprike.

Et konkret eksempel: En bedrift med ett produkt klarer seg lenge med et UI-kit. Når de lanserer et produkt nummer to og setter et nytt team på det, oppdager de snart at primærfargen er hardkodet på et dusin steder, og at en endring krever at noen leter opp hvert eneste ett. Det er nettopp det problemet designtokens og delt kode løser, og signalet om at det er på tide å gå over til et fullverdig system.

En vanlig feil: å bygge for stort for tidlig

Den dyreste feilkilden er at en organisasjon med ett eneste produkt bestemmer seg for å bygge et fullskala designsystem «for fremtiden». Man bruker måneder på tokens, styring og dokumentasjon for et produkt som ennå ikke endrer seg raskt nok til at det er verdt det. Systemet blir en administrativ byrde i stedet for en hjelp, og når behovet endelig oppstår, har mye uansett rukket å bli utdatert.

Den motsatte feilen finnes også: å la et voksende produktselskap bli stående på en enkel stilguide lenge etter at flere team har begynt å tråkke hverandre på tærne. Begge feilene koster, og begge unngås med det samme spørsmålet: Hvilket nivå løser de problemene vi faktisk har akkurat nå? Bygg for dagens behov pluss ett trinn, ikke for en tenkt fremtid flere trinn unna.

Poenget er å bygge riktig nivå for situasjonen dere er i. Trenger dere å finne ut hvor dere står og hva neste steg bør være? Designsystemer inngår i tjenestene våre. Vi i Weapp bygger dem trinnvis slik at dere betaler for sammenheng i takt med at behovet vokser. Ta kontakt, så ser vi på hvor grensen går for dere.