codexier.

Design och UX

Vad kostar ett designsystem?

Av CodexierPublicerad 4 min läsning

Ett designsystem är den gemensamma uppsättningen färger, typografi, avstånd, komponenter och regler som låter flera personer bygga skärmar som ser ut och beter sig likadant. Kostnaden beror på tre val: hur stor del av gränssnittet det täcker, om det bara finns i ett designverktyg eller även som kod, och hur mycket dokumentation och förvaltning ni vill ha runt det. Den här guiden prissätter varje nivå, förklarar den löpande kostnaden offerter brukar utelämna och visar när ett mindre UI-kit är det bättre köpet.

Nivåer av omfattning och vad de innehåller

NivåVad som ingårPassar
GrunderFärg, typskala, avstånd, rutnät, ikoner, tokensEn varumärkesuppdatering eller en enskild liten produkt
UI-kitGrunder plus baskomponenter i Figma med varianter och tillståndEtt produktteam på två till fem personer
Kodat bibliotekKitet implementerat i React, Vue eller webbkomponenter med testerTeam som levererar funktioner varje vecka, flera produkter
Förvaltat systemBibliotek plus dokumentationssajt, bidragsregler, versionshanteringFlera team eller en extern byrå som bygger tillsammans med er

Bara design eller design plus kod

Ett system enbart i Figma gör designers konsekventa men lämnar utvecklarna att tolka varje komponent, och det är där glidningen börjar. Ett kodat bibliotek betyder att knappen i Figma och knappen i produkten är samma objekt, och att en ändring i tokenfilen uppdaterar båda. Prisskillnaden speglar riktigt arbete: varje komponent behöver tillgänglig kod, tangentbordsbeteende, responsiva regler och tester. Är produkten byggd i ett ramverk som React ersätter det kodade biblioteket dessutom mycket ad hoc-styling, så en del av kostnaden hämtas hem i de första funktionerna som byggs med det. Vår tjänst för designsystem och UI-kit täcker Figma-nivån, med kod som tillägg.

Dokumentation och förvaltning

Skillnaden mellan ett system och en mapp med komponenter är att folk vet hur de ska använda det och hur det ändras. Dokumentationen säger när varje komponent ska användas och vad man inte ska göra; förvaltningen säger vem som beslutar om tillägg och hur versioner släpps. Båda är billiga att skriva i början och dyra att rekonstruera senare. För ett litet företag kan förvaltningen vara en sida: en namngiven ägare, en månatlig genomgång och en regel att nya mönster läggs in i systemet innan de skeppas i en produkt.

  • Användningsguide per komponent: syfte, gör och gör inte, tillgänglighetsnoteringar.
  • En namngiven ägare med mandat att säga nej till engångsvarianter.
  • En ändringsprocess: förslag, granskning, versionsnotering, versionsnummer.
  • En plats där allt finns som både designers och utvecklare faktiskt öppnar.

Löpande underhållskostnad

Offerter beskriver bygget; budgetar behöver underhållet. Komponenter behöver rättas när en webbläsare eller designverktyget ändras, nya mönster dyker upp när produkten växer, och tillgänglighetskraven skärps. Planera för en återkommande andel av en designers och en utvecklares tid, och för en liten genomgång varje kvartal. Kostnaden för att inte underhålla är subtilare: team börjar kopiera och ändra komponenter lokalt, systemet halkar efter produkten och inom ett år är konsekvensen det köpte borta. En underhållsrad i budgeten är det som skyddar den ursprungliga investeringen.

Återbetalning genom snabbare byggen

Avkastningen mäts i funktionerna som byggs efter att systemet finns. En ny skärm sammansatt av testade komponenter tar en bråkdel av tiden mot en som designas och kodas från grunden, och den blir konsekvent och tillgänglig som standard. Att ta emot en ny designer eller utvecklare blir en rundtur i systemet i stället för en studie av gamla skärmar. Uppskatta återbetalningen ärligt: räkna gränssnittsarbetet teamet gör på ett kvartal och fråga hur mycket av det som är att bygga om sådant som redan finns någon annanstans i produkten. Är svaret mycket betalar systemet sig inom några kvartal; aktuella priser finns på vår prissida.

När ni inte behöver det här: en enskild marknadssajt, en produkt med en skärmtyp eller ett team på en person behöver inget designsystem; en prydlig stilguide och en komponentsida i ert ramverk räcker. Ska produkten snart designas om, bygg systemet som en del av omdesignen i stället för före den. Är ni osäkra på vilken nivå som passar, boka ett kort samtal och visa oss några skärmar.

Vanliga frågor

Kan vi bygga designsystemet själva?

Ja, om en designer och en utvecklare kan lägga konsekvent tid på det under ett par månader. De flesta interna försök stannar av eftersom det inte är någons huvuduppgift. Att köpa grunden och underhålla den internt är en vanlig medelväg.

Vilket verktyg ska systemet ligga i?

Figma är standard på designsidan, och det exporterar tokens som ett kodat bibliotek kan använda. På kodsidan, använd ramverket produkten redan är byggd i; ett bibliotek i ett annat ramverk kommer inte att användas.

Hur lång tid tar det att bygga?

Grunder och kit för en liten produkt tar några veckor. Ett kodat bibliotek med dokumentation tar ett par månader, beroende på hur många komponenter ni faktiskt använder. Att räkna befintliga skärmar är första steget i avgränsningen.

Osäker på om ni behöver ett kit eller ett helt system?

En kvart med en designer: visa oss några skärmar och berätta vilka som bygger gränssnittsarbete. Vi säger vilken nivå som passar, vad den skulle kosta och om ni bör vänta.

Boka ett kostnadsfritt 15-minuterssamtal