One Bar of Signal on a Crowded Bus

Every project I start, I write one sentence before I draw anything: who is here, what are they trying to do, and where are they when they do it. Not "users want to book a tour", but "a traveller in another country, on a phone, nervous about paying a company they have never met."

That last part, the situation, changes almost every decision. It decides how big the buttons are, what loads first, what the error messages say, and what I leave out.

Desks lie

A design that looks perfect on a 27-inch monitor with fast Wi-Fi can fall apart in real life. In Ghana, a lot of people meet your product on a mid-range Android phone, on mobile data, often outside. If the page needs five seconds and three taps before it says anything useful, you have already lost them.

• Design the phone layout first, then grow it for bigger screens, never the other way round
• Put text and layout in the first response from the server, so something useful appears before any script runs
• Check every screen at 320 pixels wide, because some people really do use phones that small
• Assume the signal will drop, and decide what the screen should say when it does

Ask for the least, first

One rule I keep coming back to: friction should rise with the stakes. Signing up to look around should take almost nothing. Getting paid out, or controlling a water pump from far away, can ask for more, because the risk is higher. Asking for everything up front is how forms get abandoned.

Ask for the least first, and more only when the stakes rise.

Make everything visible

People should always be able to answer four questions on any screen: where am I, what is happening, what just happened, and what can I do next. When something is locked, say why. When something is loading, show the shape of what is coming. When a payment is still confirming, say so calmly instead of showing an error that frightens people.

None of this is decoration. It is the difference between a product people trust and one they close.