WJ - Protothon SFD Dispatch System Case Study

intro.

the problem

research

pain points

Protothon - Seattle Fire Department

Protothon is a 30-hour rapid UX design hackathon. Our five-person team — three UX designers, a project lead, and a CS student — was given one prompt: help the San Francisco Fire Department go digital.With emergency call volume rising and dispatchers still relying on an outdated legacy system, the SFD needed a platform that could handle real-time incident management, smarter resource allocation, and faster post-incident reporting — all without slowing down the people whose job it is to respond in seconds.My role spanned both research and UI design. I conducted the primary user interview, led the journey mapping, and owned the dashboard and incident discovery screens.

Role

UIUX Designer, UX Researcher

Date

May 4th 2024 - May 5th 2024

The Problem

With increase in emergency calls by 2.3% and number of responses by 5% from 2022 to 2023, SFD is struggling to keep organized and communicate efficiently between the dispatcher and their units.

Research

With only 30 hours on the clock, we had to be ruthless about where we spent our research time. Rather than relying solely on the SFD annual report, I reached out and secured a phone interview with an active dispatcher at the Vancouver Police Department — someone working inside a real dispatch system, every day. That conversation was the most valuable 30 minutes of the project. It grounded everything we designed in actual workflow reality, not assumptions.

Pain Points

Three pain points emerged clearly from the interview and the annual report — and they all pointed to the same root cause: a system designed for a quieter era, now straining under modern demand.

Pain Point #1

The outdated system has a steep learning curve

The current system's UI is outdated, making it hard for new dispatchers to be efficient as well as slowing down the workflow in general.

Pain Point #2

Inefficient resource allocation leads to delays

In emergency situations where every second is crucial, the assessment and allocation of resources should be efficient and impactful.

Pain Point #3

Poor data management and report process

After every incident, a member of the unit must fill out a report of the incident's details such as resource used, time spent, causalities, etc. Filling the report out manually can take away the responder's time and efforts.

The Process

User Journey Mapping

I led the user journey mapping to align the team around how a dispatcher's workflow actually unfolds — from the moment a 911 call comes in, through resource allocation, to incident closure. Mapping this out surfaced where the current system created the most friction, and gave us a shared foundation before anyone opened Figma.

User Flow

Keeping the design goals in mind, we also created a user flow to align the project scope with the team by identifying the type of information and features needed in each step of the user experience screen.

Our Solution

Solution #1

Organizing Data for Incident Assessments

Main Dashboard

A dashboard with organized data and live information to allow the dispatcher to quickly assess the situation and keep updated.

Incident List

Display a list of reported incidents from 911 for dispatchers to quickly assess the overall situation.

Real-time Map

Interactive map linked to the incidents report to update and display current situation.

Resource Dashboard

Overview of current units and equipments and their status. This allows the dispatchers to quickly assess the inventory and how to allocate them.

Solution #2

Optimizing the Dispatching Process

Incident Discovery & Resource Allocation

Creating a overview map with list of incident reports and available resources to optimize resource allocation and dispatching units.

Filtered Incident List

Displays in-progress incidents filterable by severity and type for prioritized resource allocation

Interactive Map

Displays data of location of incident and fire stations and their available resources. Allows dispatchers to quickly assess the situation and dispatch the appropriate units.

Solution #3

Importing, Analyzing, and Displaying Data

Post-Incident Report

Re-designing the report creating and submitting process to be intuitive and rapid by importing the incident's data through their incident number.

Importing the Data

By allowing the report writer to import the incident's data through their serial code, accelerate the process and accurate.

Additional Details

Allows further editing of the report and submit ing directly to the database or download as a PDF.

Data Analytics

Through the reports submitted from historical incidents, organize and display the data to provide insights on trends, patterns and resource allocation.

Live Incident Tracker

Displays the today's busiest fire stations and their resources, updated in real time.

Informative Map

Analyzes and displays high risk areas and trends based on data from historical incidents.

Trends

Displays analytics of collected data from historical incidents such as: call response time, trends, and type of responses.

Conclusion

Challenges

Time Restriction

As a 2 day hackathon (30 hours), the time to research, ideate, and iterate the design was very restricted. To make up for the lack of time, we mostly relied on resources provided by the fire department or online sources. Also, this gave us no time to do user testing to validate the UI design.

What I would do different?

Focus on a Flow

In a 30-hour window, our team tried to solve every problem the SFD listed. We shipped a dashboard, an incident discovery flow, a post-incident report system, and a data analytics view — and while I'm proud of what we produced under that pressure, I'd make a different call next time. Given the chance to go back, I'd focus the entire effort on the dispatching and resource allocation flow — the most time-critical moment in the system, and the one where good design has the most direct impact on outcomes. A single flow, deeply researched, iterated, and validated, would tell a stronger design story than four flows at surface depth. The constraint of no usability testing is real — and worth naming honestly. But the dispatcher interview gave us something most hackathon teams don't have: a firsthand account of what it actually feels like to work inside these systems under pressure. That insight drove every design decision, and it's what I'd lean into even harder given more time.