There is a comfortable way to start a product project. You design the onboarding, the home screen and a settings page. Everything looks finished within two weeks and the team feels good. Then week six arrives, and the one difficult flow turns out not to work.

I now do the opposite. In the first week I find the part of the product most likely to fail and I build a rough, working version of only that.

Finding the hard part

The hard part is rarely the screen people talk about most. It is the moment where the product asks the user for effort, trust or patience. At Northpier it was entering vehicle and passenger details on a phone. At Fernhouse it was the reminder schedule, which had no screen at all.

The hard part is the moment where the product asks for effort, trust or patience.

A useful test: ask the team which part they would least like to demo to a customer tomorrow. The room usually goes quiet, and then someone names it.

Rough, but real

The prototype should be ugly and honest. Real data, real delays, real error states. For Northpier I built the four-step checkout in code with no styling and tested it on a moving bus.

• Use real content, even when it is messy.

• Include the slow and broken states, not only the happy path.

• Test where the product will be used, not in a meeting room.

• Change one thing between sessions so you know what helped.

Session notes from week two of the Northpier project. Most of the red marks are on one step.

That bus test moved two fields to after payment. It is the single change that took the checkout from 3:40 to 1:05. No amount of polish on the home page would have found it.

Starting with the hard part has a second benefit. It tells the client early whether the idea works. If it does, the rest of the project is calm. If it does not, we have spent one week learning it, not three months.