Onfleet Mobile Dispatch

To allow dispatchers to use Onfleet on the go, I led a soft redesign of Onfleet's sidebar, introducing new mobile view and touch screen interactions.

Context

Onfleet dispatching product was originally built exclusively for desktop use. But as our user base grew and the product matured, we saw an increased amount of requests regarding using Onfleet on mobile devices. I saw this as an opportunity to help our dispatchers and decided to take a closer look at the requests that were coming in.
 

Challenge

Designing a native mobile experience was the easiest option available to me, as a designer, however, we could not afford that. This project took place during a high growth period, so I had to be mindful not to spend too much of our product team's resources on proposed solutions. This case study focuses on my UX process within a lean product management system. It highlights my ability to design flexibly for a mature product withing the constraints that are common for a small (1-5) product team. The tricky position I’ve been put in due to resource demands, made for an interesting challenge.
 

Research

At a higher level, the majority of issues our users were experiencing existed due to the discrepancies between mouse-based inputs used within the web app and inputs available on most touch devices. In fact, many web-based interactions worked as intended on mobile, and the web app could properly load on mobile devices, short of a number of visual changes required.
 

However there were a number of critical interactions that were broken in one way or anorther. In order to clarify the design problem, I've observed Onfleet users struggling with an existing mobile experience and asked them follow-up questions. Inquiries below were used to reduce scope by isolating only the problems affecting the majority of users:

Describe the situation you’re in when you’re trying to use Onfleet on mobile. Why can't you use your desktop machine, etc.?

When you need to use Onfleet on mobile, what are you trying to do, what is your end goal?

What are the things you can’t do on mobile right now that you wish you could do, compared to desktop experience?

After collecting enough information, I broke the initial problem down into smaller pieces:

• Dispatchers can't recreate an existing delivery task.

• Dispatcher can’t reassign a task from one courier to another.

• Dispatcher can’t update delivery task's details, like address or time window.

UX & Design Thinking

After defining the design problem better, I decided to tackle each smaller issue separately. I wanted to move fast and validate proposed solutions in a matter of hours. In addition, each idea had to be put through an impact over effort analysis and quick and simple solutions were given a priority.

After defining the design problem better, I decided to tackle each smaller issue separately. I wanted to move fast and validate proposed solutions in a matter of hours. In addition, each idea had to be put through an impact over effort analysis and quick and simple solutions were given a priority.

Based on the initial assumptions I’ve made, I sketched out low-fidelity wireframes. Since the problems affecting most users were concentrated in the sidebar, I made a decision to isolate the map component from the scope and simply move it to a separate screen. This way, the front-end developer would not need to spend time on a component that had nothing to do with the issue at hand.

Most of the problems outlined earlier revolved around mouse-based interactions existing within the product, specifically:

drag-and-dropping delivery tasks between teams and couriers
double-clicking a delivery task to open its details modal
right-clicking on items to open their context menus
using Shift and Cmd keys to select multiple deliveries

The following solutions were proposed to the problems above:

introduce a long tap-and-hold trigger to start drag & drop
introduce "more" icon to every interactive item in the sidebar, that would open a context-menu (previously triggered on right-click)
add "view" to every context-menu (previously triggered by double-clicking) 

UX & Design Thinking
 

I was happy with the easy solutions above, but still had a harder interaction to address – selecting multiple deliveries and applying bulk actions.

Below are raw notes from an ideation/brainstorming session regarding those interactions.

How do we handle the use case when a dispatcher needs to reorganize tasks (by moving them around in a list)? Go!

By pressing a dedicated icon (only shown on mobile, next to …) and dragging the task.
Or by tapping and holding the task for 0.75 seconds, which puts the task into a floating state
We need to be able to scroll through a sidebar while dragging. As the task moves closer to the edge, scroll the sidebar. This might result in patchy animations.
When you hold a task, it enters floating state. We would reduce the width of a task element by 25%, clearing out required space on the right. User would scroll through it.
While in that state, you can’t interact with anything in the sidebar. The tasks will be moving underneath the floating task, allowing for it to be dropped into the space under it.
How do we confirm placement?
By pressing a dedicated icon,then pressing another button/icon/tbd to confirm placement after the scrolling is completed.
Issues: will need to account for cancelling, will also need to restrict specific placement, based on permissions.
How do we drag multiple tasks?
Perhaps we need a drawer/second container to "hold" selected tasks and then we drag from it?
How do we select multiple tasks?
 
Brainstorming allows me to quickly test as many solutions as possible. Great design tends to be very simple, but it's the search part that's difficult.

In order to find a great solution, I looked at how various apps approached bulk actions on mobile and what UI patterns would work in Onfleet's case.
 

 I tested the final interaction using a paper prototype (while the Sales team thought I was back in kindergarten).
 

I liked the outcome of the internal testing session. Before turning to mockups I usually write out the scope of what needs to be redesigned, for easier accountability.

After that I brought my ideas back to Sketch to finalize what I had started. I tend to be more successful when I describe decisions made in high-fidelity mockups. This way I can make sure I’m not missing anything in a long and complicated workflow. 
 

After the mockups were completed, I wanted to work on explaining the interactions and the solution to my front-end engineer working across the world. I took my mockups to Principle to create high-fidelity prototypes
 

Results

At the end I had a doc with flowcharts describing each new interaction that needed to be introduced into the product. The flowcharts were supported by high-fidelity mockups, describing each step. More complex interactions were described in motion.

All of the above was sent over to front-end engineer who had a couple of follow-up questions that were discussed and answered. In addition to that, I had notes from an internal testing session and initial user interviews. Both made it easy for us to measure success for when the final version was ready to be tested.

It's hard to call this feature release a major redesign, since the features introduced fall into the "must-be" category of features. However, improvements that eliminate user frustrations are just as important to product's success as the attractive and innovative features we all try to release. Improvements like the one I described reduce churn. It's a good idea to dedicate equal time and effort to keeping your existing users happy as well as acquiring new users. And if you can manage to keep engineering scope to a minimum while at it – good for you!