A delivery shaped around the whole system.
UMobile’s hailing service involved three parties: a car owner who supplied the vehicle, the driver the owner invited to operate it, and the riders who requested trips.
Cuesoft shaped and delivered the product around the owner’s, the invited driver’s and the rider’s journeys.
Experience design is part of the delivery.
A three-party product journey
A car owner made a vehicle available, invited the person authorised to drive it and kept a clear connection to the vehicle. Riders still requested a journey in the familiar way.
Ownership and driving kept separate
The interface separated providing a vehicle from driving it, so the owner’s invite carried meaning in the product.
The technical architecture.
Vehicle, driver and rider as connected records
The first version had to preserve a traceable link between the car, its owner, the invited driver and the trips riders requested. The role-specific actions in the app built on that link.
A journey for each role
Owners, drivers and riders had different responsibilities, so each role had its own journey in the app.
Details that make the difference.
Owners invited their drivers
The car owner invited the driver who would operate a vehicle. Assignment was part of the product, so the service modelled the real arrangement before a rider was matched to a trip.
Ride requests on the ownership model
Riders used a familiar ride-request experience, and the product kept the owner and driver relationship behind each available car.
A focused first version
The first version concentrated on the operating relationship behind the service: a car owner, the driver they invited and the rider journey.
- Mobility product design
- Driver hailing
- Vehicle and driver operations
- Multi-role product journeys
- Mobile product delivery
- Flutter