A rider opens a ride-hailing product because they need to make a decision in the physical world. Can I get a ride? How long might it take? What will I need to pay? Has a driver been found? Where should I wait?
Each answer depends on a marketplace that is changing while the rider looks at the screen. Driver availability moves. Road conditions change. Location signals vary. Messages can arrive late. The product cannot remove that uncertainty, but it can decide whether to explain it well.
Naka’s rider product is being designed around useful certainty: show what the platform knows, distinguish it from what the platform estimates, and make changes visible when the underlying situation changes.
Make the request reviewable
Before a request is placed, a rider should be able to review the information that will shape it. Pickup and destination details should be recognisable. Relevant pricing information and terms should appear before confirmation. If a location is ambiguous, the product should ask for clarification rather than quietly choose.
The goal is not to add a confirmation step to every action. It is to make consequential choices deliberate and correctable.
This matters because a small misunderstanding at the start can become a larger coordination problem later. A pickup point on the wrong side of a divided road, for example, affects the rider, the driver, and the marketplace systems trying to bring them together.
Treat an estimate as an estimate
Pickup and arrival times are predictions, not appointments. They are constructed from location, distance, movement, road context, marketplace state, and assumptions about what will happen next.
The interface should not imply a level of precision that the system cannot support. It should also avoid changing an estimate without helping the rider understand that the situation has changed. The right presentation may differ by context, but the principle is consistent: precision is only useful when it is supported by the signal behind it.
The same discipline applies to availability and price. Naka will publish actual product behaviour and commercial terms when they are final. Until then, we will not use invented screens or figures to make the experience appear complete.
Keep ride state coherent
A rider should be able to tell whether the platform is searching, whether a driver has been matched, whether pickup is in progress, and whether a ride is active or complete.
That visible state has to agree with the underlying marketplace and ride systems. If a rider and driver receive conflicting information about a match or cancellation, interface clarity alone cannot solve the problem.
This is why rider experience and infrastructure design belong in the same conversation. The product can only explain state that the platform models and maintains reliably.
Design for the moment the normal flow breaks
Not every ride follows the intended sequence. A rider may be unable to find the pickup point. A driver may be delayed. A network connection may disappear. Information may look wrong.
In those moments, the product should preserve useful context and provide a route to help appropriate to the state of the ride. It should not require the rider to reconstruct information the platform already has, and it should protect sensitive information from unnecessary access.
Support and safety are therefore not destinations at the edge of the app. They are parts of the journey model.
Clarity is an operating standard
Useful certainty does not mean promising that every ride will happen exactly as first estimated. It means being disciplined about what the platform says, updating that account when conditions change, and giving the rider enough context to decide what to do next.
That standard reaches beyond interface copy. It influences the data the platform keeps, the events it treats as authoritative, the reliability work it prioritises, and the tools available to operations and support.
Naka is still building these systems. Our measure for the rider product is not whether it can make a moving marketplace look perfectly predictable. It is whether it can make that marketplace understandable without pretending away the uncertainty.