När ett team växer från två till åtta personer brukar samma problem dyka upp. Knappar som ser olika ut i olika delar av produkten, färger som avviker några nyanser, och formulär som fungerar på tre olika sätt beroende på vem som byggde dem. Det som började som små avvikelser blir snabbt ett underhållsproblem.

Ett designsystem är tänkt att lösa just det. Men varje team som försöker bygga ett inser snabbt att arbetet tar längre tid än förväntat. Ofta mycket längre.

Vad som egentligen ingår i ett designsystem

Ett designsystem är mer än en samling färger och typsnitt. Det är en levande infrastruktur som innehåller designtokens, komponentbibliotek, användningsmönster, tillgänglighetsdirektiv och riktlinjer för hur allt ska användas i praktiken.

Designtokens är värdena som bär hela systemet. De definierar färger, typografi, avstånd, skuggor och radier på ett sätt som kan översättas till både design och kod. När en färg byts ut i tokenfilen uppdateras den överallt där den används, oavsett om det är i Figma, React eller en dokumentationswebbplats.

Komponenter är de återanvändbara byggstenarna. Knappar, inputfält, dropdowns, modaler, meddelanden. Varje komponent måste fungera i olika varianter, stödja olika tillstånd och klara av olika sammanhang. En knapp kan behöva finnas i fem storlekar, tre visuella stilar, med eller utan ikon, aktiverad eller inaktiverad, och i ljust eller mörkt läge.

Dokumentation är det som gör systemet användbart. Utan den blir komponenterna bara en samling filer som ingen vågar röra. Dokumentationen förklarar när en komponent ska användas, vilka varianter som finns, hur den beter sig i olika tillstånd, och hur den testas för tillgänglighet.

Varför det tar så mycket längre tid än förväntad

De flesta projekt börjar med en ambition att bygga ett komplett designsystem på några veckor. Men redan i skissfasen dyker frågor upp som kräver beslut. Ska primärknappen ha rundade hörn eller skarpa? Hur stor ska minsta klickbara yta vara för att uppfylla WCAG-kraven? Hur många nyanser av grått behövs egentligen?

Varje sådan fråga verkar liten, men varje beslut påverkar tiotals andra komponenter. En färgskala som fungerar för knappar kanske inte fungerar för statusmeddelanden. En avståndsskala som ser bra ut i en prototyp kanske inte skalas när densiteten ökar i en riktig produkt.

Designsystem kräver också konsensus. Varje komponent måste godkännas av designers, utvecklare, produktägare och ofta även tillgänglighetsspecialister. Det tar tid att samla alla, diskutera alternativen, testa lösningarna och komma överens om vad som ska gälla framåt.

Samma sak gäller saker som fotografering och video för företag, där det inte bara är själva shooten (tillfället) som tar tid, det ingår mycket redigering efter själva händelsen.

Teknisk implementation är bara halva arbetet

När designen är klar börjar det tekniska arbetet. Komponenterna måste byggas så att de fungerar i den miljö teamet använder, ofta React, Vue eller Angular. De måste stödja olika ramverk, fungera med olika tillståndshanterare, och klara av att integreras med befintlig kod.

Samtidigt måste komponenterna vara flexibla nog att täcka många användningsfall, men inte så flexibla att de blir omöjliga att underhålla. En knapp som accepterar hundra olika props blir snabbt ohanterlig. En knapp som bara accepterar tre varianter kanske inte räcker för produktens behov.

Tillgänglighet är en annan stor utmaning. Varje komponent måste fungera med tangentbord, skärmläsare och andra hjälpmedel. Det kräver korrekt semantisk HTML, ARIA-attribut där det behövs, och noga testning med riktiga användare. En dropdown som ser fin ut men inte går att navigera med tangentbordet är värdelös.

Versionshantering och distribution skapar nya problem

När systemet väl är byggt måste det distribueras. De flesta team använder npm-paket eller liknande för att dela komponenter mellan projekt. Men det innebär också att systemet måste versionshanteras, att ändringar måste kommuniceras, och att breaking changes måste hanteras utan att förstöra produktionen.

Ett designsystem är …