How I design in the age of AI

The process most designers learned runs in a straight line: research, wireframes, high fidelity, handoff. Many of us have practised it for years. Each stage waits for the one before it, because a late change is expensive.

AI made late changes cheap. A working prototype can now exist before I would have finished the wireframes, so the line has become a loop, and I go around it many times before anything ships. The fundamentals stayed. Research still comes first, and a clear flow still beats a polished screen. The work in between is what changed.

Almost every step got faster. Review didn't, and I've stopped wanting it to.

Here is one lap of that loop, the way I run it now. I'll use one example the whole way through: a web app for fleet managers who track vehicle warranty claims. Most of the work happens with an AI agent. Which harness it runs in matters less than the habits around it. I use Claude on my own projects and GitHub Copilot at work, and the loop is the same in both.

I ask Claude to do the reading I would otherwise skip. I want a rough map of the problem before I make a single design decision.

I'm designing a web app for fleet managers who track vehicle warranty claims. The product goal is to get more claims filed before the warranty runs out.

1. What problems should I prioritise solving first, and why?
2. What type of user should I design for? What do they want, and what do they need?
3. Who are the main competitors? List the patterns they share.
4. Which of those patterns should we adopt, and which should we avoid? Explain each call.

When I leave the goal out, Claude picks one for me, and it tends to pick the most generic goal available. Every answer after that aims at the wrong target.

Don't trust the output yet. An AI is confident about everything, including the parts it made up. I keep a short list of claims to check before any of them shape the design. Some I can check against live products, and the rest need real users. I carry that list through every step below.

The claims about competitors I can check straight away. Claude's idea of a competitor comes from its training data, which can be out of date or wrong. So next I have Claude in Chrome open the real products in the browser and study the live screens.

I'm designing a web app for fleet managers who track vehicle warranty claims. Research the design patterns that strong products in this space use.

Open real examples of fleet management software, insurance claims portals, and B2B tools that track a case through several steps.

First, write a concise report that:
- Summarises recurring patterns from the strongest examples
- Points out where common patterns feel generic or wrong for fleet managers
- Recommends a page hierarchy, the key screens, and the status signals a manager needs to trust a claim
- Lists the specific design decisions you would make

Do not copy any single product or screen. Synthesise patterns across several references. Do not design anything yet.

Do not design anything yet keeps Claude in research mode, so I get a report to judge before anything is built.

• Patterns that show up in three or more strong products.
• A clear reason each pattern works for this audience.
• Anything the report calls generic. That is usually where a product is weakest.

By now I have a direction and a list of open questions. Most of those questions are about how something will feel to use, and no report can answer that.

Before AI, this was the wireframe step. Now I skip the grey boxes and build the key interactions in the real stack. A prototype in code answers questions a static frame cannot: how a state change feels, or how the layout holds at 390px.

This is also where Claude makes the most mistakes. An interaction that worked on paper breaks in the browser. Claude stops following the design system. On this portfolio, it kept reaching for raw hex colours and one-off font sizes when the tokens were right there. So I wrote the rules into a CLAUDE.md file and built a /styleguide page that renders every token. Claude reads both before it starts.

At work the design system lives in Figma, as it does at most large companies. AI tools work best from files they can read next to the code, so I carried ours over to Markdown and HTML. Copilot and Claude Code both pick it up from there.

The other risk is letting Claude start building too early. A few habits keep the prototype on track:

• Write the plan to a file before any code. Ask Claude for a plan.md that covers the product goal, the screens, the states, the data each one needs, and what is out of scope. Make changes in that file rather than in the chat. It becomes the brief that every later prompt points back to.
• Build the riskiest interaction first. Pick the one flow that could sink the idea, and leave the rest rough.
• Use realistic data early. Anonymised data with the same shape as production shows the hard cases that fake data hides, like a claim with forty line items or an API that takes six seconds to answer.
• Ask for one change per prompt, and check it before the next. A big prompt produces a big diff that is hard to judge.
• Make Claude test its own work. Ask it to run the app, drive it in a browser, screenshot desktop and mobile widths, and read the console. A build that compiles can still have a dead button.
• Keep the plan current. When a decision changes, update plan.md too, so a fresh session can pick up where the last one stopped.

A prototype can pass every one of those checks and still be wrong about people. AI gets close to how users behave, and it makes mistakes along the way. It can't predict what a real person will do. The only way I know to learn that is to watch someone use the thing, change it, and watch again. This is also where I finally check the list of claims from the research step.

I put the prototype in front of three to five real users before I polish anything.

• Give them a task. Ask them to do something they do every week, then watch. Where they hesitate matters more than what they say.
• Send the real link. A prototype in code runs on their own machine and responds like a real product, which a clickable mockup can't do.
• Record the session and write it up the same day. Notes go stale fast. Keep quotes word for word.
• Separate what they did from what they asked for. A feature request usually points at a problem. Find the problem before you build the feature.

Claude helps most after the sessions, when the notes pile up.

Here are my notes from five usability sessions with fleet managers testing the warranty claims prototype.

1. Group the feedback into themes. For each theme, count how many participants raised it and quote them word for word.
2. Separate observed behaviour (what they did) from stated opinions (what they said).
3. Flag any finding that contradicts an assumption in plan.md.
4. List the three changes with the highest impact, and what evidence supports each one.

Do not invent quotes or round up counts. If the notes do not support a claim, say so.

Then check the synthesis against the raw notes. Claude summarises well, but it smooths over the one odd comment that is sometimes the most important finding. Update plan.md with what changed, and go around the loop again.

Later laps don't all need me in the room. A follow-up round mostly checks whether a fix worked, so I run it as an unmoderated test in a tool like Maze. Participants get the task and the prototype link, and they do it on their own time. Maze reports how many people finished the task and which path they took. That is usually enough to tell whether the change helped. I save live sessions for the questions where I need to ask why.

On a small project, the prototype can turn into the product. On a bigger one, engineers build the real thing, and handoff is more than a Figma file. I give them the files that shaped the prototype:

• plan.md, with the product goal, the decisions, and what is out of scope.
• The design system in Markdown, and the styleguide with every token.
• The prompts I used, so they can rerun or adapt them.
• The prototype link, so every interaction has a working reference.

Engineers build with AI agents too, and their agents read the same files mine did. The build then follows the same rules as the prototype, and fewer details get lost between design and code.

AI makes the first version cheap. It does not make it good. Every screen still needs a person to decide what to cut and what to leave for later. When Claude can hand you ten drafts in an hour, the hard part is knowing which one deserves the next hour.

This is roughly how my time splits now:

The last row is the one I care about. Review takes as long as it always did, and that's fine with me. That is the step where I decide whether the work is any good.

I do very little of my work by hand anymore. Claude drafts the research and most of the prototype. My part is reviewing what it made and deciding what goes around the loop again.

If you want to try this, run the research prompt on a project you already know well. You'll see quickly what it gets right, and what you would have had to catch. Or see the work this process produced.