Designsystem för Vattenfalls B2B-portaler

Ett projekt med målet att gå från spretiga gränssnitt till en samlad designstandard. Ett designsystem som skapar tydlighet, effektivitet och bättre användarupplevelser.

Roll

UX Designer / Designsystem Designer

Kund

Vattenfall B2B

Uppdrag

Att skapa ett grundläggande, tokenbaserat designsystem i Figma med tillhörande dokumentation.

Tidsram

Uppstart och förarbete under LIA + 5 veckor aug-sep 2025.

Problem & utmaningar

- Inkonsekvent design och användarupplevelse inom och mellan portalerna i Energy Site Suite.
- Många unika lösningar och låg kontroll över designen.
- Vattenfalls officiella designsystem är anpassat för webb och inte för komplexa portaler och går därför inte att använda

Resultat

Ett grundläggande tokenbaserat designsystem och UI kit med dokumentation i Figma som används idag.

1 - bakgrund:

Vattenfall B2B

Om Energy Site Suite

Vattenfalls B2B-portaler (med samlingsnamnet Energy Site Suite) är system som används av företagskunder, energibolag, industrikunder och interna handlare för att hantera elavtal, följa förbrukning, köpa och sälja el, göra prognoser och arbeta med hedge-strategier.

Dessa system har utvecklats av olika team utan ett gemensamt designsystem, vilket lett till att gränssnitten varierat i både utseende och funktion. Varje portal använde olika komponenter, färger och mönster. Detta skapade inkonsekvens i användarupplevelsen och gjorde design- och utvecklingsprocessen ineffektiv.

Som UX-designer fick jag uppdraget att ta fram grunden till ett enhetligt och skalbart designsystem. Målet var att skapa struktur, förenkla samarbetet mellan teamen och lägga en grund för framtida utveckling av portalerna.

Projektet startades under min LIA våren 2025 och förlängdes sedan under hösten 2025.

2 - resultat:

Resultat & leverabler

Tokenbaserat designsystem

Grundstruktur för designsystemet med variabler och styles för färger, spacing och typografi som skapar bättre kontroll och skalbarhet.

Delad dokumentation

Dokumentation för både utvecklare och designers samlat på ett ställe - övergripande och på komponentnivå.

UI kit

Grundläggande komponentbibliotek : ikoner, knappar, formulärelement och moduler som redan nu börjat användas.

Samarbete

Påbörjat samarbete mellan portalerna - en gemensam riktning, och ett första ramverk för hur fortsatt utveckling kan ske mer enhetligt.

3 - processen:

Audit, identidiering & prioritering

Kartläggning av nuläge

Projektet inleddes med en kartläggning av centrala komponenter för att identifiera var inkonsekvenserna var som störst. Genom att samla allt i en tydlig översikt kunde jag svart på vitt visa för team och stakeholders hur spretigt gränssnitten faktiskt var. Det blev ett effektivt sätt att skapa samsyn, förklara behovet av ett designsystem och prioritera vilka komponenter som behövde standardiseras först.

kartläggning av unika knappar och formulärelement - inkonsekvens hittades både inom och mellan portalerna

Workshops & beslutsfattande

Workshops

Med insikterna från kartläggningen faciliterade jag flera workshops tillsammans med designers och utvecklare. Målet var att skapa samsyn kring nuläget, tydliggöra behov och fatta gemensamma beslut för arbetet med designsystemet.

Beslut

Under workshoparna beslutade vi kring komponenter som var mest kritiska att standardisera först, baserat på deras frekvens av användning och påverkan på användarupplevelsen. Vi beslutade också om designprinciper och riktlinjer som skulle styra arbetet framåt.

Workshop med designers och utvecklare

Struktur för designsystemet

Struktur och dokumentation

En första struktur för UI-kitet har tagits fram där centrala komponenter, moduler och riktlinjer samlas på ett ställe. Syftet är att skapa en gemensam grund för designers och utvecklare, där allt från typografi och färger till knappar, formulär och moduler är dokumenterat, visuellt konsekvent och anpassat för tillgänglighet.

Genom att samla och visualisera tillgängliga komponenter blir det enklare att standardisera, återanvända och vidareutveckla gränssnittet på ett enhetligt sätt. Den gemensamma strukturen gör det tydligare hur exempelvis färger, states och interaktioner ska fungera och användas för att möta WCAG-krav.

