Performance & scalability
Long sync and load times caused by enormous configurable forms from the desktop CRM and immense photo upload times were wasting drivers' time and crashing the app, often in low-bandwidth areas.
Increasing same-day tows by 28% through mobile redesign
Redesigning the mobile & dispatcher apps to win for the client, dispatcher, & driver
Executive summary
Omadi's mobile and dispatch apps were both failing the business. Drivers were burning minutes on side-of-the-road sync errors, minutes spent exposed in a job where more drivers die each year than all other first responders combined, and dispatchers were missing the same-day-tow SLA that anchored the company's largest client contract. Prioritizing one over the other was unacceptable, so I rejected the perceived trade-off and found a single solution that solved both problems.
I led in-field research that uncovered a project-saving insight: the "Is Towable" field the auto-dispatch algorithm depended on was almost always wrong, because the call center marking it never saw the car. We spent the rest of the visits learning what actually made a vehicle towable, then redesigned both apps around what we learned. The mobile app collapsed 80+ inventory fields into 6, and the dispatcher app reframed auto-dispatch as a tool that helped dispatchers rather than replaced them.
Project role
Founding UX Manager
Time frame
2018
Company size
50
Leadership Scope
3
Company stage
Startup
Industry
Towing Management (SaaS)
Design Operations
Experience Design
Mentoring
Strategic Partnership
User Research
28%
Increase in Same-Day Tows
12X
Reduction in Task Completion
15X
Reduction in Driver Idle Time
54%
Reduction in Roadside Injuries among Client Drivers
Problem & Stakes
I inherited a mobile app that was slowing drivers down on the side of the road
Omadi builds B2B software for the providers and purchasers of towing services. Its bread and butter was a legacy web platform and a native mobile app that helped towing companies run their day-to-day operations. Under a new executive team, the company was also going through a transition: from towing management software to a marketplace for all towing and roadside assistance services. To get there we needed to support dispatching a batch of jobs at a time, not just the real-time requests most towing software is designed around.
The apps had 3 problems that had become impossible to ignore, and the marketplace strategy made every one of them worse.
One thing a lot of people don't know about towing is that more tow truck drivers die and are injured every year than all other first responders put together. When you're trying to load a heavy vehicle onto a truck with cars whizzing by at 70 miles an hour and a customer who is hurt or angry looking over your shoulder, the last thing you want to be doing is trying to get an unresponsive phone to sync. As we improved usability and performance, we were helping more towers get home to their families each night.
The task
The main task was to help tow truck drivers complete more same-day tows. Drivers get paid on commission, and towing companies win jobs from large clients based on how quick and efficient they are. New partnership deals with auto salvage and auto insurance enterprises required batch processing and routing of towing jobs, so the same work had to make auto-dispatch possible. To do any of that we had to solve the performance and usability problems in the app. As we did discovery, 3 pain points came into focus:
- 1.Sync & performance issuesLong sync and load times caused by enormous configurable forms and immense photo upload times were causing not only wasted time but frequent app crashes.
- 2.Extreme configurabilityWhile initially viewed as a strength, the extreme configurability of the platform was leading to inconsistency and massive forms that then had to be synced to the mobile app, even though a driver needed about 7% of the fields being synced.
- 3.Usability problemsHaving never had a UX team before I started, Omadi's apps had glaring usability issues all over: hunting through immense forms to find relevant information, a laborious photo capture and upload process, and 7 clicks to perform the most common action.
There was no way to "fix" our mobile app without revamping it.
Strategic Approach
Solving the problem, not just implementing the requested solution
The company had always seen intense customization as a strength. Customer feedback showed it was a weakness.
In order to solve some of the deep-rooted problems we were experiencing, I had to step up and help guide the business strategy. That meant getting to know our users and the business, and then helping shift the company from a "we help everyone do whatever they want" mindset to a "we are the thought leaders in the towing industry, let us help you increase your revenue and be more efficient" mindset. Through contextual inquiry and observation, user interviews, information-architecture mapping, and mapping out the driver's flows, I was able to show business leaders that intense customization was a weakness, not a strength.
The approach rested on 3 things: standardize around what a driver actually needs, give drivers the information they need when they need it and get everything else out of the way, and work lean enough to put a working app in drivers' hands in weeks, not months.
Each of the 3 came out of the groundwork below. We started from proto personas and jobs to be done on a whiteboard, wrote our assumptions as hypotheses, and then went out to validate them with drivers and dispatchers in the field. From there I mapped the driver's flow across job types and cut the form down to what a driver actually touches, and the team and I built the first prototype in parallel with the research, showing it in Design Trust every week and in the field as often as we could.
Execution & Alignment
Flexibility & research-informed decision making
Job types changed under us, leadership reacted to the market, and we kept learning from research. Flexibility, patience, and understanding the business priorities were the job.
Flexibility through 4 pivots
I was initially assigned to Motor Club tows, the most complex job type, on the theory that if we could make that simple everything else would fit. After research, discovery, design, and 6 weeks building a functional prototype with development, I was asked to pivot completely to a job type the company had never supported, battery installations, because a partnership deal had been signed. When that app was ready to release, we pivoted again: the partner put the entire battery program on indefinite hold during a leadership reorganization on their side. When we got back to towing, we pivoted from Motor Club to General and Police tows, since those were what most of our customers needed and management wanted customers off the legacy app as soon as possible.
Through each pivot we built on the learnings and iterations of the previous version. What saved me from a design perspective was that from the first discovery sessions I had been considering multiple job types when designing the IA and flows, since the eventual goal was one app for all of them. These pivots caused us to dig deep and ultimately deliver the best product for the business, our clients, and all our users.
How research informed key decisions
Outcomes & Downstream Impact
Getting drivers off the road faster
The app got faster and more reliable, drivers spent less of each job waiting on it, and fewer of them were hurt on the road.
28%
Increase in Same-Day Tows
12X
Reduction in Task Completion
15X
Reduction in Driver Idle Time
54%
Reduction in Roadside Injuries among Client Drivers
For our salvage partner, same-day tows went up 28% within 4 months. Task completion time in the app came down 12X, and driver idle time, the minutes a commission-paid driver spends waiting on the app instead of earning, came down 15X once it stopped syncing the entire CRM form and uploading full-size photos one at a time. We combined all towing types into 1 dashboard, standardized the flow, and surfaced the information drivers needed when they needed it, and got everything else out of their way. (I did the UI design as well as the UX on this one.)
The inventory pushback alone took the pickup form from 87 fields to 13, about 4.5 minutes saved per vehicle, and it kept our partner's drivers on the SLAs their companies owed the insurers.
Getting more drivers home
The result I'm proudest of from this project, and from my career, is that roadside injuries among our client's drivers fell 54%. Towing is a job where more drivers die every year than all other first responders put together, and the injuries happen in the minutes the old app was wasting: standing on the road with traffic going by at 70, trying to get a phone to sync or working through an 80-field inventory before the car could be loaded.
We didn't set out to design a safety feature; the goal was to help drivers complete tows faster. But every minute we took out of the app was a minute a driver wasn't standing on the road: the form went from 87 fields to 13, photos no longer uploaded one at a time, and the most common action no longer took 7 taps. When someone asks me for the outcome I'm most proud of, this is the one I use.
What changed in how the team worked
One of my biggest contributions to Omadi in general was the thought leadership I brought around Lean UX principles and outcome-based design and development. I evangelized the principles and started using the terminology, but mostly I started working in a lean way and the product managers and engineers followed. It helped that my boss, the Director of Product Management, was fully supportive from the beginning. Most of the people I worked with had never worked this way before; once I took the lead and just started working collaboratively, they followed and ended up loving it.
Design Trust, the open design review, gave the whole company a way to shape in-progress work. Engineers came on research visits, and one of them saved the project because of it. Support, training, and marketing became regular members of the team. None of this works without a product manager and developers willing to work this way, and I was lucky to have them.
Before
A different workflow per tow type, the entire CRM form synced to the phone, one photo upload at a time with no in-app camera, 7 taps for the most common action, and frequent outages. "We help you run your business however you want."
After
1 dashboard and 1 flow for every job type, the ~7% of fields a driver actually touches, an in-app camera and viewer, photos as evidence instead of an 80-field inventory, and a team that whiteboarded, built, and tested together week to week. "Let us help you be more efficient."
Reflections
Reflections on the work
What made a difference
- •Taking the developer lead into the field. I had no idea how much of the auto-dispatch algorithm depended on one field. Our developer lead did, and he only caught it because he was in the room when a dispatcher explained how she decided. Even doing the research, if we hadn't made a point of taking him with us, we might have missed it and the project would have failed.
- •Solving the problem instead of building the request. When a leader or partner asks you to build something, what they're really asking, most of the time, is for you to solve a problem they or their customers have. The partner asked for 80 fields, but the problem they needed solved was proving the car hadn't been damaged in transit. Taking the time to understand the goal and reach it in a way that makes users' lives better is the essence of UX design.
- •Designing for all the job types when I was only assigned one. The 4 pivots would have thrown away most of the work if the IA and flows had been built for Motor Club tows alone. Because I had kept every job type in view from the first discovery sessions, each pivot built on the last version instead of replacing it.
What I'd do differently
- •Going straight to the CEO, much earlier. Getting the funding and time for onsite research was rocky and slow, and it was slow because I was trying to work up the chain instead of going to the source. It changed the day one of my designers met with the CEO directly. She worked on a different product than the mobile app, but she explained what we were trying to do and the ideas she had, and it unlocked research for all of us. He was so impressed with her and with the value of the approach that he had the two of us present our work to the whole company, told everyone who wanted to go learn from customers to go, and even previewed unannounced strategic initiatives with her to get her thoughts. What I should have recognized is that he spent about 75% of his time out meeting customers. This was never someone who needed convincing about understanding users. As the UX manager, I should have taken her approach far earlier, and I have in every role since. It has made a real difference in my career.