How I work

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. Most of what I remove from a design, I remove because it costs the user attention that the outcome does not need, not because it looked wrong.

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. The output is a position, not a feature list.

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.

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: in app store reviews, in feedback left during use, in threads on Reddit and Quora, and in the comment sections under the vendors' own pages.

That reading produces a catalogue of feature observations. I then rank it by how often each one recurs, which separates a structural complaint from one person's preference, 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.

Before a single screen, two things have to be settled: 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 the research said people were asking for.

People see structure before they read anything, and they do it by the Gestalt principles whether or not those were designed deliberately. So I use them deliberately, and I use them to describe the layout on paper before it is built, because this is how a user recognises a pattern in an interface in the first place.

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.

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 I hold 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.

Wireframes are drawn in Figma. The point of that stage is to settle information architecture and hierarchy while both are still cheap to move, so it stays low fidelity for as long as it is useful.

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 I hand the development team 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.

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. A test with no decision attached to its result is a delay, not research.

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. That is their judgement to apply, not mine to pre-empt, and the handover is better for being a working thing rather than a specification of one.

I avoid redesigning a design system that is already in place. A system carries decisions, constraints and accumulated reasons that are rarely visible from outside it, and replacing it usually buys consistency with the new work at the cost of consistency with everything else. The useful move is almost always to extend it in its own vocabulary.

The same applies to a concept that already exists. The concept stands on its own terms, and the design serves it and stays in harmony with it rather than bending it towards whatever the interface would prefer.