From Figma to AI-driven product design

Background

PIHR is a Swedish HR tech company that helps employers find and fix unjustified pay gaps. The area is changing fast right now. The EU Pay Transparency Directive means more companies need to work with their pay data in a structured way, more often, and with stricter requirements for traceability.

The existing product was built for a simpler way of working. You uploaded a file of pay data, the system did the calculations, and you got an analysis back. It worked, but it reflected a world where a pay equity audit was something you did once a year.

The current PIHR app with an uploaded file and a choice of legislation and markets — The current app. Everything starts with a file upload, and the work is split by legislation.

The current PIHR app with an EU analysis, a map and the gender pay gap — The analysis view in the current app. You pick a market on a map and get the pay gap for that selection.

When we joined in November 2025, PIHR had decided to build the next version of the product. The goal was a system where customers work with their pay data continuously, explain gaps, decide on actions and can show what was done and why.

What we were responsible for

We act as the product design team, responsible for UX and UI in the new product. In practice that means three connected things: the design of the product itself, the design system it is built from, and the way design and development work together.

We work as part of the product team, reporting directly to the product owner, and spend a few days a month on site in Stockholm.

How we did it

We started as usual

For the first few weeks we worked the way we always have. We got to know the domain, mapped the existing system and drew flows and screens in Figma.

That was the right way to start. We needed to understand a complex area before we could have opinions about it. But we soon saw where the friction was. We drew screens that looked finished, the developers built something that resembled them, and the differences only surfaced once the code was in place.

We left Figma

Over the course of the engagement we moved all of our design work to Claude Code. Today we have left Figma completely.

The reason was not that Figma is bad. The reason was that the design could live in the same place as the product. When we design directly in code we get real components, real data, real empty states and real error messages. A prototype you can click through in the browser says more in five minutes than a polished Figma file does in an hour.

It took time to get there, and we did it step by step. First prototypes in code alongside Figma. Then the design system in code. In the end there was nothing left in Figma worth maintaining.

A design system built in code

Alongside this, we built the product’s design system with AI. It consists of design tokens for color, typography, surfaces and radii, a layer of component primitives, and composite components built from them.

Two things held it together. The first was a clear rule for what belongs in the design system: would you take this component to a completely different product to recreate our look? If so, it belongs there. If it names something specific to our domain or contains its own logic, it is ordinary product code.

The second was that the design system is documented for both people and AI agents. The rules live in the repo, next to the code. That means an agent building a new view uses the right tokens and the right components from the start, instead of inventing its own colors.

The system supports several themes as well as light and dark mode, and there is a built-in page in the app where you can browse the whole design system.

The design system start page in the app, with core principles and contents — The design system lives in the app. Core principles first, then color, typography and components.

The documentation page for the Badge component, with variants in context — Every component has its own page with an explanation, variants in context and deviations from shadcn.

The Theme Customizer panel with token groups for the base theme and product-specific extensions

Themes tested in the product

To try out new looks quickly, we built a Theme Customizer right into the prototype. You pick a theme and adjust the colors token by token, and the whole app updates as you go.

The tokens come in two layers. The base follows shadcn, with layout, semantic colors, borders, sidebar and charts. On top sit the product’s own extensions, such as status colors, phases and categorical colors for charts.

A theme that works can be saved and exported. So we can test a new color scheme in the real product in a few minutes, instead of mocking it up in a separate file.

Our own prototype branch in the product

We work in our own prototype branch in the product’s codebase. That means we can build an idea in the real application, with the real design system, without touching what goes to production.

When an idea is worth showing, we publish it to a shared prototype site the whole team can reach. The discussion is then no longer about a picture of a solution. It is about the solution itself.

We don’t focus on what happens to the code afterwards. That is not what the prototype is for. The developers need to rebuild some of it from scratch, and some of it they can use as is. They decide that for themselves, based on what is actually needed. The prototype answers how it should look and behave, not how it should be built.

The Prototype Control Center with switches for uploaded files and error codes

A control center for every state

A prototype running on mock data usually only shows the case where everything goes right. The difficult states, such as a file with no market, columns that could not be mapped or an upload that fails, rarely show up on their own.

So we built a Prototype Control Center. It is a panel of switches that controls what happens next in the prototype. Want to see how the app behaves when the next file is password protected? Flip a switch and upload.

The errors use the same codes as the backend. The conversation with the developers can then start from exactly the case that needs handling, and every state can be shown for real instead of described in an issue.

From prototype to issues

From the prototype work we write issues directly for the developers. We use a way of working where a raw idea is first grilled, that is, stress-tested with sharp questions until it holds, before it becomes a specification and then concrete development tasks.

Grilling is the step that has paid off the most. It forces decisions that would otherwise have come up in the middle of an implementation, and it means that what we hand over can actually be built.

From file upload to a system to work in

The product journey has run alongside the change in how we work. From an application where you uploaded a file and got an analysis, to a system where pay data, analyses, explanations and decisions are connected over time.

A large part of the work has been about language. What is actually the difference between an upload and the data it describes? When does a piece of work become official? What should the user see, and what is internal terminology? We have helped establish the shared vocabulary, and it now lives in the repo as a shared domain model that both the team and the AI agents work from.

PIHR plans to launch the new product in early 2027. Until then we show it blurred, but you can make out the structure: an overview of all audits, and for each audit a summary that guides the user through the work step by step.

Blurred view of the status overview in the new PIHR app — The status overview in the new app. All audits and how far along they are, in one place.

Blurred view of the summary for an audit in the new PIHR app — The summary for an audit. Three steps from raw data to finished reports, and an overview of the workforce.

Results

A design system in code with tokens, components, themes and dark mode support, documented for both people and agents
Design work that has left Figma entirely and happens directly in the product
Clickable prototypes in the real application, published to a shared prototype site for the team
A way of working where design delivers grilled, well-considered issues straight to the developers
A shared domain model so that design, development and AI agents use the same words

What we learned

Designing in code only pays off once the design system exists. Without tokens and components, the prototypes are just prettier sketches.
AI removes the barrier to building, not the barrier to knowing what to build. The hard part is still understanding the domain and asking the right questions.
Write the rules down where the code lives. An agent won’t follow a design system that only exists in the designer’s head.
Throwaway prototypes are a strength, but only if everyone agrees they are throwaway. Mix them up with production code and you lose both.
Leaving Figma is not a decision you make all at once. It is what happens once everything else works better somewhere else.