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.

Engineers were encouraged to act autonomously and ship against the backlog. With the number of designers we have, we simply cannot be part of every decision. 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.

Speed was part of it. If engineering can build a feature in days, a design process measured in weeks becomes the bottleneck, and teams either wait for design or ship without it. Neither was acceptable to me.

The rest was translation. A design lived in one place, the product in another, 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. Every step cost the designer time, and something was always lost along the way.

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.

25 focused skills. Today ga-designer covers the process, design craft, research, review, visual verification, communication and improving the tool itself. It lives in Claude Code, inside our codebase, and works with our real product and our coded design system.

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.

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.

Written rules slip, gates hold. 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.

Giving the tool eyes. 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 started catching broken layouts, wrong states and other problems that were correct in code and wrong on screen. Now it produces a result, inspects it, and fixes whatever didn't pass, without anyone having to point out baseline errors. That was the turning point that let us do the entire design process in one place.

Every piece of work starts with research, and ga-designer does the legwork. It pulls from every data source we have connected: Linear, Intercom, Airspeed (formerly Glyphic), our user analytics, and our own product, down to its code and data.

That gives the designer both kinds of research at once. The quantitative side comes from analytics and product data: how many customers use something, and how. The qualitative side comes from what customers actually say, on calls through Airspeed and in conversations with support. Every finding says how we know it, so it can be checked.

In the report below, discovery for a renewals feature found that the dashboard's "Expiring soon" widget tracks signing deadlines, not contract renewals, so the dashboard had no renewal view at all. Renewals did surface one module away, but with no value, no owner and no next step, and a request from July asked exactly that question: you can see a renewal is coming, "but then what?"

Gathering that used to be the designer's job. Now it's done before they start, and their time goes to judging the evidence instead of collecting it. The findings also feed the agent: every direction ga-designer builds afterwards starts from what customers said and did, not from what a model would guess. That research never replaces understanding our users and speaking to them.

Prototypes are the most visible thing ga-designer produces, and they matter. 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 built with research, in our real product, with our design system and real data, and with foundational UX laws, copywriting and our house rules already in place. 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.

To make those directions easy to judge, I built two tools. The prototype switcher lets the designer click around in each prototype, switching between versions and directions and testing different states and amounts of data, such as long names. The canvas lays out every version and its flows on one page, for an easier overview and comparison. From there, we pick the parts that work in each version and combine them into new ones.

Handover used to be a discipline of its own: specs, redlines, annotated frames, answering questions, then reviewing how close the build came. It took real effort from the designer, and it was where intent got lost.

With ga-designer, that work has almost disappeared. Every gate produces an HTML artefact for the designer and the team to read, and it's saved to Linear automatically, for tracking and posterity. The tool writes the reports and specs engineers follow, without the designer having to think about it.

Most often, the frontend is already taken care of too. ga-designer builds with the same design system and the same skills a frontend developer would use, in the same codebase. What engineers receive isn't a picture to interpret. It's working code in our product.

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.

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. Every design tool we tried, Figma included, expected us to rebuild that world inside it: a facsimile of the design system, and the views and assets we already had. We were paying twice – in time, in tokens and in things to keep in sync – for something we already had. The source of truth was in Git.

So we made a clear call: the coded design system is the source of truth, and we won't keep building and maintaining a mirror of it in Figma. The product design team no longer has Figma licences beyond FigJam, which we keep for retros.

Figma served our industry exceptionally well for many years, and I have loved working in it. But this was not a cost-cutting exercise, or a swap of one design tool for another. It was a decision about where design should happen, and the answer was: in the same place as the product.

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.