Design is done when the person using what we made feels more capable than they did the moment before they opened it. Everything in my process exists to make that true.
Process is not a sequence of steps. It is a series of decisions made before the user arrives — and a discipline for catching the ones that drift after they do.
Garry Kapoor
HOW I WORK
Six stages, run in sequence at the start of a project and in rotation throughout it. The first three are about getting the question right. The last three are about not losing the answer.
01
Sit with the Weight
Observe. Name the human moment.
I begin where the user begins — not with their job title, not with their use case, but with what they are carrying in the moment they open what we made. Interviews, on-site observation, contextual inquiry, VOC sessions, surveys — all of it pointed at one outcome. A single sentence I write before the project starts and refuse to lose.
What is this person carrying while they try to use what we are about to build?
That sentence becomes the acceptance criterion for everything that follows. If the work no longer carries it, the work has drifted — and I stop and re-anchor before another sprint compounds the gap.
02
Ask the Real Question
Define the problem underneath the brief.
The brief in hand is rarely the real one. The stated requirement is almost always sitting on top of a desire the user could not name and the business has not yet articulated. Before I write a single problem statement, I run a Clarity Sprint — fifteen focused minutes against three questions:
Who is the specific person? Not the persona — the human being, named, with a day and a context. What is the moment they are in when they open this? What is the one thing that must be true if everything else fails?
The output is not a problem statement. It is a question precise enough that the answer would change what gets built.
03
Map the Leverage
Distinguish what we were asked to build from what the project actually controls.
Before any wireframe, I write the Leverage Brief. The brief itself is the 100K — what we have been asked to build. The 600K is what this project actually controls if the vision holds all the way through: what becomes possible for the user, what relationship becomes available to them that did not exist before.
My job is to make the 600K visible before the first sprint begins, so the team knows what they are building toward — not just what they are building. The brief is the milk. The leverage is checking the fridge before you leave the kitchen.
04
Build the Feeling
Prototype for emotional fidelity, not just functional fidelity.
A prototype is how a vision becomes felt before it becomes built. I use Figma, AI co-creation tools, and code prototypes as a single instrument now — not to ship faster, but to make the vision visible faster. The room can argue with words. It cannot argue with what it has already felt.
The test for any prototype is not does it work. It is does the person feel more capable holding it. If the room cannot feel it in the prototype, the brief will not survive the sprint.
The prototype vision stops being mine alone and becomes something the team can carry forward without me in the room.
05
Catch the Drift
Test, validate, and run the weekly review that prevents reasonable decisions from compounding into the wrong product.
Drift does not announce itself. It arrives as small, reasonable decisions — a stakeholder request, a scope addition, a feature validated in isolation — that compound, until the product is pointing in a direction nobody chose. I run the EAR every week. Thirty minutes. Five checks:
Edge — does the work still carry the weight? Vision — does it still deliver the feeling? Loop — does the latest iteration land the touch? Arc — does it still live in the building we said we were designing? Exit — what does the person carry when they leave?. The EAR is the thirty minutes that prevents eighteen months of drift.
06
Own the Exit
Refine, ship, and stay in the room until what the team agreed to build is what the user actually receives.
The handoff to engineering is not where my work ends. It is where it gets tested by gravity. Implementation details, accessibility, microcopy, performance, the order in which information appears — every one of these is a place the feeling can quietly leave the product between design and ship.
I stay in the room through implementation review, design QA, and the first weeks after launch — because what the person carries when they leave the screen is what determines whether they come back. The ship date is a milestone. The return is the metric.