DDS Wireless · 2013 – 2019

DDS: on-premise to SaaS

From screens to the whole ecosystem.

DDS sold on-premise software to transportation service providers, drivers and passengers. Moving it to SaaS meant rebuilding legacy applications from the ground up — but the harder problem was underneath them, in business processes that had been written for a different way of selling software.

Ecosystem map titled Today. DDS sits at the center, feeding taxi and limo companies and paratransit companies, each containing dispatchers and drivers, who in turn serve a passenger. Four concentric rings surround them: core value proposition, then solution providers, service partners, embedded technology providers, and regulatory bodies at the outside. Each element is colored taxi-specific, paratransit-specific or shared.
The ecosystem as it was. The color coding is the point: every element that is only one color is a place where two halves of the same company had built the same thing twice.
Role
Owned the user experience of every software product at DDS
Team
Product management, engineering, executive stakeholders
Modes
Transit, paratransit, taxi & limo, ridesharing
Users
Passengers, drivers, dispatchers, service providers

Context

DDS provided total solutions for transportation service providers, drivers and passengers, across devices and platforms — dispatch, scheduling, routing, vehicle terminals, booking. Shifting business objectives pushed the company off traditional on-premise software and onto SaaS.

Problem

Everyone framed this as an engineering project: rewrite the legacy applications. The rewrite was real, but it was the smaller half. The business processes had to move too — how the company sold, deployed, supported and versioned its software had all been shaped by shipping a product that then sat on somebody else’s server.

I owned the user experience of every software product in the company, so the whole surface of that change landed on my desk at once. It was also the only chance any of us would get to escape decisions that had been locked into the legacy applications years earlier, so I chose to treat it as a design problem from the start rather than a porting exercise.

Research: four modes, three kinds of user

It started with the users, and there were more of them than anyone had written down. I ran a literature review and competitive intelligence across all four transportation modes we served — transit, paratransit, taxi and limo, and ridesharing — and built a profile of each of the three groups in each mode.

  • Passengers. Demographics, including age, income, education, car ownership, whether they lived urban, suburban or rural, and what constraints or disabilities they had. Travel characteristics: usual trip purpose, frequency, distance, how they got to and from the vehicle, what they would use instead. Then what they felt good about and what they felt bad about.
  • Drivers. Demographics, the positives, the negatives, and — separately — what mattered most to them, which is not the same list as what they complained about.
  • Service providers. Fleet size, public or private, years in operation, urban or rural. Which business and operating strategies had worked, which had failed, and what they were worried about.

A literature review is the cheap instrument, and it was the right one for this stage: I needed archetypes and general needs to plan against, not decisions. The expensive instruments came later, against specific designs — user interviews, customer surveys, analysis of the support logs, and contextual inquiry.

Writing down what the customer is actually trying to do

Out of the research I pushed the team to do something that sounds trivial and was not: state, in plain words, what our customers were trying to achieve — and then what would actually move each of those things. We ran it as a group exercise and compressed the result until it fitted on one page.

  • Moving people. Fewer rejected trips. Less waiting and less traveling. Lower cost. More safety. More comfort.
  • Maximizing profit for transportation partners. More trips fulfilled. Better efficiency, which mostly means less dead heading. More revenue, less capital cost, less operating cost.
  • Best use of system resources. Higher vehicle occupancy. Less driver idle time. More collaboration between transportation partners. Higher ridership. A smaller carbon footprint.

A fourth goal sat underneath those three rather than beside them: motivated and efficient drivers. It needed no enablers of its own — fewer rejected trips, less dead heading, less idle time, and the driver’s day is already better. If the first three are working, the fourth is what that looks like from the cab.

One page, printable, and on the wall — so that when a business or design decision came up that would affect a customer, we could look at it instead of arguing from memory.

Two ecosystem maps

Good SaaS experience is not modern interface, or current technology, or sound business strategy. It is those things agreeing with each other. So with the product managers and stakeholders I mapped the ecosystem twice: the one we had, and the one the company’s stated vision implied.

Ecosystem map titled Today, drawn as concentric rings. Most elements are colored as either taxi-specific or paratransit-specific, and the two company types run as separate paths out from the center. Ecosystem map titled Future, laid out in the same concentric rings as the Today map. Far more of the elements are colored as shared rather than taxi-specific or paratransit-specific, and the two company types sit inside a single core rather than as separate paths.
Today above, the company’s stated vision below, drawn in the same rings so the difference is a difference in color rather than in layout. The SaaS argument makes itself — the future is mostly the gray of shared components.

