A three-day design exercise: redesign how a Toters Butler order gets placed.
Toters: Butler · PRODUCT DESIGN · DESIGN EXERCISE · 2025
What follows is how I approach a real product under a tight clock — and what I’d have done with more time.
Butler lets users request delivery of almost anything that fits on a motorbike — forgotten keys, documents, personal items. The service was flexible. The ordering experience was not: one request was split across several screens, forcing users to change context again and again before they could see the order as a whole.
Properties
- Role
- Product Designer
- Design exercise
- Toters — three-day take-home
- Timeline
- 3 days
- Scope
- Flow analysis, UX strategy, interaction design, mobile prototyping
- Focus
- “Deliver Your Stuff”
I redesigned the flow as one editable page — addresses, instructions, items, payment, pricing and courier availability in a single continuous experience.
The goal was not to remove screens. It was to make the request easier to understand, correct and submit.
01 — The challenge
Ordering from a restaurant starts from a catalogue. Butler starts from an open-ended request — the user has to explain:
- What needs to be delivered
- Where it should be collected
- Where it should go
- What the courier needs to know
- How the order will be paid for
The existing flow collected all of this across a sequence of screens. That structure worked, but it separated information that belonged to the same decision: changing an address meant going back, adding items stretched the flow, and the full price only appeared near the end.
02 — How I evaluated the existing flow
I walked through the existing flow myself and timed it — recording both Butler request types end to end. With three days on the clock, this was the primary research artifact.
- ~41s — to place a basic Deliver Your Stuff request in the existing flow
- ~52s — for the Buy Something flow — and growing with every added item or image
The recordings were not formal usability tests. They exposed where the interface changed context, loaded another screen, or made the user remember information entered earlier. The issue was not that every step was unnecessary — Butler genuinely requires detailed information. The problem was how that information was divided.
What the reviews added
For a second signal, I pulled the app’s online reviews and had AI compile them into recurring pros and cons — not a formal methodology, just a fast way to see what users praise and what they complain about.
People valued
- The ability to deliver almost anything
- Real-time order tracking
- Rewards
- Saved preferences that made future requests faster
The main complaints
- App stability
- Slow GPS updates
- Long waits for courier acceptance
- Unclear pricing and delayed customer support
Crashes, GPS performance, courier supply and support response times sat outside what an interface proposal can fix. I focused on what the request flow could directly influence:
- Ordering effort
- Address visibility
- Backtracking
- Fee transparency
- Courier availability
- Clarity before confirmation
03 — Framing the problem
The Butler user is not completing a conventional checkout. They are translating a real-world errand into instructions another person can act on. The redesign had to support four things:
- Keep the whole request visible — Pickup, delivery, items and instructions form one task. They should not feel like unrelated screens.
- Make corrections immediate — Changing an address or order detail should not require reconstructing the journey.
- Surface cost before commitment — Users should understand what they are paying and how the total is structured.
- Reduce uncertainty around the wait — Show whether couriers are nearby before asking the user to submit.
04 — The design direction
I consolidated the request into one scrollable page — not one dense form, but recognizable sections with the order staying intact as the user moves through it:
- Service type
- Pickup and delivery addresses
- Driver instructions
- Order items
- Promo code
- Toters Cash and payment
- Fee breakdown
- Courier availability
- Final review
1. Keeping the route in view
Pickup and delivery sit beside each other at the top — both ends of the journey confirmed at a glance, with tap-to-edit and drag-to-swap. The win is not the gesture: it is that route correction happens inside the order instead of through backward navigation.
2. Adding information without adding steps
Multiple items and photo attachments live directly on the page — a plus control grows the request without opening another screen. An open-ended Butler request can get complex fast; the order grows while the rest stays visible.
3. Making cost and availability visible
One payment view brings together Toters Cash (in both currencies), the payment method, a fee breakdown, the final total, nearby courier availability, the expected wait, and the choice to request now or schedule.
The most important trust improvement: users decide with the cost and the expected wait in front of them — not after discovering them later.
4. Removing pressure from confirmation
The final summary shows the full request — addresses, instructions, items, totals in both currencies, estimated wait — with a way to modify it. It confirms what the user already saw; it is not a place to discover new information.
05 — The decisions, and why
Every interaction choice traces back to the walkthrough timings or the review findings:
- One continuous page — The timed walkthroughs showed the old flow spending its seconds on screen changes and reloads. The presentation estimated consolidation could save 4–6 seconds — a hypothesis, never tested.
- Tap to edit, drag to swap — Tapping is familiar and visible to everyone; the swap gesture rewards discovery without hiding the basic path.
- Slide to confirm — Gives the user control over the moment of submission and cuts accidental taps.
- Review timer removed — Confirmation should not be pressured — the summary is a place to check the request, not race it.
- “Request Now” is primary — Requesting a Butler is the whole point of the service. Scheduling stays available, but secondary.
- Courier info before submitting — The loudest review complaint was long waits for courier acceptance. Seeing nearby couriers up front informs whether to request now or schedule.
06 — What changed
- The request was divided across multiple screens → The request became one scrollable order
- Pickup and delivery were handled separately → Both addresses stayed visible together
- Corrections required backward navigation → Key details could be changed in place
- More items extended the flow → Additional items were added within the order
- Promo entry used another interaction layer → Promo entry appeared directly on the page
- Price and payment appeared later → Totals and fees were shown before submission
- Courier availability was uncertain → Nearby courier information was surfaced
- Confirmation created time pressure → The review timer was removed
- Scheduling competed with the main action → Request Now became primary
07 — What the brief asked me to hit
The brief framed success as an OKR set. The objective: provide a frictionless experience for the customer placing the order. The key results:
- 20% — target decrease in time spent on each page, and in the overall time spent placing the order
- 30% — target decrease in customer backtracking while building a Butler order
- 40% — target decrease in operations agents’ manual intervention in Butler orders
Plus a fourth with no figure attached: missing or incomplete information provided by the customer about the Butler order should decrease.
None of it was measured. A three-day exercise ends before rollout — this page shows the proposed experience and its reasoning, not validated results.
08 — What a real engagement would have added
The presentation itself flagged what a longer engagement would take on next:
- User testing and success metrics
- Improved WCAG compliance
- A simplified “Buy Something” flow
- Embedded real-time support
- Further product development
Testing would need to determine whether the consolidated page actually reduced completion time and backtracking without making the form feel too dense.
09 — Closing
Butler’s value came from its openness: users could request almost anything. The redesign preserved that flexibility while giving the request a clearer structure — visible, editable and understandable from the first address to the final confirmation.
The redesign did not simplify what Butler could do. It simplified how users explained what they needed.
