Designsystem

Et designsystem er en fælles ramme for, hvordan digitale produkter ser ud og opfører sig. Det kan indeholde designprincipper, farver, typografi, afstande, ikoner, kode og genbrugelige komponenter som knapper, formularfelter, kort og navigation.

Systemet ligger mellem en brand guide og den konkrete løsning. Brandguiden beskriver typisk identitet og visuelle regler på tværs af medier. Designsystemet omsætter en del af identiteten til digitale mønstre og komponenter, der kan bruges direkte af designere og udviklere.

Et designsystem er heller ikke det samme som en sidebygger eller et tema. Et WordPress-tema kan implementere systemet, men systemet beskriver også, hvornår komponenterne bruges, hvilke variationer der findes, og hvordan de opfører sig på mobil, med tastatur og ved fejl.

På en mindre hjemmeside kan systemet være enkelt: farver, typografi, knapper, formularer, kort og afstandsregler. På en stor platform kan det være en selvstændig produktdel med dokumentation, versionsstyring, test og bidragsproces.

Formålet er ikke at gøre alle sider ens. Formålet er at undgå, at det samme problem bliver løst på fem tilfældige måder. Et godt system skaber genkendelse og frigør tid til de dele af oplevelsen, der faktisk er særlige.

Start med at kortlægge gentagelser. Gennemgå eksisterende sider og find alle varianter af knapper, overskrifter, felter, kort, bokse og beskeder. Hvis der findes syv grønne farver og ni knaphøjder, har du et konkret oprydningspunkt.

Definér først de grundlæggende tokens: farver, skrifter, størrelser, afstande, hjørner, skygger og bevægelse. Navngiv dem efter funktion, ikke kun udseende. “Tekst-dæmpet” er mere robust end “grå-500”, når identiteten senere justeres.

Byg derefter komponenter med klare tilstande. En knap skal beskrives som normal, hover, fokus, aktiv og deaktiveret. Et formularfelt skal også vise fejl og hjælpetekst. Det er her UI og webtilgængelighed mødes i praktiske detaljer.

Dokumentér brugen med gode og dårlige eksempler. Skriv hvornår en primær knap bruges, hvor mange der må være i samme sektion, og hvornår et tekstlink er bedre. Kode alene fortæller ikke den redaktionelle hensigt.

Kobl design og udvikling. Komponenten i designfilen og komponenten i kode bør have samme navn og variationer. Ellers får designeren ét system og udvikleren et andet. På en webshop er det især vigtigt omkring produktkort, priser, lagerstatus, kurv og checkout.

Udpeg en ejer og en ændringsproces. Nye varianter bør ikke tilføjes, bare fordi én side har et særligt ønske. Undersøg først, om behovet kan løses med en eksisterende komponent, eller om variationen er generel nok til at høre hjemme i systemet.

En organisation har tre websites og en selvbetjeningsløsning. Hver løsning er bygget på forskellige tidspunkter. Den samme primære handling vises som grøn knap, blå knap, understreget link og orange boks. Brugerne møder ikke et konsekvent signal.

Teamet starter ikke med at redesigne alt. De vælger de mest brugte dele: typografi, farver, knapper, formularfelter, beskeder og navigation. Delene designes, kodes og testes i en isoleret oversigt, før de rulles ud.

En fælles primær knap får fast højde, tydelig fokustilstand og regler for tekstlængde. Formularfelter får samme labelplacering og fejlvisning. Det reducerer antallet af specialrettelser og gør nye sider hurtigere at bygge.

Under arbejdet opdager teamet, at en gammel farvekombination ikke har tilstrækkelig kontrast. Designsystemet gør problemet synligt på tværs, så én beslutning kan forbedre mange sider. Det er mere effektivt end at rette hver side tilfældigt.

Organisationen viser udvalgte løsninger i sine cases og bruger guiden om brugervenlige hjemmesider som kontrol af, om ensartetheden også hjælper brugerens næste skridt.

Den største faldgrube er at bygge et omfattende system før behovet er kendt. Et hold kan bruge måneder på tabeller, navngivning og sjældne komponenter, mens det levende produkt fortsat har konkrete problemer. Start med de dele, der bruges og skaber friktion nu.

En anden fejl er at behandle systemet som et engangsprojekt. Browserkrav, brand, indhold og produkt ændrer sig. Uden vedligeholdelse begynder teams at omgå systemet, og de lokale varianter vokser igen.

