Overview
Mark43 makes software to streamline workflows for dispatchers and first responders across law enforcement, EMS and Fire. I was the designer on the core CAD (computer-aided dispatch) team, working in close collaboration with product managers, engineers, and customer experience managers. This case study will highlight the work I did around creating a Response Plans builder for fire agencies.
Project Details:
Duration: 8 months
Team: 2 Product Manager, 2 Engineering Managers, Regional Customer Support Managers, 2 Designers (myself, later joined by one more)
My role: research, strategy, planning, wireframing, prototyping, usability testing
Tools: Figma
Deliverable: end-to-end solution in Figma to be integrated into existing admin settings and Dispatch software
Primary Job to be Done:
Enable Fire admins, leadership, and dispatchers to create and update Response Plans in an intuitive and scalable way
Background
A response plan is a predefined set of unit types and counts for a given event, determined primarily by call type and resource needs. It is essential in fire/EMS agencies for speed, consistency, and coverage. Ideally, a small set of response plans would be applied across a large number of event criteria.
Historically, fire agencies have had to rely on Mark43’s CSV template and enter all their response details into it, which consist of run orders and response plans. Only a few individuals in the department had the specialized knowledge, training, and experience to work with the CSV, and the spreadsheets often have thousands of lines. This was a tedious process that often presented bottlenecks during crucial times, such as when updates needed to be made. Sometimes it would be so difficult that Mark43’s customer experience managers would need to step in to make the changes. This presented a significant issue throughout the broader workflow, and there was a growing desire from multiple customer agencies for a backend tool to streamline the input and management.
Additionally, the Mark43 Dispatch software did not track equipment usage (such as Jaws of Life, or sand deployment for oil spills). Tracking this would aid in financial decisions and inventory justification. Not being able to link actual responses to defined response plans also meant that benchmarks and performance analytics were not as easily tracked.
Personas
Agency Admin:
Impact
Simplify configurations and provide full functionality to cover response planning across disciplines and incident type
Sample User Stories
I need to define response codes for specific event criteria so that appropriate responses are generated consistently.
I need fields available for analytics and reporting so that performance and adoption can
be measured.
Dispatcher:
Impact
Enhance trust and transparency in unit recommendations to minimize manual interventions before unit assignment
Sample User Stories
I need to see clear unit recommendations so that I can assign the right units quickly.
I need simple Confirm and Override controls with a reason so that operator judgment is captured and preserved.
First Responder:
Impact
Enhance trust and transparency in unit recommendations so that first responders have certainty in their assignment before going en route
Sample User Stories
I need to see my assignment and brief rationale on the MDT so that I understand why I am responding.
I need to be notified when my assignment changes so that I stay aligned with dispatch.
Business Goals
The lack of a fully functional response plan feature had resulted in a 71% deal loss in potential fire agency customers. By modernizing response plan management, Mark43 could directly address competitive disadvantages in Fire/EMS bids, meet RFP requirements, and expand market share by delivering a differentiated, future-proof CAD.
The KPIs of the project were as follows:
Qualitative
Increased satisfaction for users
Quantitative
% increase in contracted ARR for fire/rescue agencies
% increase in approved RFP responses for response plan-related functionality
% of fire/rescue assignments which are equal to the recommendation (ie. recommendations are correct)
100% adoption by all customers over X months
% reduction in time to configure an agency’s response plans
% reduction in time to update an existing response plan configuration
Strategy
From the beginning, the team understood that gaining a deep understanding of Fire agency workflows would require extensive discovery. Over five months, we engaged key Fire agencies through remote conversations and strategic in-person visits to observe their work firsthand. The background information laid out above was gained through these discovery efforts.
The goals of this project were as follows:
Complete overhaul of the existing system, making sure that all personas could adopt and do well with the new one
High usage and engagement with the new system, including shorter plan creation times
Improved confidence among users, increased knowledge to make informed decisions mid-event
With the user need, problem, and project goal established, it was time to move on to implementation.
Solution
Mark43’s Rules-Based Response Plan Generator is a next-generation CAD capability designed for agency administrators, dispatchers, and first responders that eliminates the bottlenecks and low confidence created by the old CSV-based configuration approach. It leverages battle-tested rule-based reasoning technology to automatically generate transparent, scalable, and configurable response plans across all disciplines and incident types, while offering clear visibility into why units are assigned. For admins,it simplifies complex configurations and accelerates onboarding; for dispatchers and responders, it builds trust in recommendations, reduces manual interventions, and ensures operational certainty before units go en route. By modernizing response plan management, Mark43 can directly address competitive disadvantages in Fire/EMS bids, meet RFP requirements, and expand market share by delivering a differentiated, future-proof CAD.
The Respond interface (web shown here) consists of:
A. The map
B. Officer “dots”
C. Officer cards
D. The officer list
E. Alerts
At any given time, any number of items could be demanding a viewer’s attention. Depending on an agency’s alert settings, certain events could automatically trigger alerts, such as a weapon drawn, a siren activated, a vehicle’s speed exceeding a limit, etc. However, none of these configured alerts account for intentional, human-initiated requests for assistance, which is where Watch Me comes in. The challenge was to incorporate a new alert notification that would stand out from all the others because in these situations, every second counts.
Solution and Key Decisions
Visual Indicator and contents
The visual indicator I decided to go with was a purple bubble (dubbed “spotlight”) above the requesting officer dot. Prior to coming to the final decision, I brainstormed several ideas involving various icons, visual treatment, and additional banners. However, I made my final decision because purple is a color that had been established to be associated with livestreaming, but was not yet used, so it would stand out and help the assisting officer zero in on which officer(s) needed immediate attention.
As for the content of the spotlight, at first I thought about using the words “Watch Me”, but decided against it because 1) the presence of the spotlight was already sufficient to indicate a Watch Me request, and 2) that space is valuable because it needs to convey the most crucial information. Hence, I decided to highlight the officer’s name by putting it in the spotlight. The addition of the hand emoji was suggested by one of my teammates, and everyone agreed that it worked well because it was a universally understood symbol for needing attention; hence, there would be no doubt what the whole spotlight was conveying.
I also decided to add the relative timestamp because it would help Respond viewers quickly see which request has been waiting the longest, and address them in order.
Notifications
A system like this is only effective if the intended viewers receive notifications about requests. Notifying users on mobile turned out to be straightforward because we could utilize native push notification systems for apps and hence didn’t need to add anything extra to the Respond app. However, web proved to be more tricky because while Respond already has a notification system, it was poorly designed a long time ago and most users find it to be ineffective. Redesigning notifications on web was definitely a priority for the team, but the scope of that project would be much too large to include in this one, so we resolved to compromise by not changing the existing system for now, but include Watch Me as a high priority notification so that it would appear in a familiar spot, and then use the findings from this to inform the future long-term notifications overhaul efforts.
Final Designs
Flows
1. Mobile, from push notification
2: Mobile, from cluster
3. Web
Prototypes
Mobile
Web
Components
Mobile
Web
Testing, Launch, and Impact
To sync with the launch of the new Body 4 camera, Watch Me (plus the other new features like voice comms) was first released to a few customers so that they could beta test it. I separated my designs into separate beta and launch handoff pages and provided clear notes and specs for engineers, calling out product requirements and mapping specific screens to them.
(The following is an excerpt from this article)
In order test Watch Me, the agency assembled a group of five officers to activate Watch Me at least five times a shift for a period of 90 days. Some officers and command staff were admittedly skeptical, thinking that the new technology was interesting, but may “not have a lot of practical applications”, as patrol Lieutenant Justin Day put it.
However, the test users soon found Watch Me to be a reliable, helpful tool for gaining visibility in the field, including for use cases they wouldn’t have anticipated. Officers found that they could send a clear, unambiguous signal that they wanted or needed a supervisor to live stream in, enabling them bring their supervisors in a the right moment and bring their eyes to the right camera to make an impact. Supervisors, for their part, could know exactly when to start a live stream, see the situation unfold in real time, and make informed decisions on next steps and resource allocation.
For the beta release, the team had to make some small compromises, such as being more generic with copy and not yet including timestamps. Watch Me was fully launched one month later.
Since its launch, Watch Me requests get initiated 1400 times per week and increasing. I visited a customer agency that uses Respond, and they said that Watch Me was a big improvement in their patrol experience.
Overall, the launch of Axon Body 4 was a tremendous success, due in no small part to the inclusion of Watch Me. I am proud to have contributed to Axon’s mission of protecting life through the work I did on this project.