Mobile App Design
Aquahaulers Water Delivery App Design
Booking a water tanker meant a string of phone calls and a price that changed depending on who you spoke to. Two audiences, two research tracks, one marketplace.
- Client
- Aquahaulers
- Role
- Product Designer
- Year
- 2023
- Timeline
- 7 Weeks
Overview
In cities where the municipal supply cannot be relied on, a tanker delivery is not a convenience. It is how the building gets water that week. The booking, though, ran entirely on phone calls: you rang a number, you were quoted a price that moved depending on who picked up, and then you waited without knowing whether the truck was coming in an hour or after dark.
Aquahaulers is a marketplace for that job. Households book a verified tanker at a fixed price they see before they commit. Drivers get work routed to their phone instead of through a call they have to take while driving.
I was the only designer, working directly with the founder across seven weeks, brief to dev-ready handoff. The work ended there, so this case study reports design decisions, not production metrics.
A price you see before you commit
Cached addresses and standardised tank sizes make the quote deterministic, so it can be shown up front rather than negotiated.
Three taps to reorder
The common case is the same household ordering the same tank to the same address.
Dispatch without a phone call
Proximity alerts a driver can accept without taking their attention off the road.
Two apps, one marketplace
Opposite optimisation targets: the consumer app minimises taps, the driver app maximises target size.
The Challenge
The competition was not another app. It was a phone number that already works, held by a supplier the building has used for years.
That matters, because the phone call has real advantages. It is instant, needs no installation, works for a caretaker who does not use apps, and lets you argue about the price. Anything replacing it has to be faster than dialling before the transparency counts for anything.
What the call is bad at is everything after it ends and the failure lands on two different people.
What the household is up against
- A price quoted verbally, different from last time, with no way to tell whether it is fair.
- No confirmation. The order exists only in someone's memory.
- No arrival window, so somebody loses a day waiting.
- No way to tell a reliable supplier from an unreliable one except by having been let down already.
What the driver is up against
- Dispatch arrives as a phone call, taken while driving a loaded tanker.
- Jobs come in the order people rang, not in the order of what is close.
- Addresses relayed verbally, written on paper, then misread.
- No record of what was delivered, so disputes come down to one person's word.
Users & Context
The physical environment each side uses the app in decided more about the interface than any stated preference did.
| WHO | WHERE THEY ARE WHEN THEY USE IT | WHAT THE DESIGN OWES THEM |
|---|---|---|
| Household or caretaker | Indoors, unhurried, on their own phone. Usually reordering something they have ordered before, when the tank is already low. | Certainty. The price and the arrival window before they commit, and a record afterwards that the delivery happened. |
| Tanker driver | In a vehicle cab. Sunlight on the screen, one hand free at best. Working, not browsing. | Large targets, high contrast, and never a decision that needs reading a paragraph. |
| Operator | At a desk, watching several tankers and answering the customers who ring anyway. | A view of where every tanker is and which jobs are unassigned. |
Research & Insights
The signature decision was structural: two research tracks rather than one. Not two rounds of the same questions with different participants two separate sets of questions, run separately, because averaging a household and a driver produces an interface that is a compromise for both.
- Price was a proxy. Households opened with price. What they actually wanted was for the price not to be a conversation a fixed number they did not have to negotiate mattered more than a lower one they did.
- The reorder is the real use case. Almost nobody chooses a supplier from scratch each time. Designing the first-time flow as the primary path would have optimised the rare case.
- The waiting costs more than the money. Not knowing when the tanker arrives means somebody loses a day, and that cost is invisible in every version of this business that runs on calls.
- Accepting work must be cheaper than declining it. If the fastest way to deal with an alert is to ignore it, drivers ignore it.
- Drivers do not want to be tracked; they want to be believed. Location sharing was accepted where it produced a delivery record that settled disputes in their favour, and resisted where it read as surveillance.
Journey & Architecture
Two journeys running against each other, meeting only at the delivery. The design problem lives in the gap between them.
Two applications over one marketplace. They share a backend, an order object and a pricing model, and share almost nothing on screen.
The consumer app is a booking app
The home screen is the booking screen. No dashboard, because a household opens this three or four times a month with one thing in mind.
The driver app is barely an app
One screen is the app: the current job, or the next alert. Earnings and history sit behind a second tab, not designed to be used while working.
One order, two vocabularies
The same record is a "delivery" to the household and a "job" to the driver. Same object, different words, because the two sides do not think about it the same way.
Flows & Key Decisions
Three-tap booking — "the same as last time"
- Addresses cached, last-used one preselected.
- Tank sizes are a small named set, not a free volume field.
- Price computed from address and size, so it appears before confirmation rather than after.
- No account required to see a price. Asking someone to register before quoting is asking them to trust you first.
Fixed price, and when it cannot be
- The quote is binding for the slot it was given in.
- Surge changes the quote before booking, never after.
- If a driver cannot fulfil at the quoted price, the order is reassigned at that price rather than repriced. Repricing reintroduces the negotiation the product exists to remove.
Driver alerts — "accept without thinking"
- An alert shows distance, volume and payout. Nothing else.
- Accept and decline are the same size and equally reachable, so ignoring is never the cheapest option.
- An unanswered alert times out to the next nearest driver rather than sitting on screen.
- Legible at arm's length in direct sunlight.
Tracking that earns its intrusion
- Location is shared during an active job, not continuously.
- The household sees an arrival window, not a live dot — a moving dot invites watching, a window does not.
- The map appears only near arrival, when knowing changes what you do.
- The record it produces is visible to the driver too, and settles disputes.
Design System & UI
One accent colour doing the work of a trust signal, and a second, much louder set of rules for the cab.
Cerulean, because the product is water
A deep cerulean accent over structural slate blues. The association is obvious, and that is the point — the palette does a job the copy would otherwise have to do.
Two contrast standards, not one
The consumer app is designed to normal contrast rules. The driver app is designed to be read through a windscreen in sunlight: heavier weights, larger minimums, no colour-only signals anywhere.
Targets sized for the cab
Driver-side targets go well past the 48dp minimum, and the primary action on any driver screen is one button large enough to hit without looking carefully at it.
One language, two densities
Same tokens, same components, two spacing scales. The driver build is the consumer build with the air let in, which kept one component library serving both apps.
What I Did Not Test
The honest gap in this project, worth stating plainly rather than dressing up.
The research happened, with real households and real drivers, before anything was designed. The prototype was delivered at handoff without a round of usability testing against it the engagement ended where the build began. So the research findings came from people; the interface decisions came from me.
Three things I would put in front of users first: whether declining an alert is genuinely as cheap as accepting, since the whole dispatch model rests on it; whether the arrival window is believed, because a window nobody trusts converts a known unknown into a broken promise; and whether the driver screen is legible in an actual cab, given the poor record of contrast decisions made on a calibrated monitor.
Iterations
Three things that changed during the seven weeks.
- The live map moved later in the journey. The first version showed the tanker from the moment the job was accepted. Watching a truck crawl across a city for forty minutes makes a delivery feel slower than not knowing does. It became an arrival window, with the map appearing near arrival.
- The driver app lost its dashboard. An early version opened on earnings, ratings and job history. Wrong instinct: a driver opening the app is working, and all of that is something to read later. The current job became the app.
- Tank size stopped being a number field. The original flow had a volume input, which meant the price could not be shown until it was filled and could not be guaranteed at all. A small set of named sizes was what made the fixed quote possible. The most important decision in the consumer flow was taking an input away.
Final Experience
Impact / Outcomes
The work ended at dev-ready handoff, so this separates what was delivered from what the design is aiming at. Nothing here is a production measurement.
| DESIGNED | A price that is a fact rather than a negotiation. Standardised tank sizes and cached addresses make the quote computable, so it is shown before commitment and held for the slot it was quoted in. |
| DESIGNED | The repeat order as the primary path. Address and size preselected from the last order. The under-thirty-second figure is a design target, not a measurement. |
| DESIGNED | Dispatch without a phone call. Proximity alerts with symmetric accept and decline, and a timeout that reassigns rather than waits. |
| DESIGNED | A delivery record both sides can see. One order object, visible to household and driver, which is what settles a dispute about whether and when water arrived. |
| PROJECTED | Operator capacity. Tighter route clustering and automated dispatch were modelled to lift delivery capacity by roughly 40%. That is a design target derived from route modelling during the project, never measured in operation the number the work aimed at, not a result it achieved. |
| UNTESTED | Every interface decision. The research was done with real households and real drivers. The prototype was not put in front of them before handoff. |
| OPEN | The operator console. Scoped, deliberately not designed. A dispatcher view is a third product with a third set of questions, and squeezing it into seven weeks would have compromised the two that mattered. |
My Contribution
Research
Two separate research tracks, run with households and with tanker drivers, and the decision to keep them separate rather than average them.
Strategy & definition
The point of view, the standardised-tank-size call that made fixed pricing possible, and the scoping decision that left the operator console out.
IA & flows
Two application shells over one marketplace, the booking flow and its pricing branches, and the dispatch flow with its accept, decline and timeout paths.
Design system & UI
Colour, type and spacing tokens, one component library serving two densities, and the separate contrast and target rules for the driver build.
Prototype
A clickable prototype of both apps at device size, used to settle scope arguments with the founder before build.
Handoff
Figma source, a documented component library, exported assets and written specs covering the flows and their states.
FAQ
Frequently asked questions
How long did the Aquahaulers project take?
Seven weeks, brief to dev-ready handoff. Six would have covered a single-audience app. The extra week was the second research track, because a household booking water and a driver delivering it do not share a problem.
Why does a two-sided marketplace cost more to design?
Because it is two products. Not two rounds of the same research: two different sets of questions, run separately, then two interfaces optimised for opposite things. The consumer app minimises taps. The driver app maximises target size.
Why was the driver app Android-only?
Because that is what drivers carried. An iOS build would have cost time that bought nothing, and one design stretched across both platforms would have followed neither platform's conventions well.
Was the app built and launched?
I delivered the design through to dev-ready handoff: research, flows, a component library, a prototype and specs. The outcomes here are design targets the work was aimed at, not production measurements.
Next Project