Loading…
BetterSuite is built for teams who see on-demand as a business — not a feature.
We redesigned our taxi driver app software for a phone mounted on the dashboard, with larger controls and in-app navigation. As part of our taxi dispatch platform, the driver app aims to make everyday trips easier to manage. The goal is to give drivers another reason to choose your service when competing apps are available.
A driver app has a different working environment from a passenger booking app. Picture the phone fixed to a dashboard, farther from the driver than a device held in the hand. The next trip action needs to stand out from the other details on the screen.
That starting point changes the design brief. We enlarge the main actions, increase the size of supporting controls and give important information more space. In the redesigned driving screens, the primary action is at least 72 logical pixels high, with supporting touch targets sized at 56.
Those dimensions are our implementation choices, not a driving-safety standard. The general rationale is supported by W3C’s guidance on larger touch targets: small targets are harder to aim at and can lead to unintended actions. Check that the main controls remain clear and distinct when the phone is mounted.
Landscape needs its own layout too. Turning a tall stack of cards sideways does not give the map enough room. In landscape, the home screen puts the trip card on the left and the map on the right. In portrait, cards float over the map.
On the pickup screen, this separation keeps the rider details and arrival control beside the route guidance. The driver does not have to open another card to find the next trip action. Review both orientations with the phone mounted in a parked vehicle, including the offer, pickup, active trip and settlement screens.
Not every action should use the same gesture. Accepting a time-limited offer and ending a trip have different consequences, so we treat them differently.
We keep accept and reject as taps. Arrival, trip start and trip completion use a hold-to-confirm control. The driver holds the control before the app moves to the next trip stage.
A control like this needs visible feedback. Our button shows the hold progressing and confirms when it completes. Releasing early does not advance the trip, and the action’s label says what will happen.
A hold adds effort to an action. We choose that effort for trip transitions, where an accidental change would interrupt the workflow. We do not apply it to every button simply to make the interface consistent.
Look at each action’s consequence when you review a driver app. Decide which needs an immediate response and which deserves deliberate confirmation. A screen can look tidy while still making those two categories too easy to confuse.
The route belongs alongside the job it serves. We add in-app guidance so the driver can see directions within the same workflow as the pickup and trip controls.
The app shows the directions, while the routing provider supplies the route. Our hosted routing engine serves cities where we have enabled coverage. Google supplies routes elsewhere and handles requests our engine cannot serve.
We operate our own routing and traffic infrastructure. Drivers’ actual travel speeds feed traffic profiles, which inform ETA calculations where enough observations are available. Running this infrastructure means maintaining the routing service and the pipeline that turns driver movement into usable traffic data. We explain the work and the cost and coverage decisions in our article on Google Maps API costs and our geo engine.
When you evaluate taxi driver app software, check that drivers can see the route and their next trip action together. Ask for a demonstration on your own pickup and trip routes, including what happens when the driver needs a new route. A polished demo in another city does not establish suitability for your service area.
On supported phones, we add sound cues for incoming requests and spoken feedback for trip progress when a voice is available for the app’s language. These give the app ways to communicate beyond a visual change on the screen. Sound supports the workflow without becoming the only way to understand its state.
Voice answering has a deliberately narrow role. On supported phones, drivers can opt in to say “accept” or “decline” while a ride offer is active. It requires the relevant permissions and device support for the app’s language; the visible buttons remain available.
We limit recognition to the live offer window. Once the offer disappears, that listening session ends. We also stop it when the app moves into the background.
An offer has a short response window and two clear answers. We keep voice answering for offers and use hold controls for arrival, trip start and completion. This limits the opportunities for cabin conversation to trigger an action, although recognition errors can still happen.
Before relying on voice answering, assess it in your drivers’ languages, cabin conditions and audio setups. The redesigned screens are live in our web app and iOS driver app; voice answering is a supported-phone feature, rather than a web capability.
The redesigned driver app always uses a dark appearance, including its supporting screens. We choose that consistency to avoid bright panels appearing between the main driving view and the next task, particularly during night work.
We have not measured an eye-strain benefit from this redesign. Review text size and contrast in daylight as well as at night. Check that route colours, labels and available actions remain clear in both conditions.
There is a conditional power benefit on OLED displays. Purdue’s research on dark-mode power use finds that savings depend on brightness and screen content. We do not claim a measured battery improvement for BetterTaxi.
Do not assume your app is the only one on a driver’s phone. Drivers may use competing services: Uber’s own driver FAQ says it does not restrict how many apps drivers use.
Our redesign addresses one part of that choice: the experience of doing the work. Available jobs, earnings and pickup distances matter too. A better interface cannot compensate for a platform that offers little worthwhile work.
Use a parked-vehicle review to assess taxi driver app software before making a feature list your deciding factor:
Record what becomes hard to read, an unintended transition or an unanswered offer. Use those observations to set priorities for driver app development with your provider or design team. If you compare usage or offer acceptance before and after a redesign, account for changes in demand and incentives.
We cannot establish a universal preference from our redesign. Embedded guidance keeps route information alongside trip controls, while an external navigation app may be familiar to a particular driver. Review that trade-off with the people using your platform rather than assuming one approach suits everyone.
Clear offers and straightforward controls aim to make decisions easier. When you evaluate taxi driver app software, account for earnings, available work and pickup distances. We are not claiming a measured improvement in acceptance rates.
Yes, a custom app is one option. The design brief should still cover mounted screens, trip transitions and the navigation workflow. Our guide to taxi app development discusses the broader build decision.
Explore the BetterTaxi driver app to review how these decisions fit into your operation.
