From problem to product
How I run the end-to-end design process — research, ideation, prototyping, accessibility, dev handover. It varies by project, but these five phases are the shape it usually takes.
Discovery
Objective
Understand the problem space before proposing solutions. FigJam is my best friend in this phase — research notes, random links, and stray thoughts all land on the same board. The goal is a mental model, not a deliverable.
What I do
Talking to PMs and user researchers, reading whatever telemetry already exists, and pulling apart how comparable products solve the same thing. Working on products at Microsoft scale means the constraint is rarely a blank page — it is the system already in place.
Framing
Objective
Convert a vague problem into a specific, testable design question, and check early whether it can actually be built.
What I do
Agreeing the success measure with the PM, and testing what they are asking for against how people actually work — which task the request sits inside, and whether the behaviour it assumes is one users have. Running feasibility checks with engineering while the direction is still cheap to change, and sharing out early to build stakeholder buy-in.
Ideation
Objective
Generate genuinely different approaches, not variations on one idea. I push for structurally distinct directions before narrowing.
What I do
I facilitate ideation sessions with engineering in the room, so technical reality shapes ideas early rather than killing them late. Fidelity is a decision about the audience, not a stage: low fidelity keeps a review about the direction, and I only raise it when the people in the room need something more finished to react to. I also use agents as a sparring partner here — somewhere to argue a direction out loud and pressure-test a flow first. It doesn’t replace a critique; it means I arrive at one having already found my own weakest assumption.
Validation
Objective
Find out where the design breaks before engineering builds it. I optimise for finding problems, not for confirming the design works.
What I do
The first pass is usually a Figma prototype — it is quick to change and enough to find where a flow falls apart. When the question is one a click-through can’t answer, I build it in code instead, wired to real APIs where it matters, so the interaction meets real latency and real content. Which one I reach for depends on the product and the setup around it: live services cost more up front, and some questions are only worth that. Accessibility gets checked here, not after.
Delivery
Objective
Ensure what ships matches what was designed — and improve any design library it touches as a byproduct.
What I do
Handoff with the edge cases covered: empty, loading, error, overflow. Then I stay in it — pointing engineers at the exact frames, suggesting which design tokens to reach for, reading the pull request, and giving feedback in the terms they were already working in. Having been the engineer on the other side of that handoff makes the conversation shorter.