My Product Design Process:
Research to Handoff

Why process matters — and why it shouldn’t be dogma

I’m sceptical of design processes presented as universal recipes. Context changes everything: a 6-week MVP sprint looks nothing like a 6-month enterprise redesign. What I can share is the underlying structure I bring to any project — the sequence of questions I ask, the modes of working I move through, and the habits that have produced better outcomes across very different products and domains.

This is not a methodology. It is a set of dispositions, each corresponding to a phase where different modes of thinking are dominant.

Phase 1: Discovery — understanding before designing

Discovery is the phase most often cut short. “We already know the problem” is the most expensive sentence in product development. In seven years I have never worked on a project where the initial problem statement survived first contact with actual users. The problem that gets stated at project kickoff is a hypothesis. Discovery is the process of replacing that hypothesis with evidence.

What I do in discovery: User interviews (minimum 8, ideally 16+). Contextual observation where possible — watching people do the work in the actual environment, not describing it in a meeting room. Competitive analysis focused on interaction patterns, not visual design. Analytics review if data exists. Stakeholder interviews to understand organisational constraints, success metrics, and the gap between what the business thinks users need and what research shows they actually need.

Tools: Voice recorder + transcription (Otter.ai), Dovetail for synthesis, FigJam for affinity mapping. I avoid recording video in sensitive environments (healthcare, finance) and default to notes.

The output: A research synthesis document — typically 8-12 pages — with key findings, verbatim quotes, a prioritised list of user needs, and the specific assumptions the project was making that research either confirmed or disproved. This document is shared with the full project team, not just product and design.

Phase 2: Definition — shaping the problem before solving it

Definition is the phase where I resist the urge to start designing. Research has produced information; definition converts that information into design principles, constraints and a clearly bounded scope. Without this phase, the design work that follows has no anchor — every decision is made in isolation and the cumulative result is incoherent.

What I produce in definition: Design principles (3-5 guiding statements that make trade-off decisions explicit). A problem statement in the form: “Users who are [doing X] need a way to [achieve Y] because [current situation means Z].” A scope document that explicitly states what is out of scope and why. A success criteria list — how will we know this worked?

Why this phase matters: Design principles do the most work during the stages that follow. When you have two competing design directions, the principles tell you which one to pursue. Without them, decisions get made by seniority, opinion, or aesthetic preference — none of which are reliable guides to user outcomes.

Phase 3: Ideation — why I stay in low-fidelity longer than most

Most designers move to Figma too quickly. This is natural: Figma is a comfortable, familiar environment that produces artefacts that look finished. The problem is that “looking finished” is exactly what you don’t want during ideation. A polished wireframe invites feedback on visual treatment rather than structural logic. It also signals commitment to a direction prematurely.

I stay in low-fidelity — paper sketches, whiteboard photography, rough FigJam diagrams — until I have tested three to five structurally distinct approaches with real users. Not visual variations of the same structure, but different conceptual models for organising the same information or workflow. Users can evaluate and compare structural logic even in very rough form. They cannot evaluate visual design without being distracted by it.

What I do in ideation: 20-minute sketching sessions. Paper prototype walkthroughs with 5-8 users. Concept testing — showing two very different structural approaches side by side and asking which better matches the user’s mental model. Flow diagrams to validate information architecture before committing to screen layouts.

The gate from ideation to design: I only move to high fidelity when a structural direction has been validated by at least 5 users and the team has aligned on a single direction. This typically happens at week 5-7 of an 18-week project. Impatience here is expensive.

Phase 4: Design — building the system, not just the screens

By the time I open a high-fidelity Figma file, I have a validated structure, defined principles, and a clear scope. Design at this stage is execution and refinement, not discovery. This is intentional: the creative problem-solving that matters most has already happened.

How I work in Figma: I build component-first. Before designing any screen, I design the atoms: typography system, colour tokens, spacing scale, interactive states. This investment pays forward: every subsequent screen is assembled from a consistent system, and changes propagate automatically. I use auto layout throughout and variable fonts where supported.

The screens I design first: The most complex state, not the default state. The empty state. The error state. The 100-item list. These are the screens that reveal structural problems that happy-path design hides. If the component system works in the hard cases, the easy cases follow naturally.

Testing in design phase: I run usability testing at two points — on mid-fidelity prototypes with 5 users to validate interaction patterns, and on high-fidelity prototypes with 5 users before handoff. The second round focuses specifically on edge cases, error flows and the interactions that carry the highest risk of misunderstanding.

Phase 5: Handoff — design that survives contact with engineering

Handoff is not a final step; it is a continuous conversation that begins when the first components are built. The most efficient handoff is one where engineering has been involved throughout definition and ideation — not as observers, but as active contributors who flag feasibility constraints early, before those constraints require design rework.

What good handoff looks like: A Figma file with named components, annotated edge cases, and documented interaction logic (not just the happy path). A living spec document that captures state logic, error handling and accessibility requirements. A handoff session where I walk through the design, explain the decisions, and answer questions — then stay available for implementation questions throughout the build sprint.

What I avoid: Handoff as a handover. The moment design hands over a file and disappears, quality drops. I remain actively involved through implementation: reviewing builds, flagging deviations from spec, making real-time decisions on edge cases that emerge during development. Design quality lives or dies in the last 20% of implementation.

The mindset underneath the process

Every phase of this process is a different mode of thinking: Discovery is divergent and receptive. Definition is analytical and selective. Ideation is generative and experimental. Design is systematic and precise. Handoff is communicative and vigilant.

Switching between these modes is not automatic. The hardest discipline in product design is staying in the right mode for the right phase — not rushing to solutions during discovery, not reopening structural questions during design, not treating handoff as an endpoint.

The process is not what produces good design. The thinking is. The process is just a structure for protecting the thinking from being crowded out by urgency.