For to til tre år siden begynte vi å bygge et designsystem fra bunnen av for en av våre langsiktige kunder – et system som skal redusere design-inkonsistenser, skalere på tvers av flere produkter og redusere gapet mellom design og utvikling. Vi har sett med egne øyne hvor mye raskere prosjekter beveger seg når det finnes et ordentlig designsystem på plass.
Vi startet med å bygge fundamentet – lage spacing-skalaer, tilpassede primitiver, typografi, semantikk og et sett med skreddersydde komponenter. Det var en god start, men det ble raskt klart at prosjektet ville kreve kontinuerlig vedlikehold og ta mye mer tid enn vi ønsket å bruke på det. Så vi måtte revidere prosessen vår.
I år bestemte vi oss for å prøve en annen tilnærming og kjøpte et modent, ferdiglaget komponentsett. Det kom med et fullt komponentbibliotek, innebygd tilgjengelighet, et token-system og et Figma UI Kit vi kunne bruke for å gjøre livet enklere for både design og utvikling.
Det virket som det beste fra begge verdener – helt til vi begynte å revidere det nærmere.
What Didn’t Work
For utvikling så det ganske enkelt ut å bruke og vedlikeholde, men designteamet slet med å tilpasse UI-kitet for å møte våre behov og gjenspeile kundens uttrykk og visuelle identitet. Token-systemet ble spesielt et smertepunkt.
Vi kjempet med grunnlaget:
- Uoverensstemmende token-navnekonvensjon og mangel på god semantisk struktur
- Ingen enkel måte å legge til ekstra token-sett
- Tilpasningsrisiko – oppdateringer kunne lett ødelegge våre overstyringer
- Ingen innebygd støtte for flere merkevarer og temaer
Vi hadde muligheten til å tilpasse oss og inngå kompromisser, kanskje droppe eller justere deler av merkevaren for å passe systemet, men å levere noe som var “nesten on-brand” føltes ikke som riktig tilnærming.
Different approach: custom tokens, pre-built components
I stedet for å gå tilbake til en helt tilpasset løsning, bestemte vi oss for å dele det i to.
Vi beholder de ferdigbygde komponentene – de var solide og tilgjengelige – og erstatter token-laget med vårt eget. Det betydde å bygge token-systemet vårt på nytt og remappe det til komponentene.
Vi fokuserte på:
- Skreddersydde primitive farger
- Semantiske tokens
- Klar og konsistent navngivning
- En lettforståelig token-struktur som kan skalere i fremtiden
Vi tror denne hybride tilnærmingen vil gi oss fleksibiliteten vi trenger for å levere et system som både er skalerbart og virkelig “on-brand” – uten å gi avkall på alle fordelene med et modent komponentbibliotek.
Det er fortsatt mye arbeid igjen, og vi er ikke ferdige ennå. Men når vi har rullet det fullt ut, kan vi dele en oppfølging med resultatene – hva som fungerte, hva vi ville endret, og hvilken innvirkning det hadde på skalerbarhet, teamets tempo, konsistens på tvers av produktene og viktigst av alt, hvor mye vedlikeholdstid vi har spart.
Hvis du er midt i å finne ut av designarbeidsflyter eller bare prøver å få teamet ditt til å jobbe smidigere, kan det være lurt å sjekke hvordan man onboarder en designer effektivt i et produktteam, forskjellen mellom mentoring og coaching i designteam, eller hva en UX-audit er og når det er verdt å gjennomføre en. Det kan være nyttige ting der, avhengig av hva du jobber med.
