7 grunde til, at I skal bruge et designsystem
Blogartikel

7 grunde til, at I skal bruge et designsystem

16. oktober 2019

Umiddelbart forbinder du design med kreativitet og systemer med kassetænkning, så at sætte de to ord sammen, og ovenikøbet antyde at det er svaret på dine kreative bønner, virker en anelse selvmodsigende. Jeg ved det godt. Men designsystemer, når du bruger dem rigtigt og på det rigtige tidspunkt, er uvurderlige. Derfor får du her en liste med de syv vigtigste argumenter, som du skal bruge, når du skal overbevise din chef eller dine kollegaer om, at I selvfølgelig skal sætte jeres digitale udtryk i system.  

 

(Psst! Hvis du allerede er erklæret fortaler for designsystemer, men har brug for at få hul igennem til den nærmeste mellemleder, så scroller du bare ned til listen i bunden).

Walk me through it, please!

Okay, lad os begynde med begyndelsen. Et designsystem er nemlig en lidt broget størrelse, så det kan godt betale sig med en god gammeldags definition.

Designsystemer er i bund og grund en slags systemdokumentation over design- og UX-mæssige beslutninger, som er ejet af alle interessenter. Det var den korte version.

Her kommer den forståelige:

Termen ‘designsystem’ er forholdsvis ny, men det er indholdet ikke. Designerne kalder det for ‘design guidelines’, udviklerne taler om ‘komponentbibliotek’, og de ansvarlige for content kan ikke undvære deres Tone of Voice-principper.

Når vi snakker designsystemer, taler vi om den overligger, som indeholder alle faggruppernes bidrag til organisationens digitale (og for den sags skyld analoge) udtryk. Det betyder også, at designsystemer ikke er forbeholdt én faggruppe, men i dag i højere grad er et værktøj, der styrker samarbejdet og kommunikationen på tværs af fagligheder.

Uanset hvem der bidrager til designsystemet, og hvad de kalder det, så tjener dokumentationen af de her principper det samme formål: At sikre konsistens og kvalitet og en langt mere effektiv design- og udviklingsfase.

Hvornår skal du så bruge et designsystem?

Med den fanfare af en optakt forventer du selvfølgelig, at jeg råbe-svarer “ALTID, SELVFØLGELIG!” Men jeg er nødt til at gå med alle politikeres grundskolelærdom og sige:

“Det kommer an på.”

For designsystemer er ikke noget, der bare på magisk vis opstår, når vi begynder at udvikle og designe digitale løsninger. Tværtimod kræver det omtanke og benarbejde at sætte design, brugergrænseflader og content i system. Og den investering giver især mening, når...

… dit projekt skal leve over lang tid
Nogle af vores kunder siger, at de ikke vil bruge designsystemer, fordi det tager for lang tid at lave (læs: Det er for dyrt). Det koster givetvis lidt ekstra tid - og dermed penge - i starten af et projekt (pga. føromtalte benarbejde).

Men når fundamentet er på plads, er systemet også lynhurtigt til at kaste gevinster af sig.

Og ja, jeg har et eksempel:

Vi har for nylig lavet et stort redesign for en kunde. Her kørte vi kontinuerligt en triangulering mellem Sketch, designernes redskab, vores designsystem og backenden. Når designerne lavede en komponent i Sketch, implementerede vi den i designsystemet, og herfra trak vi alle de dele, som vi byggede sitet af.

Det betyder, at vi kun skal lave rettelser ét sted, så slår de igennem overalt, og vi sparer en masse tid i vedligehold af designet.

… dit projekt kræver et tværfagligt samarbejde
At det faciliterer tværfagligt samarbejde er nok én af designsystemets vigtigste egenskaber. Og her snakker vi ikke kun den tværfaglighed, du kan dyrke henover genboens computerskærm. For designsystemer kommer i høj grad til deres ret i de projekter, hvor samarbejdet krydser både by- og landegrænser.

Jo mere komplekst et projekt er – og jo flere interessenter, der er involveret – jo vigtigere er det at have et system, der holder styr på al data og alle de kreative processer og beslutninger i et projekt. Og det er her, designsystemet bliver din bedste ven.

Men kan det overhovedet betale sig?

I langt de fleste projekter eller digitale løsninger, som er af en vis varighed og/eller indeholder en grad af samarbejde på tværs af lokaliteter og fagligheder, kan designsystemer i den grad betale sig.

