DDS Wireless · 2013 – 2019

Zoro app

A network, not a fleet.

Zoro is a multi-company taxi booking app. Passengers book regulated taxis from their phones — not from one operator, but from a network of thousands of cabs across every company that joined it.

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.
Fifteen screens, three phases: book, track, talk. The last five are all about the gap between a cab being assigned and a cab being found — which is where a taxi app is actually used.
Role
Research, interaction design, visual design, prototyping, benchmarking
Team
Product management, development lead, front-end developers
Product
Consumer booking app for regulated taxis
Users
Passengers, across every operator in the network
Shipped
Published on Google Play and the App Store

Context

DDS provided total solutions to transportation companies and their drivers and passengers. Most of the passenger apps we built were one component of an enterprise system sold to a single service provider. Zoro was not that. It was a consumer app, and it connected the passenger to a network of thousands of taxis from every company that had joined.

That one difference sets everything downstream. A single-operator app books a car. Zoro had to let a passenger get a fare estimate, communicate with the driver, track the trip, book ahead or immediately, and pay in-app — while choosing between companies that were competing for the same ride.

Research

A user-centered process starts with the same four questions, and they are worth writing down rather than assuming. Who are the primary users? Why will they use this? What are they trying to accomplish? And in what environment and context will they be doing it?

Earlier literature review and competitive research had already given us a picture of the taxi-app user: demographics — age, gender, income, education, urban, suburban or rural, car ownership — and trip characteristics — usual trip purpose, frequency, typical distance, how they got to and from the vehicle, and what they would use instead of us.

The part that could not be read off a report was behavior, and for that we had something better than a report. DDS already ran the passenger apps inside our enterprise deployments, so we looked at their data:

  • How often a rider needs a car immediately.
  • How often they book for the future — and typically how far ahead.
  • How often a return trip gets booked at the same time.
  • Which payment methods they use, and how often.
  • Where they actually go.
  • What they tip.

Empathize

With that understanding I created personas. The goal of a persona is not to represent every user or cover every need in the product — it is to hold the major needs of the most important groups still long enough for a team to design against them.

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.

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 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.
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.

Define

Understanding the user is not a deliverable. Articulating what you are going to fix is. We stated the primary problems plainly, and in the passenger’s order rather than the engineering one:

  • Get a ride quickly, with an accurate time and fare estimate. Immediately or in the future, with a choice of service provider, vehicle and payment method.
  • Track the ride. Real-time vehicle location, and two-way communication between passenger and driver.
  • Make the ride itself smooth and frictionless. Board the right cab, watch the route in real time, and let payment happen automatically if the rider wants it to.
  • Follow up afterwards. Lost and found, trip review, driver rating.

Ideate, prototype, test — and again

With the product managers and the development lead, we diverged first and brainstormed as many solutions as we could stand, then converged and worked out the flow of the best one.

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.

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.
At the bottom of the tracking screens, a three-digit code, set in the largest type on the page, over the words please give your driver this code. Boarding the right cab was on the problem list, and this is what solving it looks like at wireframe fidelity.

We tested the prototype with real users, then iterated — ideate, prototype, test again — until the design was ready to ship as the minimum viable product.

Only then did it become a visual problem. A mood board set the aesthetic, and high-fidelity mock-ups settled color, layout, typography and iconography.

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.
One of the two orange notes says booking failed — explain reasons. A screen flow that only draws the happy path is a screen flow that will be argued about later, in a bug ticket, by people with less context.

I also built interactive prototypes for the transitions and animations, in Principle and Framer. I preferred Framer, for a reason that has nothing to do with the design: it let me hand the developers the animation itself. I sent them the CoffeeScript — timings, easings, spring values — so they received the properties that made up the motion rather than a video to approximate. No guesswork.

The mock-ups, prototypes, screen flow, UI specifications and graphic assets went to the development team, and I stayed with them — making sure they had everything they needed from me and that the UI was implemented accurately.

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 — which is the only way to know that iteration is doing anything.