Versioning – stabilitet i ett designsystem som förändras
Ett designsystem måste vara stabilt för att gå att lita på. Samtidigt måste det förändras för att förbli relevant. Det här är ingen paradox. Men i praktiken är det ofta här många designsystem börjar skava. För varje förändring som görs i systemet uppstår frågan: går det här fortfarande att använda utan risk? Och för varje försök att frysa systemet uppstår en annan: hänger det här fortfarande med verkligheten? Kärnfrågan är därför inte om ett designsystem ska förändras, utan hur ett system kan vara i ständig rörelse utan att upplevas som instabilt. I vårt arbete på Intunio, med designsystem som används av flera team och produkter över lång tid, är svaret ofta detsamma: versioning. Ett sätt att skapa stabilitet i ett system som fortsätter att förändras.
Tobias Rydenhag
Head of Design
När förändring blir opålitlig
De flesta team har upplevt det här i någon form.
En komponent uppdateras för att lösa ett problem i ett projekt. Förändringen är i sig rimlig. Men någon annanstans ändras beteendet oväntat. Layouten bryts. Ett tidigare fungerande flöde beter sig annorlunda.
Inget av detta behöver vara dramatiskt. Men upprepas det tillräckligt ofta händer något med relationen till systemet. Team börjar tveka. De dubbelkollar. De kopierar komponenter lokalt ”för säkerhets skull”. Systemet används fortfarande – men med försiktighet.
Det är ett tecken på att förändring saknar tydliga gränser.
Vad vi egentligen menar med versioning
När vi pratar om versioning menar vi inte bara versionsnummer eller releases.
Versioning är i grunden ett sätt att vara tydlig med tre saker:
- när något förändras
- vad som förändras
- vilka förväntningar som gäller efter förändringen
I designsystem-sammanhang är det ofta hjälpsamt att skilja mellan design system versioning och component versioning.
Design system versioning handlar om systemets helhet: vilka antaganden, mönster och grundprinciper som gäller vid en viss tidpunkt.
Component versioning handlar om förändring på komponentnivå: när en enskild komponent utvecklas, justeras eller ersätts.
Olika typer av förändring kräver olika grad av tydlighet.
Vad man faktiskt versionerar
En vanlig missuppfattning är att versioning främst handlar om visuella justeringar. I praktiken är det sällan där problemen uppstår.
Det som oftare kräver versioning är:
- förändrade beteenden
- justerade interaktionsmönster
- uppdaterade kontrakt mellan komponent och användare
Här blir begreppet breaking changes centralt. Med breaking changes menas förändringar som inte bara förfinar eller bygger vidare, utan som kräver att någon aktivt anpassar sitt arbete.
All förändring är inte av den typen. När den är det behöver den vara tydligt markerad, så att förändring kan ske utan att skapa osäkerhet.
Förändring i olika takt
I de flesta designsystem blir det snabbt tydligt att olika delar utvecklas i olika tempo. Vissa förändringar påverkar grundläggande antaganden, andra bygger vidare på befintlig funktionalitet, och vissa handlar om rena korrigeringar.
För att hantera detta används ofta begrepp som major, minor och patch versions. Inte som ett strikt regelverk, utan som en gemensam tankemodell för att förstå förändringens konsekvens.
- Major versions signalerar att något grundläggande har förändrats
- Minor versions innebär att funktionalitet byggts ut utan att bryta befintligt
- Patches handlar om korrigeringar och förfiningar
Ett förenklat exempel kan se ut så här:
- 2.0.0 – ett nytt beteende i en central komponent som kräver anpassning i befintliga flöden
- 2.1.0 – en ny variant eller egenskap som kan användas frivilligt
- 2.1.1 – en justering av spacing eller ett visuellt fel som rättas till
Exemplet är inte viktigt i sig. Det viktiga är att versionerna gör förändringens konsekvens tydlig redan innan den tas i bruk.
I praktiken handlar stabilitet därför om att ge team kontroll över när de uppdaterar, och vilken typ av förändring de tar in – inte om att hålla systemet stilla.
Versioning som praktiskt stöd i vardagen
När versioning fungerar förändras relationen till designsystemet. Förändring blir inte något diffust som “bara händer”, utan något som är förutsägbart, kommunicerbart och valbart.
I praktiken innebär det att team kan fortsätta arbeta tryggt på en etablerad version samtidigt som systemet utvecklas vidare. Stabilitet uppstår inte genom stillastående, utan genom förtroende för att förändring inte sker bakom ryggen på dem som använder systemet.
I de flesta större miljöer innebär detta också att flera versioner lever parallellt under perioder. Det är inte ett undantag, utan ett normalt tillstånd när produkter utvecklas i olika takt. Ett team kan ligga kvar på en stabil version medan ett annat testar nästa, utan att det gemensamma ramverket spricker.
Versioning blir då inte ett sätt att tvinga fram synkronisering, utan ett sätt att möjliggöra parallell utveckling utan att tappa helheten.
Stabilitet över tid
Ett designsystem blir aldrig färdigt.
Men det kan bli pålitligt.
Vår erfarenhet på Intunio är att frånvaron av versioning ofta leder till mer friktion, fler speciallösningar och mindre förtroende. Inte för att team gör fel, utan för att systemet saknar ett sätt att hantera förändring över tid.
Att arbeta med versioning handlar därför om att erkänna att förändring är en del av vardagen – och att ge team kontroll över när och hur den sker. Versioning är inte ett efterarbete, utan en del av hur ett designsystem hålls användbart när det fortsätter att utvecklas.
Inte genom att stå still.
Utan genom att röra sig på ett sätt som går att lita på.