De flesta designsystem dör inte av att de var dåligt gjorda. De dör av att ingen underhåller dem, att produktteamen börjar bygga vid sidan av dem, och att avståndet mellan biblioteket och verkligheten till slut blir så stort att biblioteket blir en belastning. Det tar sällan mer än tre år.
De få som överlever ett decennium har en sak gemensamt: de behandlas som en produkt med användare, inte som ett projekt med en leverans. Allt annat följer av den skillnaden.
Börja med det som redan finns
Den vanligaste starten är också den sämsta: en designer och en utvecklare får i uppdrag att bygga ett komplett bibliotek innan någon använder det. Sex månader senare finns fyrtio komponenter, varav produktteamen behöver tolv och tycker att fem av dem är fel.
Vi föredrar att börja med en inventering. Gå igenom det som faktiskt finns i produktion i dag och räkna. Hur många olika knappar finns det? Hur många nyanser av grått? Hur många sätt att visa ett felmeddelande? Siffrorna brukar vara pinsamma nog att skapa mandat, och de pekar samtidigt ut vilka komponenter som är värda att göra först.
Sedan görs de fem eller sex mest använda komponenterna ordentligt, i samarbete med det team som ska använda dem först. Inte som ett bibliotek som lanseras, utan som något som redan är i drift på ett ställe den dag det annonseras. En komponent med en riktig användare är värd tio som väntar på sin första.
Tokens är kontraktet
Om det finns en del av ett designsystem som är värd att göra rätt från början är det de underliggande värdena: färger, avstånd, typografi, radier, skuggor. De ändras mer sällan än komponenterna och de är svårast att byta i efterhand.
Två regler har hållit för oss. Den första är att namnge efter roll, inte efter utseende. En färg som heter ytan-under-kortet överlever en omprofilering. En färg som heter ljusgrå-2 gör det inte, och det slutar med att den ljusgrå färgen är mörkblå i mörkt läge.
Den andra är att låta komponenterna aldrig innehålla ett eget värde. I samma stund som en enda komponent har ett hårdkodat avstånd har systemet fått en spricka, och sprickor sprider sig fort eftersom nästa utvecklare kopierar den komponent som ligger närmast. Vi brukar bygga in ett automatiskt test som letar efter råa värden, just för att den regeln inte överlever på god vilja.
Regeln för när något får bli en komponent
Ett designsystem som växer okontrollerat blir ett bibliotek ingen orkar leta i. Vår regel är enkel: något får bli en delad komponent när det används på tre ställen av minst två team, och när det ser likadant ut på alla tre.
Kravet på tre användningar filtrerar bort det som bara råkade dyka upp två gånger. Kravet på två team filtrerar bort det som egentligen är ett teams interna lösning. Kravet på att det ska se likadant ut är det viktigaste och det som oftast ignoreras: om tre team gör nästan samma sak på tre olika sätt är det inte en komponent, det är ett designbeslut som ingen har fattat än.
Undantaget är komponenter med tillgänglighetslogik. En dialog, en meny, en kombinationsruta. De är svåra att göra rätt och nästan alltid fel när de görs lokalt, så de bör centraliseras redan vid första användningen. Det arbete ett produktteam sparar där motiverar hela systemet på egen hand.
Versionshantering utan att låsa någon
Ett system som kräver att alla uppgraderar samtidigt kommer att sluta uppgraderas. Ett system där ingen någonsin uppgraderar splittras i sju versioner. Vägen mellan de två går genom att ändringar nästan alltid är bakåtkompatibla, och att de få som inte är det kommer med verktyg.
I praktiken betyder det att en komponent som ska ändras i grunden får en ny variant vid sidan av den gamla, att den gamla markeras som avvecklad med ett datum, och att det finns ett skript som gör den mekaniska delen av bytet. Att skicka ut en ändring som kräver manuellt arbete i fem produktteam är att skicka en räkning till någon annans budget, och den räkningen betalas inte.
Vi rekommenderar också att systemet aldrig har fler än två versioner i drift samtidigt. Fler än så och stödfrågorna blir omöjliga att svara på, eftersom svaret alltid börjar med en motfråga om vilken version som avses.
Dokumentation som faktiskt används
Dokumentationen till ett designsystem läses nästan aldrig i förväg. Den läses när någon sitter fast, och då i tio sekunder. Det gör att den vanliga strukturen med en introduktion, riktlinjer och principer är i stort sett bortkastad, medan exemplet högst upp på komponentsidan är det enda som betyder något.
Vi skriver därför varje komponentsida baklänges. Först ett exempel som går att kopiera och som gör något meningsfullt. Sedan varianterna, med bild. Sedan när komponenten inte ska användas, vilket är den mest värdefulla och mest utelämnade delen. Riktlinjerna sist, för de som söker dem.
Den sista punkten förtjänar en utveckling. En komponentsida som bara beskriver vad komponenten gör lämnar valet mellan tre snarlika komponenter till läsaren, och det valet blir godtyckligt. En sida som säger att den här inte ska användas för navigering, använd länken i stället, avgör frågan på en rad. Det är också där ett designsystem faktiskt utövar sin styrning, långt effektivare än i något styrdokument.
Mörkt läge avslöjar om tokens håller
Ett bra test på om de underliggande värdena är rätt namngivna är att införa ett andra tema. Om varje token har ett namn efter sin roll går det oftast att göra på ett par dagar. Om de heter saker efter sitt utseende blir det ett projekt, för då måste varje användning läsas och tolkas.
Vi rekommenderar att göra det testet tidigt även om det andra temat inte ska släppas. Det kostar en vecka och det ger ett svar på om systemet är byggt på ett sätt som klarar en framtida omprofilering. Att upptäcka svaret när marknadsavdelningen redan bytt profil är betydligt dyrare.
Samma sak gäller täthet. Ett gränssnitt som ska fungera både för en handläggare med mycket data på skärmen och för en kund på en telefon behöver kunna skala sina avstånd utan att varje komponent skrivs om. Om det går har systemet en verklig struktur. Om det inte går är det en samling komponenter som råkar se lika ut i dag.
Vem som betalar
Den fråga som avgör om ett designsystem finns kvar om fem år är vem som betalar för det när det inte är nytt längre. Ett system som finansieras av ett projekt lever så länge projektet lever. Ett system som finansieras som en löpande kostnad, med minst en person som har det som huvuduppgift, klarar sig.
Bemanningen behöver inte vara stor. En person på heltid och en designer på halvtid räcker långt för ett system som stödjer tio produktteam, förutsatt att produktteamen får bidra med komponenter själva. Det som inte fungerar är noll personer och en förhoppning om att alla ska underhålla det på sin lediga tid, vilket ändå är den vanligaste modellen.
Måttet som betyder något
Antalet komponenter är ett dåligt mått. Antalet team som använder systemet är bättre. Det bästa måttet vi har hittat är hur stor andel av gränssnittet i produktion som är byggt av systemets komponenter, mätt automatiskt och följt över tid.
Den siffran går att räkna fram, den går inte att prata sig ur, och den fångar det som faktiskt spelar roll: om systemet är den enklaste vägen för den som ska bygga något i dag. Är det inte det kommer det att kringgås, oavsett hur väl det är dokumenterat och hur mycket alla är överens om att det borde användas.