Från Figma till AI-driven produktdesign

Bakgrund

PIHR är ett svenskt HR-tech-bolag som hjälper arbetsgivare att hitta och åtgärda osakliga löneskillnader. Det är ett område som just nu förändras snabbt. EU:s lönetransparensdirektiv gör att fler bolag behöver arbeta strukturerat med sin lönedata, oftare och med högre krav på spårbarhet.

Den befintliga produkten var byggd för ett enklare arbetssätt. Du laddade upp en fil med lönedata, systemet räknade, och du fick ut en analys. Den fungerade, men den speglade en värld där lönekartläggning var något du gjorde en gång om året.

Den nuvarande PIHR-appen med en uppladdad fil och val av lagstiftning och marknader — Den nuvarande appen. Allt börjar med en filuppladdning, och arbetet är uppdelat per lagstiftning.

Den nuvarande PIHR-appen med EU-analys, karta och lönegap mellan kvinnor och män — Analysvyn i den nuvarande appen. Du väljer marknad på en karta och får ut lönegapet för urvalet.

När vi kom in i november 2025 hade PIHR bestämt sig för att bygga nästa version av produkten. Målet var ett system där kunderna arbetar löpande med sin lönedata, förklarar skillnader, beslutar om åtgärder och kan visa vad som gjorts och varför.

Vad vi ansvarade för

Vi går in som produktdesignteam med ansvar för UX och UI i den nya produkten. I praktiken betyder det tre saker som hänger ihop: designen av själva produkten, designsystemet den byggs av, och arbetssättet mellan design och utveckling.

Vi arbetar som en del av produktteamet, med direktrapportering till produktägaren, och sitter på plats i Stockholm några dagar i månaden.

Så gick vi tillväga

Vi började som vanligt

De första veckorna arbetade vi som vi alltid har gjort. Vi satte oss in i domänen, kartlade det befintliga systemet och ritade flöden och skärmar i Figma.

Det var rätt sätt att börja. Vi behövde förstå ett komplext område innan vi kunde ha åsikter om det. Men vi märkte ganska snabbt var friktionen låg. Vi ritade skärmar som såg färdiga ut, utvecklarna byggde något som liknade dem, och skillnaderna upptäcktes först när koden fanns på plats.

Vi lämnade Figma

Under uppdragets gång flyttade vi hela designarbetet till Claude Code. Idag har vi lämnat Figma helt.

Anledningen var inte att Figma är dåligt. Anledningen var att designen kunde bo på samma ställe som produkten. När vi designar direkt i koden får vi riktiga komponenter, riktig data, riktiga tomma lägen och riktiga felmeddelanden. En prototyp som går att klicka på i webbläsaren säger mer på fem minuter än en genomarbetad Figma-fil gör på en timme.

Det tog tid att ta sig dit, och vi gjorde det stegvis. Först prototyper i kod vid sidan av Figma. Sedan designsystemet i kod. Till slut fanns det inget kvar i Figma som var värt att underhålla.

Ett designsystem byggt i kod

Parallellt byggde vi upp produktens designsystem tillsammans med AI. Det består av designtokens för färg, typografi, ytor och radier, ett lager av komponentprimitiver, och komposita komponenter byggda av dem.

Två saker gjorde att det höll ihop. Det första var en tydlig regel för vad som får bo i designsystemet: skulle du ta med dig komponenten till en helt annan produkt för att återskapa vårt uttryck? Då hör den hemma där. Namnger den något i vår domän eller håller den egen logik, då är den vanlig produktkod.

Det andra var att designsystemet är dokumenterat för både människor och AI-agenter. Reglerna ligger i repot, bredvid koden. Det gör att en agent som bygger en ny vy använder rätt tokens och rätt komponenter från början, istället för att hitta på egna färger.

Systemet stödjer flera teman och både ljust och mörkt läge, och det finns en inbyggd sida i appen där hela designsystemet går att bläddra i.

Startsidan för designsystemet i appen med grundprinciper och innehåll — Designsystemet bor i appen. Först grundprinciperna, sedan färg, typografi och komponenter.

Dokumentationssidan för komponenten Badge med varianter i sitt sammanhang — Varje komponent har en egen sida med förklaring, varianter i sitt sammanhang och avvikelser från shadcn.

Theme Customizer-panelen med tokengrupper för bastema och produktspecifika tillägg

Teman som testas i produkten

För att snabbt kunna pröva nya uttryck byggde vi en Theme Customizer direkt i prototypen. Du väljer ett tema och justerar färgerna token för token, och hela appen uppdateras medan du gör det.

Tokens är uppdelade i två lager. Basen följer shadcn, med layout, semantiska färger, ramar, sidomeny och diagram. Ovanpå ligger produktens egna tillägg, som statusfärger, faser och kategoriska färger för diagram.

