A safer order-accept flow for couriers
Reviving a shelved feature, proving it with real usability testing, and shipping the version that actually works — for couriers reading a countdown at 60 km/h.
You didn’t accept in time. Repeated rejections can affect your account.
For two years, couriers used the same flow to accept orders. Then someone worked out what it was quietly costing.
10–14% of accepted orders were accepted by accident, behind about 4% of all cancellations.
Benchmarked five delivery apps, ran two rounds of usability testing, and redesigned onboarding and the order screen.
Two failures caught before launch, including 13 of 13 testers misreading the onboarding. Built to cut about 4% of cancellations.
The context
Mrsool’s couriers accept orders on the move — a map, a countdown, a tap. It’s been the same pattern for two years, and mostly, it works.
Between 10–14% of accepted orders were being accepted by accident.
Not because couriers didn’t want the work — because the accept flow made it too easy to accept without meaning to. Every one of those mistaken accepts had to be undone, and that undo is what a cancellation is. It was quietly responsible for around 4% of all order cancellations on the platform.
A fix already existed. It just never shipped.
Before this project started, another designer had already identified the problem and designed a solution: replace auto-accept with auto-reject — orders reject themselves by default unless the courier actively accepts. It was designed. It was built. It never launched — there wasn’t enough testing behind it to trust it in production.
That’s where this project actually starts. Not with a blank page, but with someone else’s unproven work and a month to either prove it or fix it.
Two kinds of validation
The brief split cleanly into two questions: was auto-reject actually the right call, and if so, was this design of it good enough to ship?
Problem validation — benchmarking and risk
Five major delivery platforms — DoorDash, Talabat, Hungerstation, Glovo, Deliveroo — were checked directly against their own apps and public walkthroughs, not assumed. Every one of them had already moved to some form of auto-reject. That answered the “should we” question. What varied was the “how”: rejection limits per shift, countdown timers from 30 to 45 seconds, progress bars versus static banners, automatic reassignment to another courier. The shape of the solution wasn’t in question anymore — the details were.
Solution validation — usability testing on the existing design
The shelved design still had to earn its place. It was run through structured usability testing and evaluated directly against Nielsen’s heuristics — recognition over recall, visibility of system status, consistency and standards — not as a checklist exercise, but because the test sessions kept surfacing exactly the failures those heuristics predict.
Primary research — riding along
To understand the courier’s actual moment of decision, the courier journey was mapped end to end, and orders were delivered personally to feel where attention actually goes when a countdown is running and a map is moving. That firsthand pass is what shaped the onboarding strategy that followed — informed by the forgetting curve: tell someone once, and most of it is gone within a day. A single announcement was never going to be enough.
What usability testing actually found
This is the part that mattered most. Two rounds of testing, two specific, quantified failures — not vague “users were confused” notes, but exact counts of exactly what went wrong.
13 of 13 test participants tapped “Accept” on the onboarding message — because it looked like a real order.
The first version explained the new system inside a card that visually matched the real order-accept screen. Every single tester read it as an actual order waiting to be accepted, not as a notice about a policy change. The second attempt tried an Arabic headline reading roughly “cancel the auto-accept system” — and every tester read that as the assignment system itself being switched off, the opposite of what was true. The final design broke visual similarity to a real order entirely and stated the actual consequence in plain language, in red: orders will now be rejected automatically if not accepted in time.
The order-details screen had its own quiet failure. An early RTL version placed the countdown inside a green button on a green-tinted background — and testers, reading the matching colors as a slide track rather than a button, tried to swipe left instead of tapping accept. The fix wasn’t a redesign, just a correction: move the countdown text back above the button, where couriers already expected to find it from years of the old pattern, and let the button just be a button.
Building trust in layers, not one message
Because a single announcement doesn’t survive the forgetting curve, the rollout was split across five touchpoints instead of one:
- Push notification. A lock-screen announcement — first contact, low friction, easy to miss on purpose.
- Main onboarding modal. The full explanation, shown once, redesigned after the two rounds of testing above.
- A persistent static banner. A minimized reminder shown across every screen — the fact stays visible even after the modal is dismissed and forgotten.
- Reinforcement inside the order screen itself. At 5 seconds left, the countdown’s copy, color, and a device vibration escalate together — a second sensory channel for the moment attention is most likely to be on the road, not the screen.
- A dedicated timeout screen. If the countdown wins, the courier isn’t left guessing why an order disappeared — they’re told plainly, with a warning about what repeated rejections mean for their account.
What this proved
The more interesting proof here isn’t a number — it’s what happened before any screen got redesigned. A shelved feature is usually shelved for a reason, and the honest version of this project is that the reason was real: it hadn’t been tested enough to trust. Two specific rounds of testing found two specific failures that would have shipped straight into production if the original timeline had held. Finding “13 of 13 users got this wrong” before launch, instead of after, is the entire value of the month this took.
Team on this project: