GetAccept

I joined GetAccept in August 2025 to lead a product design team of six. The team was skilled and worked the way most product design teams still do: explore in Figma, hand over to engineering, answer questions, review what came back.

Around us, R&D was changing faster than almost anywhere I have seen. Our R&D organisation has been exceptionally quick to adopt AI practices. Product managers own the problem, not the solution. Engineers run many agents in parallel, and at that pace a manual design process could no longer keep up.

If engineering can build a feature in days, a design process measured in weeks becomes the bottleneck. Nobody is at fault, but the result is the same: teams either wait for design or ship without it. Neither was acceptable to me.

There was a second side to it. Engineers were encouraged to act autonomously and ship against the backlog. With the number of designers we have, we simply cannot be in every room. So the real question was not how to make designers faster. It was how to keep design quality under control when design is not present.

Looking closer, the slowness was not only in designers working at a manual pace. It was also in the translation. A design lived in Figma, the product lived in code, and every handover meant describing one in the language of the other. Specs, redlines, comments, and then a review of how close the build came.

Many teams are still asking how to make Figma and code talk to each other better. We asked a different question: what is Figma still doing for us that the code cannot?

The honest answer was less and less. Our design system already existed in code, as the components our product is built from. A Figma copy of it would only be a second asset to maintain and keep in sync, and it would always be a step behind. So we made a clear call: the coded design system is the source of truth, and we will not continue building and maintaining a mirror of it in Figma.

Figma served our industry exceptionally well for many years, and I have loved working in it. But it was late to AI, and for a long time Figma Make didn't produce anything of quality, which is what made us look at other AI-driven design tools. For us, putting pixels on a canvas is no longer a realistic way of working. The craft has moved, and so have we.

The new tools exposed a second problem. Every tool we tried expected us to rebuild our world inside it: a facsimile of the design system, and the views and assets we already had, recreated once more. We were paying twice – in time, in tokens and in things to keep in sync. It was pointless reproduction, because we already had the source of truth. It was in Git.

Once the call was made, the rest followed. If the source of truth is code, designing in code is designing in the real material. The product design team no longer has Figma licences beyond FigJam, which we keep for retros.

This was not a cost-cutting exercise. It was a decision about where design should happen, and the answer was: in the same place as the product.

Leaving Figma only works if designers have something better to go to. So I built our design process into Claude Code as a plugin: ga-designer, an agentic tool that works in our codebase, with our design system, following the way we design.

Where it started. I had been thinking about how UX design is an umbrella role for a number of skills, some of which are job titles in their own right, like UX copywriter or UX researcher. Around the same time, we started connecting our data sources in Claude Cowork. That led me to the idea of building a skill for each of those roles, and pulling from our data sources for automated research. That research never replaces understanding our users and speaking to them.

From personas to roles. The first version was a cast of named designers with their own voices, led by a design director called Bengt. It was fun, and it taught us a lot, but personality got in the way of the work. The rewrite replaced the cast with functional roles: one that routes the work, one that researches, one that builds, and a panel of reviewers. The lesson: don't humanise the tool. A named persona with opinions carries authority it hasn't earned, and it risks steering the designer instead of supporting their judgement. Today ga-designer has 25 focused skills, covering the process, design craft, review, visual verification, communication and improving the tool itself.

The Double Diamond, with gates. The process follows the diamond we already used, with four decision points where a human designer approves before anything moves on: the plan, the problem, the direction and the release.

Reviewers that cannot overrule. Before anything is released, five reviewers check the work in parallel: accessibility, usability heuristics, AI experience, design system adherence and overall quality. They report findings, but they don't edit the work and can't block it. Judgement stays with the designer.

Real material, real data. The builder works with the real components from our design system, and can read real product data without changing it. Research draws on every data source we have connected, such as Linear, Airspeed (formerly Glyphic), Intercom and our user analytics, as well as the knowledge in our own product. That way, work starts from what customers actually say and do, instead of from a blank page.

