DDS Wireless · Mobile App

Zoro app

Making a fragmented taxi network feel like one service.

Zoro is a multi-company taxi booking app. Passengers book regulated taxis on their mobile devices - not from a single service provider, but from the combined fleets of service providers in the network.

Fifteen labeled high-fidelity Android screens on a pale gray board, in three rows. The first row runs map, booking pickup, booking pickup and drop-off, driver notes, and service providers. The second runs travel needs, payment, a credit-card picker, tracking while looking for a cab, and tracking a cab on its way. The third runs a delayed cab, an incoming message, a message thread with the driver, a voice call, and the cab arrived. Green is the action color throughout.
Role
Lead/solo designer - from research to design
Platform
Mobile
Focus
End-to-end UX, visual and motion design
Published on
Google Play, App Store

Context

At the time, before ride-hailing apps had become mainstream, DDS had been providing transportation technology to companies, drivers, and passengers for decades.

Unlike the passenger apps bundled into DDS's enterprise solutions, Zoro was a consumer app that connected passengers directly to a network of thousands of regulated taxis across participating service providers. Passengers could get fare estimates, communicate with drivers, track trips, book immediately or in advance, and pay seamlessly in the app.

Problem

Taxi service was inherently fragmented: each service provider had its own fleet, operating model, and booking process. Unlike emerging ride-hailing and ridesharing services, the taxi industry was also highly regulated, with established rules governing fares, licensing, dispatch, and operations. There was no simple way for a passenger to discover, book, track, and pay for a taxi across the entire network.

Zoro's goal was to make that complexity invisible. And this was before ride-hailing had become mainstream. We weren't simply adapting an established interaction model; we had to establish what a mobile taxi-booking experience should be while working within the realities of a regulated industry.

The challenge was to create a consumer experience that made thousands of taxis across independent service providers feel like one seamless, trustworthy service-without losing the operational and regulatory requirements that made the taxi system work.

Approach

Understand the users

Who they are

A user centered design process starts with understanding the users of the app: Who the primary users? Why will they use this app? What do they need to accomplish using the app? In what environment/context will they be doing it?

Earlier literature review and competitive research had already given us a picture of the taxi-app user, such as:

  • demographics (e.g., age, gender, income, education, urban/suburban/rural, car ownership)
  • trip characteristics (e.g., common trip purpose, trip frequency, typical length/distance of the ride, access/egress mode, alternative transportation)

DDS already ran the passenger apps inside our enterprise deployments, so we looked at their data to better understand the trip characteristics, such as:

  • how often they need a ride ASAP
  • how often they need to book a ride for the future (and typically how far ahead)
  • how often a return trip gets booked
  • which payment methods they use, and how often
  • common destinations
  • common tipping preferences

Personas

With a better understanding of our users, I created personas to help the team focus. Rather than attempting to represent every user or capture every possible need, the personas focused on the most important user groups and the needs most critical to the product experience.

An example persona:

A persona sheet for Charlie Gray, shown with a photograph of a man in a shirt and tie checking his phone on a city street. A left column lists age 32, marketing specialist, income 65K, university educated, Vancouver, single, and a personality described as organized, upbeat, adventurous and fun. Three sections on the right cover his life, his work and his relationship with technology.
The useful line is in the Work section, not the demographics: it's always important to dress professionally and arrive on time. That is the whole product requirement - a late cab is not an inconvenience to Charlie, it is a professional failure.

Passenger jobs to be done

Based on the research and personas, I distilled the passenger experience into four core jobs to be done:

  • Book a ride (immediate or future) quickly, with an accurate time and fare estimate, and a choice of service provider, vehicle and payment method.
  • Track the ride with real-time vehicle location, and two-way communication between passenger and driver.
  • Have a smooth and frictionless ride with guided boarding on the right taxi, real-time route tracking, and optional automatic in-app payments.
  • Follow up afterwards with lost and found, trip review, and driver rating.

Passenger journey

Then I examined the UX touchpoints and mapped the journey the passenger was actually having - the channels available to them set against the stages of the trip, and the experience running underneath.

A customer journey map for a taxi passenger. Five stages - pre-booking, booking, waiting, riding, post-ride - subdivided into eight phases from planning the trip through to reflecting, rating and sharing. Four rows run beneath: illustrated activities, the questions the passenger is thinking, what they are feeling, and the opportunities each moment opens.
Five stages, eight phases, four rows. The bottom row is the one that gets used - every opportunity on it is a candidate feature that arrives with its reason already attached.

