Process
How I design with AI
One place where research, decisions, prototype and hand-off stay in sync. The core holds steady. The tools get better every week.
A snapshot · October 2026
This is how I work as of October 2026. Things move fast here, so by the time you read this, some of it may already have changed.
Where I come from
More than 25 years of design taught me what not to skip: research, flows, wireframes, visual design and a careful hand-off, without giving up the speed this AI era gives us.
What AI changed is how the pieces stay connected. Everything I learn about a feature builds up in one place, from the first request to the hand-off, instead of living in my head and in chat threads. What hasn’t changed: people make the decisions. The AI drafts, I decide, and I review everything before a stakeholder sees it.
Everything moves together
The steps below have an order, but the work doesn’t wait for it.
On any given day, the matrix, the logs, the prototype and the questions are all moving, and a change in one reaches the others.
People
Documents
Prototype
My AI assistants
Engineering
The seven steps
-
01
Gather
Every request, from every source. I start with the request wherever it lives: tickets, specs, shared docs, meeting notes, Slack threads and the application’s knowledge base. Early on, I also meet the client (and users, when we have access) to ask questions and get the scope right. Then I take my first reading to the dev leads: a CSD matrix, flows and rough sketches in Miro. We go through it together and list the questions. They know what the system already does, so many doubts turn into certainties right there.
Where AI helps I feed the sources into the framework by prompt, Miro flows included, as images. Feature tracking files them in the feature’s knowledge base, and the knowledge-base reader brings in the application’s rules.
-
02
Map
What we know, what we assume, what we still need to ask. The first thing I create isn’t a screen. It’s a matrix of certainties, suppositions and doubts, and it keeps filling up in those meetings until the scope is clear. Next to it, a decision log and a design log grow meeting by meeting: every visual change, and who asked for it.
Where AI helps A feature-tracking assistant I wrote sets up the three documents and carries each new decision into all of them, so they never drift.
C
Certainties
Somebody decided it.
A saved view keeps a list’s filters and sort order.Anyone can save views of their own.S
Suppositions
I believe it and would defend it. Nobody has ruled on it.
Each list needs a default view.Teams will want to share their saved views.Could become a certainty or a doubt
D
Doubts
Nobody has answered yet.
Who can edit a view someone else shared?Does deleting a shared view delete it for everyone?Was a certainty, until a meeting reopened it
Columns are states, not filing. The example cards are invented, about a fictional saved-views feature (a list’s filters and sort order, kept to reopen later), to show how the matrix works. -
03
Validate
Checked with people before anyone builds it. I take the matrix to interviews and meetings with the internal team and the client, in English, or settle points offline on Slack. A card moves when its answer does: one stakeholder can turn a certainty back into a doubt.
Where AI helps I feed the meeting notes back in by prompt, and they update the matrix and the logs.
-
04
Prototype
High fidelity, built from the product itself. As soon as a minimum scope is clear, I build an interactive prototype from the design system’s components, rebuilt from the live app. The build also checks the application’s knowledge base, so the prototype follows the rules of the application as a whole, not only the feature’s. Every prototype is interactive and published at a private address. Different teams test it remotely, in their own browser, and send feedback before development starts, not as rework for the developers. When we have access, users try it too.
Where AI helps The prototype reads two knowledge bases: the feature’s, which feature tracking keeps from day one, and the application’s, which my knowledge-base reader brings into every prototype.
-
05
Resolve
Questions answered where the problem is. A hand-off assistant I wrote generates the questions: it turns every open point into a question and pins it in the prototype itself, on the button or field it’s about, with the reason and an owner role. Then I run internal and client meetings from those pins, write the answers right there, and have feature tracking apply them to the prototype and every document. Answered questions stay on the board until the prototype shows the answer, then move to its history.
Where AI helps The AI drafts the wording. I rewrite each question until it can be read out loud, and it names a role, never a person.
-
06
Hand off
Documents that live with the prototype. The prototype’s Docs panel holds three of them. What’s New is a tour for stakeholders that opens with who can do what on each screen. Dev and QA is the full spec that engineering and QA work from. The same assistant writes both. The third is the CSD Matrix. They regenerate as decisions land, so when I change a rule or a screen, nothing gets left behind. And every procedure in them is a walkthrough you can click: each step opens the prototype where it happens, signed in as that role and in the exact state it needs, with a Click here marker on what to press. The doc keeps your place as you go. The same steps also read as pictures, a map of the prototype and the feature’s rules drawn as diagrams, and every topic opens with an In short line. A check runs over the whole set before anything goes out.
Where AI helps Engineering turns them into user stories, test cases and development planning (the requirements document).
-
07
Follow up
The work doesn’t stop at hand-off. While engineering builds, I answer the team’s questions, review the UI as each part lands and open tickets when needed. Now and then we step in on something the hand-off missed, though with AI that’s become rare. At the end, I update the product’s Help pages to match what the team built.
Where AI helps The AI reads the feature’s documents and drafts the Help page changes, and I review them before they go in. Once they’re merged, I ask the knowledge-base sync to feed them into the application’s knowledge base, so the next feature starts from them.
Across the project
From May to October 2026, the time I’ve been on my current project as its only designer.
- 400+design changes logged across 15+ features, most with the requester stated in the source
- 25+reversals of a settled rule, logged instead of silently overwritten; nearly all point to the entry they overturn
Counted from the project’s design logs by a metrics script I wrote, which also reads the git history and the open questions. I didn’t track time saved, so I don’t claim any.
The design system
Every prototype looks like the real application because I build it from the real thing.
I’m rebuilding the product’s components inside the framework: more than 30 so far, from tables, drawers and pickers to filters and navigation. That library makes a high-fidelity prototype fast to build and keeps it consistent from one feature to the next. It’s also why the client can test something that behaves like the product. When a feature starts from a screen that already exists, the page tracer I built helps me recreate that page from its URL, already in the prototype format and with the design system’s components. It gets me most of the way, but I still make targeted adjustments to reach the final result.
AI assistants I built
I work in VS Code with Claude Code, Anthropic’s AI coding agent, which reads, writes and changes the prototypes and the documents. The assistants below run inside the AI design framework our design team built for itself, with its own skills and agents. We built our own instead of adopting a ready-made tool, for five reasons:
- Consistency. Every prototype starts from the same components and rules, so they look and behave alike. That holds on every project.
- One way to build, whatever the stack. A prototype never depends on a product’s code: it’s plain HTML, CSS and JavaScript, built the same way on every project, whatever the product is made with.
- Confidentiality. Under NDA, the client’s material stays in tools we control.
- Ready-made tools fell short. The ones we tried didn’t hold up in early tests.
- We extend it ourselves. Designers build plugins and improvements by vibe coding, and developers review every change before it goes into the framework the team uses. The UI Inspector started that way.
The framework is a team effort. These assistants are mine.
Feature tracking
Sets up the feature’s knowledge base on day one (the matrix, the decision log and the design log), keeps them in step, and carries the answers from the pinned questions into the prototype and every document.
Knowledge-base reader
Brings the application’s rules into every prototype and Help page, so new screens respect the roles and rules that already exist.
Knowledge-base sync
When I ask, at follow-up, reads what changed in the Help pages and feeds the application’s knowledge base.
Hand-off assistant
Once there’s a prototype, turns the feature’s knowledge base into the What’s New and Dev and QA documents, with an access matrix for each screen, turns open points into questions pinned on screen, and makes every flow step open the prototype in the exact state it describes, by pressing the prototype’s own buttons.
Page tracer
Turns a live page into a first draft of a prototype from its URL, using the components and styles the design system already has. Fast by default, measured on request.
Visual parity
Reads the product’s styles straight from its source code (colours, corners, borders, spacing, type and sizes), so every rebuilt component and traced page matches the app exactly.
Product UX writing
Writes and reviews every interface string, from labels and tooltips to errors and empty states, against the writing guidelines and the wording the app already uses.
UI Inspector
A style inspector and editor for prototypes that turns every tweak into a prompt.
Where it is going
The steps haven’t changed since I joined this project. The assistants behind them get better every week, and some of them are now used by the whole design team. Right now, answers typed in a meeting still need an export step, because they live in the browser of whoever typed them. I want them somewhere the whole team can see. And after release, I want to count the questions engineers bring back, to measure what the hand-off still misses.