Ett tema som fungerar går att spara och exportera. Vi kan alltså testa en ny färgsättning i den riktiga produkten på några minuter, istället för att måla upp den i en separat fil.

En egen prototypgren i produkten

Vi arbetar i en egen prototypgren i produktens kodbas. Det betyder att vi kan bygga en idé i den riktiga applikationen, med det riktiga designsystemet, utan att röra det som går i produktion.

När en idé är värd att visa publicerar vi den till en delad prototypsajt som hela teamet kommer åt. Diskussionen handlar då inte längre om en bild av en lösning, utan om lösningen.

Vi lägger inget fokus på vad som händer med koden efteråt. Det är inte det prototypen är till för. En del av den behöver utvecklarna bygga om från grunden, en del går att använda rakt av. Det avgör de själva, utifrån vad som faktiskt behövs. Prototypen svarar på frågan hur det ska se ut och bete sig, inte hur det ska byggas.

Prototype Control Center med reglage för uppladdade filer och felkoder

Ett kontrollcenter för alla lägen

En prototyp med mockdata visar oftast bara fallet där allt går som det ska. De svåra lägena, som en fil utan marknad, kolumner som inte gått att mappa eller en uppladdning som misslyckas, dyker sällan upp av sig själva.

Därför byggde vi ett Prototype Control Center. Det är en panel med reglage som styr vad som händer härnäst i prototypen. Vill du se hur appen beter sig när nästa fil är lösenordsskyddad slår du bara om ett reglage och laddar upp.

Felen har samma koder som i backend. Samtalet med utvecklarna kan då utgå från exakt det fall som ska hanteras, och varje läge går att visa på riktigt istället för att beskrivas i en issue.

Från prototyp till issues

Ur prototyparbetet skapar vi issues direkt till utvecklarna. Vi använder ett arbetssätt där en rå idé först grillas, alltså stresstestas med skarpa frågor tills den håller, innan den blir en specifikation och sedan konkreta utvecklingsuppgifter.

Grillningen är det steg som gett mest. Den tvingar fram beslut som annars hade dykt upp mitt i en implementation, och den gör att det vi lämnar över faktiskt går att bygga.

Från filuppladdning till ett system att arbeta i

Produktresan går parallellt med arbetssättet. Från en applikation där du laddade upp en fil och fick en analys, till ett system där lönedata, analyser, förklaringar och beslut hänger ihop över tid.

En stor del av arbetet har handlat om språk. Vad är egentligen skillnaden mellan en uppladdning och det underlag den beskriver? När blir ett arbete officiellt? Vad ska användaren se, och vad är intern terminologi? Vi har varit med och satt den gemensamma vokabulären, och den ligger nu i repot som en delad domänmodell som både teamet och AI-agenterna utgår ifrån.

PIHR planerar att lansera den nya produkten i början av 2027. Fram till dess visar vi den suddig, men strukturen går att se: en översikt över alla kartläggningar, och för varje kartläggning en sammanfattning som leder användaren genom arbetet steg för steg.

Suddig vy av statusöversikten i den nya PIHR-appen — Statusöversikten i den nya appen. Alla kartläggningar och hur långt de har kommit, på ett ställe.

Suddig vy av sammanfattningen för en kartläggning i den nya PIHR-appen — Sammanfattningen för en kartläggning. Tre steg från rådata till färdiga rapporter, och en överblick över arbetsstyrkan.

Resultat

Ett designsystem i kod med tokens, komponenter, teman och stöd för mörkt läge, dokumenterat för både människor och agenter
Ett designarbete som helt lämnat Figma och sker direkt i produkten
Klickbara prototyper i den riktiga applikationen, publicerade på en delad prototypsajt för teamet
Ett arbetssätt där design levererar grillade och genomarbetade issues direkt till utvecklarna
En gemensam domänmodell som gör att design, utveckling och AI-agenter använder samma ord

Lärdomar

Att designa i kod betalar sig först när designsystemet finns. Utan tokens och komponenter blir prototyperna bara snyggare skisser.
AI tar bort tröskeln att bygga, inte tröskeln att veta vad som ska byggas. Den svåra delen är fortfarande att förstå domänen och ställa rätt frågor.
Skriv ner reglerna där koden bor. Ett designsystem som bara finns i huvudet på designern följs inte av en agent.
Slit-och-släng-prototyper är en styrka, men bara om alla är överens om att de är slit och släng. Blandas de ihop med produktionskod förlorar du båda delarna.
Att lämna Figma är inget beslut du fattar på en gång. Det blir följden av att allt annat blivit bättre någon annanstans.