Design system eller UI kit?

“Vi har brug for et designsystem” er en af de mest almindelige og dyreste fejlbestillinger inden for digitalt design. Ofte er det et UI kit man er ude efter, nogle gange er det virkelig et helt system. Forskellen handler om ambitionsniveau, og at forstå den sparer dig for at betale for styring du ikke har brug for, eller for at bygge for tyndt og måtte lave det om.

Forskellen i definitionen

Et UI kit er et komponentbibliotek. Det er en samling færdige, genbrugelige dele af brugerfladen (knapper, formularfelter, kort, menuer) som designere plukker fra når de tegner. Nytten er konsistens og tempo: Ingen behøver at tegne en knap fra bunden, og alle knapper ser ens ud.

Et designsystem indeholder et UI kit, men er meget mere. Det tilføjer fire ting:

• Principper: de udtalte regler og beslutninger bag komponenterne så nye dele kan skabes i samme ånd i stedet for på fornemmelse.
• Design tokens: navngivne værdier for farve, afstand og typografi der gemmes centralt og deles af både design og kode.
• Kode: de faktiske, byggede komponenter som udviklerne bruger, ikke kun tegnede modstykker.
• Styring: nogen der ejer systemet, beslutter ændringer og holder det levende over tid.

Den korte version: Et UI kit er byggeklodserne. Et designsystem er byggeklodserne plus reglerne, koden og ansvaret for at holde dem i takt.

Modenhedstrappen

Forskellen bliver tydeligst som en trappe hvor hvert trin koster mere, men giver mere sammenhæng.

De fleste organisationer begynder øverst og behøver ikke at klatre hele vejen. En stilguide rækker langt for et lille brand. Et UI kit er nok til et enkelt produkt med et lille team. Først når flere produkter og teams skal dele samme fundament, bliver de nederste trin deres omkostning værd.

Tegnene på at det er tid til næste niveau

Hvordan ved du at du er vokset fra et UI kit? Signalerne er konkrete og genkendelige i hverdagen.

Den samme komponent begynder at leve i flere versioner. En designer tegner en ny knap fordi ingen kunne finde den gamle, og pludselig findes der tre næsten ens knapper i produktet. Design og kode glider fra hinanden: Det der vises i værktøjet, stemmer ikke længere med det der er bygget, og ingen ved hvilken version der gælder. Flere teams bygger parallelt og fortolker den samme komponent forskelligt så produkterne langsomt begynder at trække i hver sin retning.

Et konkret eksempel: En virksomhed med ét produkt klarer sig længe med et UI kit. Når de lancerer endnu et produkt og sætter et nyt team på det, opdager de hurtigt at primærfarven er hardkodet et dusin steder, og at en ændring kræver at nogen finder hvert eneste af dem. Det er præcis det problem design tokens og delt kode løser, og det er signalet om at tiden er inde til at tage skridtet op til et rigtigt system.

En almindelig fejl: at bygge for stort for tidligt

Den dyreste fejlkilde er at en organisation med ét enkelt produkt beslutter sig for at bygge et designsystem i fuld skala “til fremtiden”. Man bruger måneder på tokens, styring og dokumentation til et produkt der endnu ikke ændrer sig hurtigt nok til at retfærdiggøre det. Systemet bliver en administrativ byrde i stedet for en hjælp, og når behovet endelig opstår, er meget alligevel nået at blive forældet.

Den modsatte fejl findes også: at lade en voksende produktvirksomhed blive hængende ved en enkel stilguide længe efter at flere teams er begyndt at træde hinanden over tæerne. Begge fejl koster, og begge undgås med det samme spørgsmål: Hvilket niveau løser de problemer vi faktisk har lige nu? Byg til nutiden plus ét trin, ikke til en forestillet fremtid flere trin væk.

Pointen er at bygge det rigtige niveau til den situation du er i. Har I brug for at få afklaret hvor I står og hvad næste skridt bør være, indgår designsystemer i vores ydelser. Vi hos Weapp bygger dem trinvis så I betaler for sammenhæng i takt med at behovet vokser. Kontakt os, så ser vi på hvor jeres grænse går.