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.
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.
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.
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:
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.
Realizing there was an opportunity to save at least two weeks of an engineer's time, instead of approaching the problem as a mobile app project, I approached it as a web design problem.
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:
The following solutions were proposed to the problems above:
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!
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
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!