A lot of projects start the same way. Someone has run ten interviews, the notes are scattered over five documents, and a designer is already drawing screens. The screens look good. They also answer questions nobody checked.
I try to slow that part down. Before any UI, I build a small foundation: what we learned, what is broken, how the product is organised, how people move through it and why we made each choice.
How I run it
- I give Claude Code the transcripts and notes and ask it to group what people said into themes. Every insight keeps a link to the quote it came from.
- If a product already exists, I audit it and log each problem with an example.
- I decide how the product is organised and draw it as a diagram. I use Mermaid, because the diagram is just text and stays easy to edit.
- I map the main flows, including what happens when something goes wrong.
- I write down why the important decisions were made.
- I finish with the accessibility requirements and a short glossary, so the team uses the same words.
What the AI does
It does the slow reading. Forty pages of notes become a set of themes in a few minutes, and the documents stay consistent with each other. What it cannot do is decide what matters to your business. That part stays with me.
My one rule: if I cannot trace an insight back to a real person, I treat it as a guess and leave it out.
A word on UX laws
UX laws are handy, but they are rules of thumb. I only name one when I can point to the decision it changed. Here are the ones I reach for most:
- Hick's Law, when a menu has too many options. I cut it down and show each role only what it needs.
- Miller's Law, when a list is long. I group the items into small clusters.
- Jakob's Law, when a task is familiar. People expect it to work like the apps they already use, so I keep it familiar.
- Tesler's Law, when a task is complicated. Some complexity cannot be removed, so I decide who carries it and make it the product, not the user.
- The goal-gradient effect, in long flows. I show progress, because people speed up as they get closer to the end.
What you get
A written synthesis of the interviews, the audit findings, the architecture and flow diagrams, the reasoning behind the key decisions, the accessibility requirements and a glossary.
Where it goes wrong
Skipping the audit because the product is new is a mistake, since even a prototype has patterns worth checking. Letting the AI summarise without sources is another. And leaving accessibility until after the design makes it much more expensive.
All writing