Mobile logistics · Customer, driver and operations
Zapp Today
Helping customers describe a delivery, review the request and understand the handoff to a driver.
- Contribution
- Mobile product design contribution
- Evidence
- Historical app design + current desktop website reference
The project and my part in it
A delivery involves several people with different jobs. The customer describes what needs moving, the driver handles the next stop, and operations needs enough context to resolve an exception.
My contribution covered these connected mobile journeys. I focused this case on how the customer request becomes a clear delivery task, while keeping customer and driver screens distinct.
What shaped the design
- Customers and drivers act on the same delivery with different priorities.
- Pickup, parcel and service choices need to stay connected through review.
- Address lookup, routing and payment depend on real services.
THE DESIGN CHALLENGE
How can the same delivery feel clear to the person booking it and the person carrying it out?
The customer journey moves from account entry to pickup, parcel details, service selection and a final review. The driver then needs an operational view of the same delivery.
Make the first choice clear
The account-entry screen gives Create account and Sign in their own explanation. New customers have a clear starting point, and returning customers can go straight to the route they need.
Registration and code verification continue that path. Keeping the mobile number and resend action understandable is part of making the next step feel connected to the previous one.
Giving the new-customer action more emphasis should not make sign-in hard to find.
Build the request one decision at a time
Pickup entry offers address search, a landmark route and current location. The parcel screen then asks what is being carried, with named package types and a description field. Service selection follows after that context exists.
The review screen brings the request together before payment: pickup, recipient, parcel, vehicle and a sample estimate. An edit-recipient action gives the customer a way to correct a detail without starting again.
Breaking up the request keeps each step focused, while the final review needs to show how the choices fit together.
Give the driver a clear next stop
The driver view distinguishes a confirmed pickup from the next drop-off. Progress and the current stop take priority, with a separate route for reporting a stop issue.
This is where the handoff needs an agreed rule. The team has to define which driver action changes the delivery status and what the customer or operations team sees afterward.
Driver and customer views need a shared account of progress, even though their next actions differ.
Separate a finished delivery from payment records
The completion screen names the handoff and offers a return to availability. Settlement and earnings depend on verified server records, so they remain a different responsibility.
For implementation review, I would check an interrupted handoff, a repeated completion action and the return to the driver dashboard. Those situations are part of making the completion message dependable.
A reassuring completion message must describe what is actually known to be finished.
Current public website reference
What I delivered
The screenshots connect entry, pickup, parcel and service choices, review, the driver’s next stop and completion. The added pickup and review screens fill in the customer journey between the earlier examples.
Current public website, checked 5 November 2026. Its presentation may differ from the customer-app design contribution described in this case.
Outcomes and next steps
The design gives the customer and driver different priorities within one delivery story. Routing, dispatch, payment and delivery performance still need real-service evidence.
What I would test next
- Compare the customer milestone with the driver action for pickup, arrival and completion; each pair should describe the same service event.
- Walk through an intermediate-stop failure and delayed completion update. Check that the next action remains clear without implying settlement has occurred.
What I learned
A delivery flow becomes easier to explain when every screen answers a practical question: what are we moving, where is it going, what happens next and who acts now?
