Designsystem för webbplatser: när det lönar sig
Ett designsystem är en delad uppsättning visuella beslut och återanvändbara komponenter. Välgjort snabbar det upp allt efterföljande arbete. Fel dimensionerat blir det ett parallellt projekt som slukar tid och blir inaktuellt.
Den här guiden visar vad du tar med, när det lönar sig, och hur du börjar utan att bygga ett bibliotek ingen kommer använda.
Vad det innehåller, från väsentligt till tillbehör#
Börja högst upp i listan. De första posterna löser merparten av problemet.
| Lager | Innehåll | Prioritet |
|---|---|---|
| Grunder | Färger, typografi, avståndsskala | Väsentligt |
| Element | Knappar, fält, länkar, etiketter | Väsentligt |
| Mönster | Formulär, kort, navigation, tabeller | Hög |
| Mallar | Kompletta sidlayouter | Medel |
| Skrivriktlinjer | Ton, etiketter, felmeddelanden | Hög och ofta bortglömd |
| Användningsregler | När man använder vilken komponent | Medel |
| Levande dokumentation | Exempel som kör riktig kod | Beror på skala |
Skrivriktlinjer är det mest underskattade lagret. Inkonsekventa etiketter och meddelanden skadar upplevelsen lika mycket som inkonsekventa komponenter.
När det lönar sig#
Ett designsystem har en skapande- och en förvaltningskostnad. Det lönar sig när det finns tillräcklig upprepning för att amortera den.
- Flera produkter eller webbplatser som ska se ut som samma varumärke.
- Ett team där fler än en person designar eller bygger gränssnitt.
- En stor webbplats med många mallar och förväntad tillväxt.
- Byte av leverantörer, där konsekvens hänger på dokumentation.
- Lönar sig inte: en företagswebbplats på tio sidor med en enda ansvarig.
- Lönar sig inte: när webbplatsen ändå ska byggas om inom ett år.
- I de fallen räcker en stilfil med färger, typsnitt och knappar gott och väl.
Att börja smått#
Det pålitligaste sättet att få ett designsystem är att extrahera det ur det som redan finns, i stället för att designa i abstraktion.
- Gör en inventering: fånga alla knappar, fält och kort från nuvarande webbplats.
- Du kommer hitta för många varianter. Välj en av varje och ta bort resten.
- Definiera tokens: färger, typsnitt, avstånd, radier, skuggor — som namngivna variabler.
- Bygg de fem till tio komponenter som förekommer överallt.
- Dokumentera var och en med tillstånd och en anteckning om när den används.
- Tillämpa på en riktig mall innan du fortsätter; tillämpningen avslöjar vad som saknas.
- Först därefter utökar du, och bara när en komponent behövs mer än två gånger.
Ett system extraherat ur den riktiga webbplatsen används; ett system designat i abstraktion ser fint ut i dokumentationen och ignoreras i praktiken.
Hur designsystem dör#
Felmoderna är förutsägbara och nästan alla organisatoriska.
| Felmod | Tecken | Förebyggande |
|---|---|---|
| Ingen är ansvarig | Slutar uppdateras | En ägare med avsatt tid |
| Ur fas med koden | Dokumentationen ljuger | Generera från riktig kod |
| För stelt | Team går runt det | Tillåt dokumenterade undantag |
| För stort | Ingen hittar något | Börja med tio komponenter |
| Bristande uppslutning | Duplicerade komponenter utanför systemet | Involvera användarna från början |
| Bara design, ingen kod | Utvecklare bygger om för hand | Riktiga komponenter, inte bara skärmar |
Vanliga frågor
Behöver jag ett designsystem för en liten webbplats?
Nej. För en företagswebbplats med en enda ansvarig räcker en stilfil med färger, typografi, avstånd och några komponenter, och den fyller samma funktion. Ett formellt system lönar sig först när flera personer eller flera produkter ska hålla ihop.
Hur lång tid tar det att skapa?
En användbar första version — tokens plus tio komponenter — tar två till fyra veckor. Ett komplett system med dokumentation, kod och riktlinjer tar månader och blir aldrig riktigt klart, eftersom det följer produkten. Börja smått och tillämpa tidigt istället för att sikta på komplett innan användning.
Ska jag använda ett befintligt bibliotek?
Ofta ja, särskilt i interna applikationer där visuell identitet betyder mindre än tempo. Ett moget bibliotek ger dig tillgängliga och testade komponenter direkt. Anpassa det med dina tokens istället för att bygga allt från grunden — att bygga tillgängliga komponenter från noll är mer arbete än det verkar.
Vem ska ansvara för designsystemet?
En utsedd person med faktiskt avsatt tid. Utan ägare blir systemet inaktuellt på månader och blir ett hinder istället för en hjälp, eftersom dokumentationen slutar motsvara produkten. Det här är den vanligaste felmoden, och den är organisatorisk snarare än teknisk.
designsystemkomponentbibliotekdesigntokensstilguidevisuell konsekvensåteranvändbara komponenter
