Ett designsystem är ett komponentbibliotek på systemnivå — designtokens, UI-komponenter, mönster och dokumentation som skalar över flera produkter eller varumärken. B3 etablerar och förvaltar det. Resultatet är konsekvent UX, snabbare time-to-market och inbyggd tillgänglighet i varje applikation som konsumerar systemet.

Vad ingår

Designtokens (färg, typografi, spacing, motion) versionerade och plattformsoberoende
Komponentbibliotek i Figma med fulla varianter och states
Kodat komponentbibliotek (React, Vue, Angular eller webbkomponenter) som matchar Figma 1:1
Dokumentation i Storybook eller Zeroheight med användningsregler, do/don’t och tillgänglighetsanvisningar
Tillgänglighet enligt WCAG 2.2 AA inbyggd i varje komponent
Versionshantering enligt SemVer med changelog och migrationsguider
Bidragsmodell och governance — RFC-process för nya komponenter
Tema-system för flera varumärken (white labelling)
Automatiska tester — axe-core för tillgänglighet, visuella regressionstester via Chromatic

Vad det INTE är

Produktdesign på enskild lösning — se B2
Tillgänglighetsaudit av befintligt system — se B4
Frontend-implementation av enskild applikation — se C1
Innehållsproduktion — se B5
Designtokens som såld plattformstjänst (SaaS)
Varumärkesarbete på koncernnivå

För vem

Design Director, CTO och Head of Product i organisationer med flera produkter, varumärken eller team som ska dela ett designspråk. Också plattformsteam som vill säkra konsekvens utan att flaskahalsa enskilda produktteam.

Så går det till

Discovery och strategi (2–4 v) — kartläggning av existerande UI-arvet, varumärkesriktlinjer och konsumerande team. Komponentstrategi och ägarmodell.
Tokens och kärnkomponenter — färg, typografi, spacing, grundkomponenter (knappar, formulär, navigation, kort, tabeller). Figma och kod parallellt.
Dokumentation och pilotteam — Storybook eller Zeroheight som dokumentationsyta. Pilotteam konsumerar v1 och ger feedback.
Release v1 och adoption — npm-paket, changelog, migrationsguide. Aktiv supportkanal mot konsumerande team.
Förvaltning — versionerade releases, RFC-process för nya komponenter, kvartalsvis tillgänglighetsrevision. Övergår till D1 eller löpande konsultinsats hos er.

Bevis

Länsförsäkringar — Digitalist driver vidareutveckling och förvaltning av LFDS (Länsförsäkringars designsystem) med ett team seniora konsulter. Systemet används över flera applikationer och varumärken inom koncernen. Se /kundcase/lansforsakringar.
AFRY — multisajt med 16 språk på 12 marknader bygger på gemensamt komponentbibliotek. Se /kundcase/afry.

De vanligaste frågorna

När är det dags för ett designsystem? När ni har minst tre produkter eller varumärken som divergerar designmässigt, eller när nya produktteam ständigt återuppfinner samma komponenter. Ett designsystem är en tvärgående investering — den betalar tillbaka sig först när flera team konsumerar det.

Vad är skillnaden mellan B2 och B3? B2 designar för en specifik produkt — en webbplats, en app, en e-tjänst. B3 etablerar systemet som flera produkter konsumerar. Många av våra kunder börjar med B2 på enskild lösning och låter komponenterna generaliseras till B3 när skalan motiverar det.

Hur säkrar ni att Figma och kod inte divergerar? Strikt 1:1-mappning på namngivning, props och states. Designtokens som single source. Automatiska tester på kod, granskningsrutin per release. Designkvalitetsråd granskar varje release innan publicering.

Kan vi ta över förvaltningen själva? Ja, det är målet. Dokumentation, bidragsmodell och governance levereras så att ni driver vidare själva. Många kunder behåller dock en konsultinsats — ett par seniora utvecklare i kundens designsystem-team — för stabilitet.

Relaterat

Erbjudande: Den nya digitala närvaron
Tjänst: B2 UX och visuell design
Tjänst: B4 Tillgänglighet
Tjänst: D1 Förvaltning och vidareutveckling
Kunskap: Designsystem i praktiken