An app that gets out of the way

Open almost any ride-hailing app and you already know where everything is. A map fills the screen and a search bar floats over it. A strip of offers competes with the thing you came to do, and a spinner turns while you wait. But familiar is not the same as easy. Most of those patterns have been carried from one app to the next, and it is fair to ask whether they help. Some leave small frustrations that repeat on every trip: the price you have to scroll to find, the list that shows the same place twice, the estimate that turns out not to be true.

So we are redesigning SnappCab around a single belief: an app for getting somewhere should get out of your way. Not look emptier, not do less — get out of your way. Here is how that belief has shaped the work so far.

One question, asked of everything

The redesign did not begin with a new visual style. It began with a question we ask of every screen, control and sentence: does this actually make the journey easier? Not “do other apps have this”, and not “will this look modern in a screenshot”. If an element cannot answer that question, it does not earn its place.

The test also changes how the things that stay behave. Take the wait between requesting a ride and being matched — the most anxious moment in the app. The convention is a spinner, and to someone standing alone at a pickup point a spinner says “hurry up”. Our screen shows a slow pulse instead, a plain count of how long you have been waiting, and a clear line on what is happening and what the ride will cost. Certainty is what settles someone who is waiting.

It also means refusing to decorate with information we do not have. That screen could easily show a progression — locating, matching, found — driven by a timer. It does not, because at that moment the system knows one true fact: the request is out. A progress bar marching forward on the clock would be a small, comforting lie, and small lies are what make people stop trusting an app.

Simplicity is deciding what not to show

A simple interface is not what is left when there is little to do. SnappCab handles rides, parcels, intercity bookings, scheduled trips and safety tools. The simplicity has to be designed on top of all that, mostly by deciding what to leave out.

Some of those decisions are small. Your recent places used to show “HSR Layout” directly above “HSR Layout, Bengaluru, Karnataka, India” — one destination, two rows, and no way to tell why both were there. Now the list folds them into one and keeps the fuller name. Air-conditioning used to be a preference toggle; it is now simply a tier you choose, and both the price and the car that is sent follow from that choice. A fresh search starts from how you usually ride, with the vehicle you last picked remembered separately for rides and parcels, so sending a parcel never changes the ride you usually book. And we stopped asking senders to guess a weight; a parcel is priced by the vehicle that carries it.

Others are about where things sit, and when. The fare, trip time and distance are pinned beside the Book button, so the number you commit on is visible without dragging anything up to find it. And an arrival estimate only appears once the captain’s own location has reached us. Before that, the only number available covers the whole trip. Printing it would tell you a captain two hundred metres away is eighteen minutes out. We would rather show nothing.

Nothing here is visually dramatic, and that is the point. Modern does not mean more motion, more cards and more colour. It means each thing on the screen is doing a job. And the job depends on who is holding the phone.

Designed for the person actually holding the phone

SnappCab is used by someone booking in the seconds before a meeting ends, someone in a hurry with a bag in one hand, someone who finds busy screens tiring, someone with low vision — often in a moving vehicle. We design for those moments, not for the screenshot.

That shows up in unglamorous places. On the booking map, the button that finds your current location sits apart from the other map controls, the lowest of the three. It is the one people reach for while the car is moving, and it belongs where a thumb already is. The map you use to pick a spot follows the same pattern, with its location button on its own beneath the other controls, so you learn it once. Rows and icon buttons never drop below 44 pixels, however tightly a screen is packed; a denser layout can tighten spacing and type, never the size of what you tap.

While you wait, you can also raise or lower the fare you are offering. The slider for it has a minus and plus pair beside it that sets the same values. A drag is hard with cold hands, with an accessibility switch or on a small screen in the dark.

There is also Simple mode, one setting that makes the whole app’s text larger. It respects the size you already chose for your phone and lets it go larger than the app normally allows. The app says it helps in bright sun and on cracked screens too, because we did not want an accessibility setting to read as if it were for someone else.

Accessibility as structure, not a layer on top

The difference between accessibility built in and accessibility added later is whether the rules live in the building blocks or in someone’s memory. We put them in the building blocks: the shared rows, buttons and maps that every screen is made from.

A map is the clearest example. To a screen reader, an embedded map is close to silent: it does not say where you are being picked up, where you are going, or what stage the trip is in. So our rule is that every map has a spoken description. Before you choose a destination, the booking map tells you your pickup and how many cabs are nearby; once you have one, it names both ends and says plainly that nothing is booked yet. And a description that spoke on every GPS update would drown out everything else, so it speaks when the meaning changes, not every time a number moves.

Nothing relies on colour alone, and if your phone is set to reduce motion — the setting for people who find animation distracting or unsettling — the searching pulse simply stops.

Most of what gets filed under accessibility is simply what makes an app easier for everyone: clear order, readable type, controls that behave the same way twice, and fewer things to hold in your head.

Features that answer a real frustration

Building less is not the goal. We do not add features for the sake of more; we build the ones that remove a problem people keep running into.

Some are invisible until you go looking. On Android, an app that asks for two permissions at once can have one silently dropped and recorded as refused. That is one real reason behind the familiar complaint that an app “sometimes doesn’t ask for location”. SnappCab queues its location and notification requests so each gets its own dialog and its own real answer. When location is unavailable, the message names the cause, what it means for you and what to do next. It also tells apart three different reasons, because each is fixed in a different place.

Some are about fear rather than friction. When a booking fails, most people first wonder whether they were charged, so the message says: “No rides available right now. Nothing was charged.” Trip updates are a separate setting from marketing, so you never have to choose between hearing your captain has arrived and being advertised at. And once you share a live trip, the button becomes Stop sharing, and it does not tell you sharing is off while a link is still live.

Not finished, on purpose

There are gaps we know about. A map’s spoken description should be able to read out the route as steps, not just where it starts and ends. Our routing data does not include turn-by-turn directions yet, so we leave that part out rather than guess at it.

Nor is the rest of it solved. A redesign built on one question has no end date: every new feature, screen and sentence has to answer it again. We will keep learning from how people actually use SnappCab, and let that, not convention, decide what changes next.

The price you had to hunt for, the place listed twice, the estimate that was not true: none of them was fixed by adding something. Each was fixed by taking something away, or by putting it where it belongs.

We are not trying to build a more complicated app with more things in it. We are trying to build a better one, by making every part of it more useful — and then getting out of the way.