Written rules slip, gates hold. The most important lesson came from shipping it. Across many versions, every rule written as an instruction eventually slipped. The only rules that held were the ones enforced by the system itself. So the non-negotiables – design system use, accessibility floors, never touching real data – became hard checks, not guidelines. Reviewers advise, hard checks enforce, and the designer decides.

A lot of UX and UI isn't opinion. It's pattern and law: Fitts's and Hick's laws, Gestalt principles, Nielsen's heuristics, WCAG 2.2 and the European Accessibility Act. Good designers carry this in their heads. ga-designer carries it in its skills, so every piece of work starts from established practice instead of whatever the model happens to produce.

General design knowledge isn't enough, though. To design well for GetAccept, the tool also needs to know how we design. So we extended our coded design system with guidance that agents can read alongside the components.

Pattern definitions describe how each component should be used. Not only what a button looks like, but when to use which button, and how several buttons work together in one view.

House rules capture what we consider good design for our product: when to use a side sheet instead of a modal, or when changes save automatically and when the user saves explicitly. These are the decisions an experienced designer on the team makes without thinking. Writing them down makes that expertise available when no designer is in the room. It also makes for better conversations, because our conventions are already built into every proposed solution.

Together, they're our main defence against AI slop – the generic, plausible-looking design that AI tools produce by default. Laws and patterns keep the work correct. House rules make it ours.

For a long time, ga-designer judged its work from the code, and from the code everything looked fine.

Once it could open the running product in a real browser, through Playwright or Claude's built-in browser, it could look at what it had built. It started catching broken layouts, wrong states and other problems that were correct in code and wrong on screen. It also captures screenshots across empty, sparse and data-heavy states, so seeing the result in context is part of checking the work.

Seeing its own work also lets ga-designer fix itself. It produces a result, inspects and judges it, then fixes whatever didn't pass, without anyone having to point out baseline errors. That saves us time and keeps our attention on the work that actually needs a designer.

Figma Make and Claude Design have this built in. For us, it was the lever that let us truly work in Claude Code and our real codebase, and brought us back to one tool for the entire design process.

From the start, I pushed the designers to treat prototyping as a core part of the process. Design is communication, and a prototype communicates far more clearly than we can face to face. When we describe an idea in a meeting, we can only hope we all leave with the same picture in mind. With a prototype, everyone reacts to the same thing.

Our teams can now have a meeting and, an hour later, have three different directions to react to. Each one is "finished" design: foundational UX laws, copywriting and design system usage are in place, and our house rules enforce our patterns and our taste. What the designer still brings is the ability to tell what only looks good on the surface, as AI design often does, from what actually is good.

Owning the tool means we decide what it can do, not a vendor's roadmap. When something is missing, I build it. The prototype switcher and the canvas started that way: leaving Figma meant losing its open canvas, so I built one that works with our real prototypes.

Another example is feedback. A user or a designer records a video walking through a solution and thinking aloud. ga-designer breaks it down into Linear issues we can fix, so spoken feedback turns into a backlog automatically.

The tool itself improves the same way. Designers and engineers file requests and bug reports through ga-designer itself, which creates a Linear ticket for me to act on. That gives us a platform that grows with us, is tailored entirely to our needs, and can be extended in a matter of minutes.

ga-designer is not only for designers. It is GetAccept's official design tool, and engineers and product managers use it too.

An engineer picking up a backlog item can now produce a design that is at a completely new level of good enough. Most of the time it only needs minimal fixes from a designer. Product managers use it to show their ideas and intentions instead of describing them, which makes every conversation with design and engineering sharper.

This changed what my team's work is worth. Every improvement to the tool reaches everyone in R&D who designs with it. Design expertise is no longer limited by how many rooms designers can be in. It is built into the tool everyone uses, and that is what removes design as a bottleneck.

We'll keep building and extending ga-designer. It builds on the models underneath it, so as they become more powerful and capable, so does our tool.