My approach

This is not a step. It is the lens every step below is read through. The frame comes from cognitive and behavioural psychology: what a screen costs in attention, what it assumes someone already remembers, what it asks them to hold in working memory while they go and do something else. Those questions are answerable. Taste is not, and a design argument settled by taste is a design argument that gets reopened every sprint.

The design work then sits between two things that both have to hold: the business logic of the application, and the outcome the client is trying to produce. A flow that serves one and not the other is not finished.

1. 1Position the productA position and a named market segment
2. 2Read what the users already saidA catalogue of requests, ranked by how often they recur
3. 3Empathise, then write the problem downA written problem statement and the solution to it
4. 4Structure the layout with GestaltThe layout described on paper, before it is drawn
5. 5Grey wireframes in FigmaInformation architecture and hierarchy, settled in grey
6. 6A working prototype in hoursSomething the team can open and use
7. 7Hold it against Dieter RamsEverything that does not earn its place, removed
8. 8Build it, then hand it overA working build in the developers’ hands
9. 9Measure it once it is liveA decision for each open question

Before anything gets drawn, I research where the product can sit. That means the competitive landscape, what the incumbents are actually good at, and which part of the market is underserved rather than simply crowded.

Only once I can name the market segment does it make sense to look at the people in it. A product with no position produces user research that cannot be acted on, because every finding applies to somebody and none of them applies to the person you are building for.

What goes in

The competitive landscape, what the incumbents are good at, and where the market is underserved

What comes out

A position, not a feature list, and the segment it is for

Guideline applied here

Do not reinvent the wheel: what incumbents already do well is learned from, not redrawn

With a segment identified, I gather as much as I can about those users and about what makes them satisfied, and most of it already exists in public. People describe what is missing from the software they use, in detail and unprompted.

That reading produces a catalogue of feature observations. I rank it by how often each one recurs, and the ranking is what the build order follows. It is the cheapest research available and the most specific, because none of it was said to a researcher.

What goes in

App store reviews, in-product feedback, Reddit and Quora threads, comments under the vendors’ own pages

What comes out

Feature observations ranked by frequency, which becomes the build order

Guideline applied here

Frequency over opinion: a request that recurs is structural, one that does not is a preference

Two things have to be settled before a single screen: which category the product belongs to, and who it is for. Then I empathise with that group properly, which is the point of the exercise and not a warm-up for it. Without it you end up solving a problem that is easy to describe rather than the one that is expensive to live with.

What comes out is a written problem statement and the solution this product offers to it. Everything downstream gets measured against that sentence, including the features step 2 said people were asking for.

What goes in

The segment from step 1 and the ranked catalogue from step 2

What comes out

One problem statement and the solution this product offers

Guideline applied here

Empathy before execution

This is where Gestalt is applied, and it is applied before the layout exists. People see structure before they read anything, and they do it by these principles whether or not they were designed deliberately. So I use them deliberately, to describe the layout on paper before it is built.

Proximity

Things placed close together are read as one group, before any label is read.

Similarity

Controls that look alike are assumed to behave alike, so a control that looks different is claiming to be different.

Common region

A shared container groups its contents more strongly than a heading above them does.

Continuity

The eye follows a line or an alignment, which is what makes a sequence read as a sequence.

Closure

An incomplete shape is completed by the viewer, so structure can be implied rather than drawn.

The practical test is simple. If I find myself writing a label to explain which things belong together, the grouping is wrong, and the label is a patch over a layout that failed to say it.

What goes in

The problem statement and the ranked features it keeps

What comes out

Which things group together, in what sequence, and inside which regions

Guideline applied here

The Gestalt principles: proximity, similarity, common region, continuity, closure

The paper layout becomes wireframes in Figma. The point of this step is to settle information architecture and hierarchy while both are still cheap to move, so it stays grey and low fidelity for as long as it is useful. Colour at this stage would start an argument about colour instead of about structure.

If a design system is already in place, the wireframes are drawn in it. A system carries decisions, constraints and accumulated reasons that are rarely visible from outside, and replacing it buys consistency with the new work at the cost of consistency with everything else. The same goes for a concept that already exists: the design serves it rather than bending it.

What goes in

The paper layout, and the existing design system if there is one

What comes out

Low-fidelity wireframes with no colour in them yet

Guideline applied here

Grey prototype before any colour, and extend an existing system rather than replace it

For a working prototype fast enough to be worth discussing, I use AI-augmented development tooling such as Claude Code and Cursor, or Google Stitch for a first pass at the frames.

What the development team sees is therefore something they can open and use, not a static picture of it. That changes the conversation: they respond to behaviour rather than to intention, and the disagreements surface while they are still cheap.

What goes in

The grey wireframes

What comes out

A working prototype built with AI-augmented tooling

Guideline applied here

Behaviour over intention: the team responds to what it does, not to a picture of it

Before anything is handed over, the working prototype is held against Dieter Rams. Rams ran design at Braun and is, for me, one of the finest product designers there has been. His ten principles are the closest thing this discipline has to a usable standard, and this is the point where I measure the work against them rather than against a mood board.

1. 1Good design is innovative
2. 2Good design makes a product useful
3. 3Good design is aesthetic
4. 4Good design makes a product understandable
5. 5Good design is unobtrusive
6. 6Good design is honest
7. 7Good design is long-lasting
8. 8Good design is thorough down to the last detail
9. 9Good design is environmentally friendly
10. 10Good design is as little design as possible

The last one carries the most weight in practice. As little design as possible means every element has to earn its place and guide the person using it, rather than add to what they have to work out. Less is more is not a style here, it is a test: if something can come out without the screen losing a job, it comes out. Most of what I remove, I remove because it costs the user attention the outcome does not need, not because it looked wrong.

What goes in

The working prototype

What comes out

A leaner prototype where every element guides the person using it

Guideline applied here

Rams’ ten principles, the tenth above all: as little design as possible

Most of the time I build the thing I designed. Designing a flow and building it are the same act of reasoning about someone's intent, and doing both means a design that cannot be built as drawn gets found out in hours rather than at a sprint review.

It then goes to the developers to be made properly developer-friendly and fitted to the engineering patterns the company already works in. The handover is better for being a working thing rather than a specification of one.

What goes in

The prototype that survived the Rams check

What comes out

A build the developers fit to the engineering patterns the company already uses

Guideline applied here

The engineering patterns are the developers’ judgement to apply, not mine to pre-empt

Once something is live, the design is a hypothesis with usage data attached. I use behavioural monitoring to see where people hesitate, where they leave, and which route through a flow they actually take rather than the one the flow was drawn for.

Where two solutions are genuinely arguable, that is what A/B testing is for, against a metric tied to the outcome the client wants rather than to engagement for its own sake.

What goes in

Real usage: behavioural monitoring and, where two options are arguable, an A/B test

What comes out

Where people hesitate, where they leave, which route they really take, and what to change

Guideline applied here

A test with no decision attached to its result is a delay, not research