Pas på for stramme regler. Et designsystem skal skabe sammenhæng, men ikke forhindre en nødvendig ny løsning. Kræv en begrundelse og en vurdering, ikke blind lydighed. Gode systemer kan udvikle sig uden at blive tilfældige.

Det er også en fejl kun at dokumentere den pæne standardtilstand. Fejl, tomme resultater, lange oversættelser, små skærme og langsomme forbindelser er en del af produktet. Komponenter skal beskrives under de forhold, hvor de bliver sværest.

Endelig kan systemet blive ejet af én faggruppe. Hvis designere ændrer komponenter uden udviklere, eller udviklere ændrer kode uden design og indhold, glider versionerne fra hinanden. Ejerskabet bør være tværfagligt.

Et komponentbibliotek er en del af et designsystem, men begreberne er ikke identiske. Biblioteket indeholder genbrugelige dele. Systemet rummer også principper, tokens, dokumentation, arbejdsgange og beslutninger.

Designsystemer som GOV.UK Design System og Material Design kan bruges som inspiration, men de bør ikke kopieres ukritisk. De er bygget til andre organisationer, målgrupper og tekniske rammer.

Tilgængelighed bør bygges ind i komponenterne. Når fokusmarkering, labelstruktur og kontrast er korrekt i den fælles komponent, bliver det lettere at skabe tilgængelige sider. Det fjerner dog ikke behovet for at teste den samlede brugerrejse.

Et designsystem kan styrke responsivt design, fordi komponenternes opførsel på forskellige skærme defineres én gang. Det bør beskrive, hvordan indhold bryder om, hvad der skjules, og hvordan touchmål fungerer.

Brug en prototype til at afprøve nye mønstre, før de optages i systemet. Når et mønster er testet i en rigtig opgave, ved teamet mere om dets variationer og begrænsninger.

Et lille system kan være professionelt. Ti velbeskrevne komponenter, som faktisk bruges, er mere værd end 80 teoretiske komponenter uden ejerskab eller kode.

Før en enkel ændringslog. Notér hvad der er ændret, hvorfor, og hvilke produkter der påvirkes. Det gør versionsskift lettere og hjælper redaktører med at forstå nye muligheder.

Mål brugen af komponenterne. Hvis en variant aldrig bruges, kan den måske fjernes. Hvis teams ofte bygger den samme lokale løsning, mangler systemet sandsynligvis noget.

Planlæg faste, korte gennemgange frem for sjældne totalrevisioner. Små beslutninger om fejltilstande, indhold og kode holder systemet tæt på den daglige drift.

Den bedste indikator er ikke antallet af komponenter, men om nye sider bliver mere ensartede, hurtigere at bygge og lettere at bruge.

Et designsystem bør beskrive mere end form. Knaptekster, fejlbeskeder, labels og tomme tilstande gentages på tværs af løsningen. Faste principper for sprog gør komponenterne mere genkendelige og lettere at bruge.

En formularfejl bør eksempelvis fortælle, hvad der er galt, og hvordan det rettes. “Ugyldig værdi” er teknisk korrekt, men hjælper sjældent brugeren. Dokumentér konkrete mønstre for telefonnummer, dato, adgangskode og obligatoriske felter.

Tag højde for lange ord, dynamiske produktnavne og oversættelser. En komponent, der kun er testet med “Læs mere”, kan bryde sammen med en rigtig CTA på mobil. Brug realistisk indhold i både design og kode.

Redaktører bør kende rammerne uden at skulle forstå hele systemet. En kort vejledning i WordPress kan vise, hvilke blokke der bruges til hvilke typer indhold, og hvilke kombinationer der bør undgås.

Når komponent, indhold og kode dokumenteres samlet, bliver systemet et praktisk arbejdsredskab. Ellers risikerer det at være en pæn reference, som den levende hjemmeside langsomt bevæger sig væk fra.

Følg konkrete tegn på gevinst: færre specialkomponenter, kortere udviklingstid, færre tilgængelighedsfejl og mindre variation mellem sider. Et designsystem skal kunne mærkes i arbejdet, ikke kun tælles i dokumentationen.

Spørg også redaktører og udviklere, hvor de stadig må improvisere. De svar viser, om systemet mangler en komponent, eller om den eksisterende dokumentation er for svær at finde.