What is Dispatch Hub?
Zello Dispatch Hub is a centralized push-to-talk dispatch platform that helps dispatchers support the frontline faster.
Overview
One of the key use cases of Dispatch Hub is drivers calling in dispatchers for help. Ideally, the first dispatcher that answers the call is able to assist,
however, that is not always the case.
Previously, if dispatchers could not help, they had no choice but to end the call and ask the driver to call again so they can be placed back in the pending calls list.
Over a couple of weeks, I explored explorations, iterated high-fidelity prototypes, and went through multiple rounds of internal x-functional critique sessions to land on the final design.
Previous User Flow
This was a huge pain point for our users when dispatchers could not offer assistance during the initial call. It resulted in dispatchers and drivers repeatedly calling and hanging up until they successfully connected with the appropriate counterpart.
Key Areas of Focus
Based on customer calls, user interviews, and general feedback, we decided to focus on these key areas:
Allow users to send calls to pending
Allow users to transfer calls to another dispatcher
a. On the dispatcher’s receiving end, have them accept/acknowledge the call
b. On the driver’s side, give them feedback that their call was transferred to another dispatcher
Iteration Explorations
In the early stages of my exploration, I tried many different approaches and shared these early iterations with the design team and the product manager:
Success and error states
Placement
Toast vs. banner
Tooltips
Copy explorations
Modals
Headers
Subtitles
Initially, we considered implementing a feature that would allow dispatchers to leave each other messages (audio or text) when transferring calls. However, due to that feature increasing scope and our desire to first validate if our users would actually use this feature, we decided to simplify the flow by completely removing this step.
Since the Dispatch Hub platform is responsive, it was important to keep in mind how content would scale at different screen sizes and adjust components based on screen size.
Feedback Sessions
Due to time constraints and limited resources, I did not have a chance to hold external user interview sessions but had the opportunity to have internal x-functional critique sessions, where I shared my explorations with other designers, product managers, and engineers. In the end, we were able to come up with a solution that everyone agreed on.
After the last round of iterations, the product manager of the project let me know that after a discussion with engineering, implementing one of the solutions would take a significant amount of work. I had to make a quick pivot, but in the end, was able to come up with a solution that everyone agreed on.
Transfer Call Back to Pending
Pending active call user flow
Dispatchers are now able to move an active call to pending and confirm that the call was moved back to pending successfully.
*The loading state isn't necessarily part of the flow, but a state to handle longer loading times.
Other screens
Error state
History screen
In addition to the primary user flow, I also had to take into account other screens and scenarios. For example, I considered how the system would handle errors and what the display would be like on the history screen when a call was successfully moved back to the pending status.
Transfer Call to Another Dispatcher
For transferring the call, there are two distinct flows: sending and receiving the call.
Sending call user flow
The process of transferring a call to another dispatcher follows a similar flow to moving an active call to a pending state. However, in the case of transferring, we introduced a confirmation modal that requires the user to confirm their action. We implemented this additional step to prevent errors and provide a clear decision point. Once a dispatcher selects "Confirm Transfer," they lose control over the transfer.
Other screens
Transfer unavailable
Error state
History screen
Again, similar to pending active calls, I had to consider additional states such as errors, history screen, and what would happen if there were not any dispatchers to transfer calls to.
Receiving call user flow
No calls
Successfully transferred
Initially, we considered having the dispatcher receive a list of "transferred calls" that they could choose to accept or put back in pending. However, implementing this solution would require additional effort from the developers, and we realized that it did not address the original problem. If the dispatcher didn't accept the call, the drivers would still be stuck in a pending state.
To streamline the solution, we made a few changes. We now only allow dispatchers without any active calls to receive transferred calls. Additionally, I utilized an existing component to highlight the cell and replace the subtitle with a description indicating who transferred the call.
Two-panel view for successful transfer
Select dispatcher
Successfully transferred
On larger screens that have two-panel views, I employed modals to display user lists and confirm critical actions. However, I made a conscious effort to minimize the use of modals whenever possible, as they have the potential to interrupt users' primary workflows.