Winnie.N®Corevia
One delivery lifecycle connects Customer, Operations, Fleet Manager, and Driver—from booking to proof of delivery.
- Role
- Product Designer
- Scope
- Service model · IA · User flows · Product UI · Design system
- Outputs
- 2 web portals · 2 mobile apps · Design system
One order crosses four roles while the supplied brief describes fragmented operational information.
The order is shared; Customer, Operations, Fleet Manager, and Driver have different responsibilities.
Each screen prioritizes the next action and exposes failure paths for matching, capacity, or delivery.
Four UI sets and a design system are documented; no field test, baseline, or post-launch result is supplied.
One order, too many disconnected decisions.
The supplied brief describes operational information spread across radio/WhatsApp, manual tracking, and paper records. Without one shared order status, four roles may act on different information. This is framing from the brief and UI artifacts, not a validated field-research finding.
Four surfaces. One delivery lifecycle.
Read the work as one service system, not four independent screen collections. A booking becomes an assignment, draws on fleet capacity, moves through execution, and closes with proof of delivery (POD). Status must tell each role what happened and what they need to do next.
- 01Request
Customer chooses stops, cargo, vehicle, and time.
- 02Match
Operations assigns resources and handles no-driver exceptions.
- 03Capacity
Fleet Manager manages records, drivers, vehicles, and maintenance.
- 04Execute
Driver confirms milestones and reports delays or issues.
- 05Proof
POD closes the feedback loop with the customer.
Customer: remove uncertainty before booking.
Booking progresses through route, cargo, vehicle, schedule, and confirmation instead of one dense transport form.
- Rationale
- Cargo and destination affect vehicle choice; vehicle and timing affect expectations before confirmation.
- Failure path
- No driver available and Retry searching acknowledge that matching may fail.
- Validation lens
- Booking completion, incorrect vehicle choices, support requests—proposed measures, not results.
Operations: make exceptions actionable.
The dashboard puts action signals first; Dispatch and Exception Queue connect detection with resolution.
- Rationale
- Late orders and unassigned drivers get lost in a normal order list.
- Failure path
- Operations owns system-wide assignment; Fleet Manager owns the readiness of a particular fleet.
- Validation lens
- Time to assign, detect, and resolve exceptions; no baseline available.
Fleet Manager: protect capacity before it blocks delivery.
Driver and vehicle records, verification, maintenance, and performance sit in one resource-decision context.
- Rationale
- Deliverability depends on available drivers and vehicles, not just the number of open orders.
- Failure path
- Expiring inspections or unapproved profiles need visibility before dispatch is affected.
- Validation lens
- Verification time, vehicle readiness, utilization; not yet measured.
Driver: make every field milestone provable.
The app follows trip preview, pickup, transit, delivery, and POD rather than putting every action on one screen.
- Rationale
- Sequential status keeps the driver oriented while Operations and Customer see matching progress.
- Failure path
- Delays, incorrect updates, and weak connectivity need testing in real-world conditions.
- Validation lens
- POD completion, status errors, offline usability; no field test yet.
The design exists. Outcomes need measurement.
Potential improvements in booking clarity, dispatch and exception handling, vehicle readiness, and proof-of-delivery completion remain hypotheses. The supplied work has no measured baseline, field study, or post-launch outcomes.
Follow the complete product reasoning.
The complete case study connects context, the operating model, Product Design decisions, and UI across four roles. Individual HTML UI files remain private.
Designing a product with multiple roles?