Eftersom utvecklarna arbetar i olika kodbaser och språk fungerar Figma just nu som den gemensamma platsen där allt kan dokumenteras och delas, ett naturligt första steg innan designsystemet tas vidare till kod.

kartläggning av unika knappar och formulärelement - inkonsekvens hittades både inom och mellan portalerna

Komponentbygge

Alla komponenter är byggda för att vara flexibla för att kunna anpassas efter olika behov och scenarier enligt standardprinciper. Designen utgår från det officiella designsystemet men är anpassade för portalerna.

exempel på komponenter i UI kitet

Designtokens och komponenter

I arbetet med designsystemet upptäckte vi att variationer i färger, otydliga states och inkonsekventa komponenter ofta berodde på en bristande grundstruktur. Därför införde vi en token-baserad modell där färger, typografi och spacing definieras centralt och används konsekvent i hela biblioteket.

Det gav oss inte bara ett mer enhetligt uttryck, utan också bättre kontroll över hur färger och komponenter används, vilket i sin tur gjorde det enklare att säkerställa att tillgänglighetskrav, som exempelvis kontrastnivåer, möts. Genom att uppdateringar hanteras på token-nivå sprids de kontrollerat till alla komponenter, vilket förenklar underhåll och gör systemet både mer skalbart och mer robust över tid.

Visualisering av sambandet mellan färg-tokens, styles och hur de appliceras i olika error-komponenter.

Test & kvalitetsäkring

Arbetssätt för test och kvalitet i designsystemet

I arbetet med att bygga komponenter och tokens testade vi parallellt att systemet höll i praktiken i realistiska scenarier. Därför etablerade vi ett iterativt arbetssätt för test och kvalitetssäkring, där komponenter skapas, testas och justeras i flera cykler. Arbetet skedde med kontinuerlig synk kring benämningar, implementation och förbättringar - för att säkerställa att systemet fungerar både i design och kod, och i verkliga användningskontexter.

Test i kontext

Test i kontext

Testning i realistiska scenarier och användningskontexter

Samarbete dev + design

Samarbete dev + design

Synk kring benämningar, dokumentation och implementation

Iterativ förbättring

Iterativ förbättring

Justeringar baserat på feedback och testning i kontext

4 - summering:

"Målet är inte att bygga om allting, utan att ha en gemensam sanning att utgå ifrån när vi bygger nytt" - gemensam vägledande princip

Genom att etablera ett skalbart och levande designsystem skapade jag förutsättningar för ett långsiktigt och mer hållbart arbetssätt. Nu finns en gemensam designbas som kan utvecklas, förbättras och byggas vidare på över tid.

Insikter & lärdomar

Workshop som metod och verktyg

Det var utmanande att våga, men jag har verkligen sett hur effektiva workshops är för beslutsfattande. De ger strukturerade tillfällen för diskussion, lösningsutforskning, samsyn och engagemang. Jag använde mig av olika format: en halvdag på plats men också kortare, fokuserade möte, anpassat efter tid och problemets typ.

Kontinuerligt dela insikter

Genom att tidigt i processen göra och dela kartläggningen fick jag en djupare förståelse för problemen och kunde tydligt se var inkonsekvenserna var som störst. Jag insåg att jag tidigare antagit att alla redan hade en tydlig bild av nuläget, även om många upplevde portalerna som spretiga blev omfattningen först tydlig när den visualiserades svart på vitt. Att konkret visa inkonsekvenserna skapade både engagemang och en gemensam förståelse bland stakeholders och teamen, en känsla av att “nu tar vi tag i detta tillsammans".

Bygga in tillgänglighet från början

Genom att bland annat definiera färger på token-nivå och namnge dem efter användningsområde, inte utseende, säkerställer vi kontrastkrav från början och gör det enklare för teamet att använda rätt färger vid rätt tillfälle. Detta minskar risken för felanvändning och gör det lättare att upprätthålla tillgänglighetsstandarder över tid.

Mer tid och tajtare samarbete med utvecklarna

Jag hade regelbundna synkar med utvecklarna, men ett tätare och mer kontinuerligt samarbete från start hade gjort det enklare att hitta gemensamma beröringspunkter, fatta fler beslut tidigare, stärka kvaliteten och skapa en starkare gemensam grund.

fler projekt: