Design system eller UI kit?

“Vi behöver ett design system” är en av de vanligaste – och dyraste – felbeställningarna inom digital design. Ofta är det ett UI kit man är ute efter, ibland är det verkligen ett helt system. Skillnaden är en ambitionsnivå, och att förstå den sparar dig från att betala för styrning du inte behöver, eller att bygga för tunt och få göra om.

Definitionsskillnaden

Ett UI kit är ett komponentbibliotek. Det är en samling färdiga, återanvändbara gränssnittsdelar – knappar, formulärfält, kort, menyer – som designers plockar från när de ritar. Nyttan är konsekvens och tempo: ingen behöver rita en knapp från grunden, och alla knappar ser likadana ut.

Ett design system innehåller ett UI kit, men är mycket mer. Det lägger till fyra saker:

• Principer – de uttalade reglerna och besluten bakom komponenterna, så att nya delar kan skapas i samma anda i stället för på känsla.
• Designtokens – namngivna värden för färg, avstånd och typografi som lagras centralt och delas av både design och kod.
• Kod – de faktiska, byggda komponenterna som utvecklare använder, inte bara ritade motsvarigheter.
• Styrning – någon som äger systemet, beslutar om ändringar och håller det levande över tid.

Kortversionen: ett UI kit är byggblocken. Ett design system är byggblocken plus reglerna, koden och ansvaret för att hålla dem i takt.

Mognadstrappan

Skillnaden blir tydligast som en trappa, där varje steg kostar mer men ger mer sammanhållning.

De flesta organisationer börjar högst upp och behöver inte klättra hela vägen. En stilguide räcker långt för ett litet varumärke. Ett UI kit räcker för en enskild produkt med ett litet team. Först när flera produkter och team ska dela samma grund blir de nedre stegen värda sin kostnad.

Signalerna att kliva upp en nivå

Hur vet du att du vuxit ur ett UI kit? Signalerna är konkreta och känns igen i vardagen.

Samma komponent börjar leva i flera versioner. En designer ritar en ny knapp för att den gamla inte hittades, och plötsligt finns tre snarlika knappar i produkten. Design och kod glider isär: det som visas i verktyget stämmer inte längre med det som är byggt, och ingen vet vilken version som gäller. Flera team bygger parallellt och tolkar samma komponent olika, så att produkterna långsamt börjar spreta.

Ett konkret exempel: ett bolag med en produkt klarar sig länge på ett UI kit. När de lanserar en andra produkt och sätter ett andra team på den upptäcker de snart att primärfärgen finns inkodad på ett dussin ställen, och att en ändring kräver att någon letar upp varenda ett. Det är precis det problemet designtokens och delad kod löser – och signalen att det är dags att kliva upp till ett riktigt system.

Ett vanligt misstag: att bygga för stort för tidigt

Den dyraste felkällan är att en organisation med en enda produkt bestämmer sig för att bygga ett fullskaligt design system “för framtiden”. Man lägger månader på tokens, styrning och dokumentation för en produkt som ännu inte ändrar sig snabbt nog för att motivera det. Systemet blir en administrativ börda i stället för en hjälp, och när behovet väl uppstår har mycket ändå hunnit bli inaktuellt.

Det motsatta misstaget finns också: att låta ett växande produktbolag ligga kvar på en enkel stilguide långt efter att flera team börjat trampa varandra på tårna. Båda felen kostar, och båda undviks med samma fråga – vilken nivå löser de problem vi faktiskt har just nu? Bygg för nuläget plus ett kliv, inte för en tänkt framtid flera steg bort.

Poängen är att bygga rätt nivå för läget du är i. Behöver ni reda ut var ni står och vad nästa steg bör vara, ingår design systems i våra tjänster. Vi på Weapp bygger dem stegvis, så att ni betalar för sammanhållning i takt med att behovet växer – hör av dig så tittar vi på var er gräns går.