This turned out to be the highest-leverage artifact of the project. Not because either map was surprising to any individual, but because nobody had ever been shown both at once. It gave everyone a big picture to place their own decision inside, and it made the consequences of a decision arguable rather than a matter of seniority.

Three journeys and their touchpoints

Then I mapped the journey and the experience our users were actually having: dispatcher, driver, passenger. Each map carried the UX touchpoints alongside it, so a person reading it could see not just what the user went through but which piece of our software was in front of them at the time.

The three maps do not have the same shape, and that turned out to be the finding. The passenger’s runs pre-booking, booking, waiting, riding, post-ride — a trip. The dispatcher’s and the driver’s both run start shift, during shift, end shift — a day. Two of our three users do not experience our software as a journey with an end. They experience it as eight hours.

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.
Empathy is the stated reason for a journey map; the working reason is that it gives a room full of people the same object to point at. The bottom row is the one that gets used — every opportunity on it is a candidate feature with a reason already attached.
A customer journey map for a taxi dispatcher and administrator. Start shift, during shift, end shift. The during-shift column holds four clusters of activity drawn as circles of sub-tasks: fulfill trip requests, maintain functioning fleet and dispatch, ensure real-time system performance, and review and improve fleet performance. Beneath run rows for thinking, feeling and opportunities.
First box, top left: get information from dispatchers for the previous shift — in-person, sticky notes, bulletin board. The handover between two shifts of the same job was running on paper, next to software we sold as a dispatch system.

The feeling row on the dispatcher map is where the interface got its brief. Going through the data grid is tiring and slow. I hope data can be better visualised. Going through the map requires much focus and attention to detail, and things can be overlooked when markers are overlapped or lack contrast. A dispatcher describing a contrast failure, unprompted, without the vocabulary for it.

A customer journey map for a taxi driver. Start shift, during shift, end shift. During the shift, three clusters: get trips — checking zones and stands, trip distribution, driving in busy zones, waiting at stands, bidding on trips; fulfill trip requests, drawn as a loop from receiving a request through pickup, destination, payment and post-trip follow-up; and take a break. Rows beneath for thinking, feeling and opportunities.
The driver’s thinking row is entirely economic. Which stand has the shortest wait time? Is it worth the penalty to reject this trip? Another driver who came here after me got the trip before I did — why? That last one is not a feature request but a question about whether the dispatch algorithm is fair, and no screen we shipped answered it.

Deciding what the SaaS product would contain

Consolidation was the opportunity hiding inside the migration. I compared every existing product and built an inventory of every feature and function across all of them. Set that against the user goals and the journey maps and three categories fall out on their own: what is missing, what exists but is inadequate, and what is redundant or insignificant.

Which gave product management three questions it could actually answer. What is essential to the core experience and belongs in the MVP? What adds real value and can wait for a later release? And what adds little or nothing, and should be removed rather than ported?

The inventory was laborious and I would do it again. Building it meant a long conversation with every product manager in the company about their own product, which is the fastest education available and is not obtainable any other way.

What it produced

The feature comparison and the priority charts gave product management solid ground for the SaaS roadmap — the document that then coordinated what everyone in the organization built, and in what order, to deliver the SaaS product on time.

Design work that ends in a roadmap rather than a screen is easy to undervalue. This one decided which screens would exist at all.

Tradeoffs I made

Literature review first, real users later.

Secondary research is a weaker source than talking to someone, and I opened a project of this size on it.

What I gave up: primary evidence at the start. What I got: coverage. Four transport modes and three user groups is twelve populations. Interviewing all of them before we knew what we were building would have spent the year on research and arrived at the same archetypes.

A full feature inventory instead of a sample.

Weeks of comparison work, and no visible design output at the end of it.

What I gave up: speed, and looking productive. What I got: the authority to say a feature should be dropped. Nobody removes anything from a migration on an opinion.

What I’d change

I built the customer goals model with the team and then let it live on a wall. It should have been wired into how decisions were recorded — a field on the ticket, a line in the spec — so that a choice had to name the goal it served. Artifacts that people have to remember to consult are artifacts that stop being consulted, and this one was good enough to deserve better.