The useful starting point
Scope the journey across every participant. Tracking is useful when it sits alongside clear ride status, appropriate actions and a way to handle exceptions.
Design the passenger and driver journeys together
Passengers need to arrange and follow a ride. Drivers need the information and actions relevant to their side of it. Separate applications can give each person a focused experience, while the product still needs a shared understanding of the trip.
Map the journey across both applications. At each step, ask what the person sees, what they can do and what the other participant should learn when something changes.
Map the service across its participants
Illustrative example · a planning model; actual ride states depend on the service
| Stage | Passenger | Driver | Operation |
|---|---|---|---|
| Request | Provides the journey information | Sees the request if eligible | Can understand the request’s current state |
| Accept | Learns that a driver is assigned | Sees the active assignment | Can identify who is assigned |
| Approach | Follows the arrival information | Follows the relevant pickup task | Can investigate if help is needed |
| Trip | Understands the journey is in progress | Works within the active-trip experience | Can distinguish an active trip from a completed one |
| Complete | Can find the completed journey | Can see the completed work | Can inspect the resulting record |
Read across each row. A screen that looks finished for one person may leave another participant without a clear next action. That is a scope problem as much as a technical one.
Put exceptions in the first test plan
| Situation | Question the product must answer | Useful evidence from a demonstration |
|---|---|---|
| Two drivers act on the same request | Which assignment is authoritative? | Each participant reaches a consistent result |
| Cancellation and acceptance happen close together | Which actions remain valid? | The final state and explanation are clear on each side |
| A connection drops during an active trip | What remains visible and what needs checking? | The user can understand the state during the gap and after recovery |
| A support question arrives after completion | How does the operation investigate? | The relevant journey record can be located without private device access |
These are illustrative acceptance scenarios. The implementation and operating rules need to be agreed for the service being built; the table is not a record of incidents at a client.
Give each technical discussion a clear scope
This guide concerns the complete product: roles, actions, operations and acceptance criteria. The companion guide on stale driver locations goes deeper into the location stream itself—freshness, background behaviour, gaps and recovery.
Keeping these discussions connected but distinct helps a founder see the whole scope and gives the engineering team room to examine a difficult component in detail. The first release needs both a useful end-to-end journey and an explicit view of its important technical constraints.
Give every state a clear meaning
Booking, acceptance, arrival and completion are useful places to start a conversation about ride status. A real operation may need additional steps or different rules. Agree them before designing the screens around them.
Then work through exceptions. What if a request is cancelled while a driver is responding? What if the phone loses its connection? What should a person see when the latest position is unavailable? These are planning and test questions, not reasons to promise that a product will never fail.
Decide what live tracking needs to communicate
A location update should support a decision or reassurance for the person viewing it. That means considering the context around the map, including the ride status and whether the displayed location is recent.
Test tracking in realistic conditions for the intended devices and operating environment. A convincing demonstration on a single well-connected phone does not answer every question about a mobile journey.
Include the people running the service
Ask who deals with a confused rider, an unavailable driver or a disputed trip. Their needs may require administrative tools and access to relevant ride information. Define that responsibility before launch rather than treating it as a dashboard to add later.
- What can each participant do at each step?
- Which changes need to reach another person?
- What does the user see during a connection problem?
- How does the operation investigate an exception?
- Which journeys must work before the first release?
The product scope behind our mobility work
Our ride-hailing work spans passenger and driver applications, a backend and operational administration, alongside a dedicated notification service. The work includes React Native applications, a real-time NestJS backend, tracking and fare-tier capabilities.
This is the experience behind the role-by-role planning approach above. An active ride is represented across applications and the systems serving them; evaluating one screen cannot establish that the complete journey works. The case study connects those responsibilities to the product scope, and the location guide examines one difficult stream within it.
Common questions
Should the first version include an operations tool?
Identify who will handle exceptions and what information they need. The tool can be focused, but the responsibility needs a workable path from the first release.
Is a working map enough for a first release?
A map demonstrates one capability. A releasable service also needs the agreed passenger and driver journeys, the operational process and handling for the exceptions included in its scope.