Det kræver naturligvis en villighed til at investere i opbygningen af designsystemet, men mindst lige så vigtigt: En villighed til at bruge og vedligeholde det fra alle parter.

Hvad du får til gengæld er et system, der kan bygge bedre og mere robuste produkter, hurtigere end normalt.

Og hvis det ikke er nok, så får du her:

 7 lynhurtige argumenter, som overbeviser dit team, din chef og din kunde på én gang

Her får du de syv væsentligste argumenter for at bruge et designsystem - du er velkommen til selv at tage æren for dem:

1. Designsystemer skaber overblik og sikrer effektivitet. Designsystemet er et samlet kartotek over alt fra UI-komponenter til farver, fonte, kode og content. Når du har al data samlet på ét sted, er der ingen slingrekurs. Du slipper for “Valgte vi egentlig 10px eller 12px?” og for at lede en endeløs række af ustrukturerede mapper igennem for at finde den forjættede _final-fil.

2. Designsystemer sikrer genbrugelighed. Her er et argument, som dem, der sidder på pengene, kan forstå. Med et designsystem behøver I kun opfinde den dybe tallerken én gang - og så genbruge, forfine og forbedre. I sparer en masse tid og penge, når I ikke designer og udvikler komponenter, som allerede findes i næsten samme afskygning et andet sted i jeres digitale eksistens.

3. Designsystemer udrydder konteksten. Og i design- og udviklingsarbejdet er det en vigtig forudsætning for netop genbrugelighed (det var det argument, vi havde i punkt nummer 2). Med et designsystem udvikler du komponenter i isolation - det vil sige, at du ikke blindt udvikler til én specifik side eller ét specifik brugsscenarium, som gør din komponent ubrugelig i alle andre sammenhænge. Byg i stedet noget der virker på tværs - med det samme.

4. Designsystemer sikrer ensartethed. Når hele teamet arbejder med designsystemer, bliver kundeoplevelsen i sidste ende meget mere ensartet, fordi I bruger de samme elementer igen og igen. Og tillad mig at bruge denne lejlighed til at mane idéen om, at ensartetheden kommer på bekostning af kreativiteten, til jorden. Designsystemerne forhindrer dig ikke i at skabe innovative løsninger. De opfordrer dig til at dokumentere din kreative proces, så de andre i dit team også kan få gavn af dine ideer.

5. Designsystemer giver en gnidningsfri onboarding. Hele teamet vælter sig i overblik og er hamrende effektive. Men så kommer der en ny kollega (åh-åh). Men bare rolig, krisen er afblæst: Jeres nye kollega kan finde al den dokumentation, han eller hun har brug for, i designsystemet.

6. Designsystemer skaber fokus for udviklerne. Når I bruger et dedikeret designsystem-tool, er udviklerne ikke afhængige af databaser, VPN og testmiljøer. De kan fokusere udelukkende på at udvikle selve frontend-komponenterne uden at skele til de mange variabler, som er i spil på diverse udviklingsmiljøer, og som har indflydelse på visningen af komponenterne.

7. Designsystemer forbedrer kommunikationen. I kan lynhurtigt misforstå hinanden, når hver faggruppe taler deres helt eget indforståede sprog. Hedder “tingen” en slider, en carousel, en swiper eller en product rotator? Præcis. Her er designsystemer uundværlige: Slut med misforståelser. Alt er jo defineret i systemet, så alle taler det samme sprog.

Kom i gang

Hvis du er klar til at skrue helt op for effektiviteten, den gode kommunikation, det skærpede fokus og den konsistente brugeroplevelse (svært at sige nej til, ikke?), så har vi samlet et par af vores egne kom i gang-favoritter her:

En håndbog, som giver dig en god indføring i designsystemer og en anden bog, der også kommer godt omkring alle aspekter og udfordringer, når du arbejder med designsystemer.

Og så er der nogle af vores foretrukne værktøjer:

  • Et værktøj til at præsentere komponenter og selve designsystemet (find det her). 
  • Et starterkit med forskellige lækre features, blandt andet Fractal, som er et godt sted at starte (find det her). 
  • Med Stencil kan du lave web components der virker cross-browser og i forskellige JavaScript framework-kontekster (find det her).