Share one lifecycle
The product uses consistent delivery states underneath role-specific interfaces.
Multi-role logistics product
Zapp Today
Three interfaces looking at the same delivery, each needing a different answer from the same underlying state.
- Role
- Product design contribution
- Product
- Multi-role logistics product
- Users
- Customers, drivers, and operations/support teams sharing one delivery lifecycle
The roles should share the truth, not the screen.
Customers want confidence, drivers need the next operational task and support teams need enough history to recover when something goes wrong. All three roles depend on one delivery lifecycle, but showing them the same information would make every experience worse.
My contribution. My work focused on booking context, driver tasks, tracking, delivery status, state transitions and exception handling across customer, driver and operational views.
Where the design judgment mattered.
Put the next task first for drivers
Active-work screens reduce secondary information and prioritize the action needed now.
Design exceptions before support has to explain them
Delay, reassignment, interruption and failure receive defined states and recovery paths.
Screens, shipped material and public references.
The artifacts sit inside the story because proof is more useful next to the decision it supports than in a ceremonial section at the end.
Experience model
One delivery lifecycle, three useful views
The design separates information priority by role without allowing status language to drift between them. That gives the product a stronger foundation for tracking, support and exception handling.
- 01
Booking creates the shared delivery context.
- 02
Driver views translate state into immediate tasks.
- 03
Customer tracking translates state into useful confidence.
- 04
Operations preserve history and exception detail for recovery.
What this work demonstrates
Different interfaces telling one consistent delivery story
The design separates information priority by role without allowing status language to drift between them. That gives the product a stronger foundation for tracking, support and exception handling.
Multi-role service designOperational state modelingException and recovery UX