inDrive UI design & app screens

Designing an interface around a negotiation, not a fare

Every other ride-hailing app treats price as a fact handed down before you tap Confirm. inDrive inverts that: the ride request screen leads with an editable price field where the rider types the fare they want to pay, and the whole layout is built to make that number feel like the primary action rather than a hidden preference. Pickup and drop-off sit above it as compact rows, but the visual weight lands on the amount, often pre-seeded with a suggested figure the rider can nudge up or down before broadcasting the request to nearby drivers.

What makes this work as UI is restraint elsewhere. There is no surge multiplier, no dynamic-pricing explainer, no fine print about the estimate changing. The rider owns a single decision — how much — and inDrive keeps that decision uncluttered. For designers, it is a sharp case study in letting one input define the screen: the information hierarchy, the button copy, and the empty states all orbit the price the user is proposing.

The offer-and-counteroffer flow as a live marketplace

After a rider posts a fare, the screen becomes a scrolling list of incoming driver bids, each card showing the driver's photo, rating, car, distance away, and either an acceptance of the rider's price or a counteroffer. This is the app's signature moment, and it is essentially a real-time marketplace collapsed into a single feed. Cards arrive as drivers respond, sorted so the rider can weigh proximity against price without leaving the view, and a countoffer visibly differs from an acceptance so the rider always knows whether they are agreeing or still bargaining.

The interaction mechanics are quietly clever. Accepting a bid is one tap on a card; ignoring the rest requires nothing. There is no modal confirmation interrupting the flow, because the list itself is the decision surface. Contrast this with the standard hail-and-wait pattern, where a spinner hides all the supply from the user — inDrive exposes the whole set of offers and lets the rider act as the matcher, which is exactly why the screen has to make comparison effortless.

Built for the next billion, legible on modest hardware

inDrive's visual language is deliberately economical because its users are largely in emerging markets on entry-level Android devices and patchy connections. Type is large and high-contrast, touch targets are generous, and the palette leans on a bright accent green against plenty of neutral space so the screen stays readable in sunlight and on low-density displays. Iconography is literal rather than clever, which lowers the learning curve for first-time smartphone users.

The same pragmatism shows in how the app degrades. Driver cards render legibly before profile photos finish loading, and core actions stay reachable when the map tiles are still catching up. It is a useful reference for anyone designing for constrained contexts: the product assumes the network will disappoint and the device will be slow, and it designs the layout so the negotiation never stalls waiting for decoration to arrive.

Frequently asked questions