UX touchpoints

A touchpoint grid for the taxi passenger. Rows for website, call center, IVR, mobile app, in-person and email; columns for the five journey stages. The mobile app row is full across all five stages; the IVR row holds only checking trip status and getting an ETA.
The IVR row covers two tasks in one stage; the mobile app row runs end to end. The grid does not argue that the app should exist - it shows how much of the journey has nowhere else to go.

Ideate, prototype, test - and again

User flow

Together with the product managers and dev lead, we first diverged to brainstorm as many solutions as possible. Then we converged and worked out the flow of the best solution:

A flow diagram titled Book a trip. It opens by asking whether the rider has a preferred local company, then mirrors the same path twice - once for the local default, once for a national one - through searching for a car, checking availability, choosing among available companies, specifying a destination, seeing a fare estimate and confirming. A legend distinguishes four node types: decision, information presented by the system, user action and system process. Every unavailable-car branch routes to a box marked user feedback: explanations and suggestions.
Two mirrored halves, local default and national default - that fork is the whole multi-operator problem in one diagram. And no branch dead-ends: every no lands on explanations & suggestions rather than on nothing.

Wireframes and early prototypes

Then into the design tools, for wireframes and early prototypes to put in front of people.

Twenty-four grayscale phone wireframes arranged in four rows of six. The first row is a five-step registration flow - personal info, verification code, payment method, default tip - ending on a map screen headed book a trip. The second row covers booking summary, pickup location by search and by contact list, pickup date and time, a message for the driver, and a preferred-companies screen listing three cab companies with option badges. The third row runs active bookings, trip detail, two tracking screens, a completed trip and a receipt. The fourth row covers profile, payment and managing preferred companies by country, province and city.

High-fidelity mock-ups

We tested the prototype with real users, then iterated-ideate, prototype, test again-until the experience was ready to move toward MVP.

The next step was to bring the experience to life visually. A mood board established the visual direction, while high-fidelity mock-ups refined the color, layout, typography, iconography, and overall visual language.

I developed the screens at both levels of detail:

  • close-up explorations of individual UI elements
  • a complete screen flow to ensure the visual system held together across the entire experience

Fifteen labeled high-fidelity Android screens on a pale gray board, in three rows. The first row runs map, booking pickup, booking pickup and drop-off, driver notes, and service providers. The second runs travel needs, payment, a credit-card picker, tracking while looking for a cab, and tracking a cab on its way. The third runs a delayed cab, an incoming message, a message thread with the driver, a voice call, and the cab arrived. Green is the action color throughout.
A wall-sized screen flow, roughly a hundred screens connected by arrows. It begins at a DDS Wireless splash and an onboarding carousel, then forks into two labeled branches, new user and existing user, each with password recovery by email or by phone and a choice of adding a credit card at registration or later. Both converge on a side menu, below which a wide lower band covers booking, tracking, messaging the driver, rating a completed trip, trip history and account preferences. Two orange sticky notes annotate the diagram.

Craft the experience

Once the core flows were working, I turned my attention to the details that would make Zoro feel polished and intuitive, and delight users: the transitions between screens, the way information appeared and disappeared, and all the small visual details.

  • Motions: I explored animations with Principle and Framer, refining the motion parameters until it felt right, because even a small difference in timing or easing could change how an interaction felt. I chose Framer for production because it let me carry that level of precision into implementation: I could give developers the animation itself, including the CoffeeScript with its timings, easings, and spring values, rather than handing over a video and asking them to approximate it.

  • Illustrations and visual design: I created custom illustrations across the experience with carefully refined typography, iconography, color, and composition. I wanted every screen to feel intentional and carefully crafted, while being part of a cohesive whole experience.

Zoro - loading
Zoro - onboarding
Zoro - arrival

Test with users, and keep testing

Zoro launched on both Google Play and the App Store. For UX that is not the finish line, it is the point at which the feedback stops being hypothetical.

Alongside usability testing on specific aspects of the app, I ran UX benchmark testing to measure how users actually performed with it. Usability testing tells you what is wrong this week. Benchmarks tell you whether the next release was better than the last one, and whether the targets were met.

Outcome

  • One app, thousands of taxis. Passengers could book regulated taxis across all participating service providers through a single app.
  • A complete passenger experience. Booking, tracking, messaging, payment, and rating were brought together in one experience that worked across the network.
  • Continuous UX improvement. UX benchmark testing established a measurable baseline, allowing us to determine whether each release improved the experience and met its targets.