Mobile App Design

Most app projects don't fail on visuals. They fail because nobody mapped what the user is actually trying to do, so the app ships with twelve screens where three would have done, and people quietly stop opening it.

I design mobile products end to end: the research, the flows, the interface, and the prototype your engineers build from.

Who this is for

• Founders and product teams building a first app, who need the thinking done as well as the screens.
• Teams with real workflow complexity. Multiple user types, scheduling, payments, live status. The apps where getting the flow wrong is expensive.
• Companies with an app that isn't working, where the numbers say people install it and then leave.

Who this isn't for

Worth saying plainly, so neither of us wastes a call:

• If you want the existing screens reskinned without touching the flows, I'm the wrong choice. Reskinning a broken flow gives you a prettier broken flow.
• If you need the app built as well as designed, you still need engineers. I hand off to them; I don't replace them.
• If the deadline is three weeks, I can't do the research properly, and the research is the part that makes the rest worth paying for.

How the work runs

Research and flows come first. I talk to the people who will use the app, not to a proxy for them, and map every path through it. You see the journey map and the flows before a single screen exists, because that is when they are cheap to change.

Wireframes settle the hard questions. What goes on the home screen. What gets cut. Those arguments are far cheaper over grey boxes than over finished UI.

Interface and motion come last, not first. High-fidelity screens, built on a component library, following iOS and Android conventions so the app feels native rather than ported from the other platform.

Handoff is a deliverable, not an afterthought. A clickable prototype you can test with real users, and a documented Figma system your engineers can build from without messaging you every day to ask what a state does.

What this looked like on Aquahaulers

Aquahaulers deliver bulk water by tanker, in a city where the municipal supply isn't reliable. Booking one meant a string of phone calls, a price that changed depending on who you spoke to, and no idea when the truck would arrive.

Two very different users, one product. So I ran two research tracks.

For households, the problem was uncertainty about the price and about the arrival. I designed a three-tap booking flow: cached addresses, standardised tank sizes, and a fixed price shown before you commit. A repeat order takes under thirty seconds.

For drivers, the problem was the phone. Dispatch happened by call, while driving. I replaced it with proximity alerts they could accept without taking their hands off the job, and designed the interface for a truck cab: oversized touch targets, high contrast, legible in direct glare.

The operator side is where it paid off: tighter route clustering and automated dispatch lifted delivery capacity by an estimated 40%. Seven weeks, brief to dev-ready handoff.

Read the full Aquahaulers case study for the research and the screens.

What you leave with

Not a folder of pretty screens. A product your team can actually build:

• The research, written down, so the reasoning survives after I've gone.
• Flows and wireframes for every path through the app.
• A Figma component library, not a pile of one-off screens.
• An interactive prototype you can put in front of users.
• Specs and assets your engineers can work from.

If you're building something and you're not sure the flow is right, that is exactly the conversation worth having early.