CAA
Tow truck dispatch panel: improving response times
Improved emergency response times by adding map filter functionality and hierarchy to the buttons and data visualization.
ROLE
Product Designer
TIMELINE
1.5 months (2023)
TOOLS
Figma, FigJam, Teams Meetings
Overview
Background of the application
The purpose of this software was to show the roadside assistance team historical, live and predictive information about our stranded members and tow trucks all on 1 map.
Challenge
2 challenges slowed down emergency response time:
-
Map is overcrowded by showing all of this data
-
Control panel displays all the buttons and data with equal hierarchy when they all serve different purposes and priorities
Original control panel with cluttered map icons.
Solution
-
Adding filter functionality to minimize overloading the map
-
Prioritize the hierarchy of the buttons and data displayed on the control panel
Old panel
New panel
Business objectives
-
Reduce average response times
-
Improve dispatcher & control tower efficiency
-
Decrease operation error (e.g. wrong truck assignment)
01
Talking to users
The goal of this stage was to
-
Understand the platform's daily challenges
-
Identify key pain points
-
Analyze what features were actually used versus ignored
I had to ensure the redesign addressed the needs without accidentally removing anything essential for any user.
User interviews + shadowing
The goal of the user interviews was to get a complete picture of diverse workflows and zero in on the most critical operational needs.
Targeted users
I spent time shadowing and conducting detailed interviews with all 4 primary roles who rely on the platform.
-
Dispatchers
-
Control Tower Operators
-
Supervisors
-
Account Representatives
Key findings from user interviews
It was clear from initial observations and user feedback that its core issues stemmed from an overwhelmed and inflexible interface.
Original control panel with cluttered map icons on snowy day.
1
Information overload & visual clutter
-
The map was severely crowded with icons, heatmap data, and weather information, creating severe information overload.
2
Impeded response & safety risks
-
This clutter, especially during high-pressure scenarios, increased the risk of missing critical alerts, slowed decision-making, inflated training time, and introduced significant safety risks.
3
Lack of customization for diverse roles
-
A "one-size-fits-all" design failed to be diverse enough for the 4 distinct roles.
-
All essential data was presented with equal visual weight with the inability to filter or customize views.
Balancing competing workflows
The root of the information overload wasn't just too much data - it was that 4 distinct roles were forced to share the exact same view, despite having conflicting operational goals.
Real-time action roles
Roles included: Dispatchers, Controllers, Supervisors
These users operate with high urgency. They need to determine which tow truck is best suited to rescue, accurately communicate to tow truck and stranded person the status of their call.
Need to be able to look at all active calls, road closures, tow truck details & location
Audit & Review Roles
Role included: Account Representatives
These users aren't dispatching trucks at all. They need to investigate completed calls, track idle times, and ensure trucks are adhering to licensed zones.
Need to be able to see historical data to understand why calls were late and make sure that tow trucks are following the licensed area laws.
02
Identifying
workflows
I reframed the challenge to include the 4 user roles of this tool.
"How Might We"...
...allow four distinct user roles to access critical emergency data without overwhelming the interface?
The solution started with the Information Architecture (IA)
I noticed that 4 user roles primarily needed either "Live" or "Historical" data. I laid out all of the features in FigJam and then based on this, I restructured the entire interface around 2 distinct primary functions:
-
"Live" tab for real-time incident management
-
"History" tab for reporting and past data
By segmenting the data, the interface becomes cleaner and more focused - allowing users to prioritize current critical data while keeping historical data accessible but secondary.
03
Interactive
prototyping
I translated the Live/History IA into structural wireframes first & conducted preliminary usability tests with these.
This stage included close collaboration with the development team to ensure the concepts were feasible within the existing backend constraints.
Out of scope
System limitations didn't allow us to change any icon designs on the map.
To combat this, I added comprehensive descriptions within the panel to ensure clarity despite the icon designs, while avoiding overcrowding.
Crowded map on a snow day
Wireframe prototype usability test
I developed interactive prototypes from the wireframes for initial usability testing with the core user roles. This testing was essential for identifying friction points before moving into high-fidelity design.
Key findings
My analysis pinpointed several critical usability issues that created friction:
Rescued, Stranded, Available, Occupied were not used as frequently as “Mean Arrival Times”. These stats should be swapped so when the panel is collapsed, the Mean Arrival Times always show
“Refresh” button is used frequently.
Needs to be bigger and more prominent.
Checkboxes took too long to check/uncheck all calls or all trucks at once. Need to add checkboxes for each of the groups to quickly show/hide all items at once.
Control panel width was too big.
Need to show more of the map.
Mockups
Using all the findings from the wireframe usability tests, I refined and created the mockups.
Designing for white-label scalability: the Line of Business wanted to keep the colours to a minimum so they can sell the product to other companies in the future.
Live Tab
History Tab
Prototype
04
Handoff & learnings
Prototype usability testing
I ran 1-on-1 sessions with Dispatchers, Controllers, Supervisors, and Account Reps asking them to perform specific tasks using the mockup prototype.
UI design updates from prototype usability testing:
-
Font sizes
-
Spacing/Padding
-
Added thicker stroke to separation lines
-
Introduced colour for links to enhance usability
Learning: The amount of changes were minimal due to amount of testing we had done prior with the wireframes and mockups.
Dev design review
-
Once development was completed & during the QA stage of the project, I initiated a design review of the development work.
-
Typically we do not have one built into our process.
-
-
I addressed any discrepancies and new modifications via Figma comments.
Dev design review comments
Final learnings and reflection
This was my first time designing an application instead of a website, and it came with many learnings. It was challenging (but fun) to think differently and step into a new problem space.
Learnings:
-
Application flows are not linear. They involve many interconnected tasks rather than the hierarchical navigation typical of websites.
-
Components are more dynamic, with multiple states and interactions to support complex tasks.
-
The design approach shifts from communicating information to enabling efficient task completion.
Old panel
Looking back 1.5 years later, there are a few things I would approach differently with the experience I have now. I’d introduce more subtle colour, typography, and shading details to elevate the visual hierarchy.
I’d also be more specific in my design documentation, especially around sticky buttons and interactions, to ensure smoother collaboration with developers.
This project gave me a foundation for designing complex, task-oriented experiences, and it’s rewarding to see how much my visual and communication skills have grown since then.
New panel