Protothon - Seattle Fire Department
Protothon is a 30-hour rapid UX design hackathon. Our five-person team of 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 30 hours on the clock, I skipped secondary research and went straight to a primary source. I reached out and secured a phone interview with an active dispatcher at E-Comm, the non-profit that handles 911 dispatch for 99% of BC.

That call changed everything we designed.
Finding #1
Resource tracking was physical
Dispatchers moved fire truck cutouts on a literal corkboard to track unit locations. No digital tracking. No automated alerts. One person, moving cardboard by hand.
Finding #2
Dispatchers manage three screens simultaneously
Incoming incident tickets color-coded by priority. A live unit status table. Radio communication running in parallel. Fire crews receive all updates verbally because they have no laptop on the truck.
Finding #3
The system had gone down before
For eight hours, the team ran emergency dispatch on paper and pen. Call takers wrote updates by hand. Runners carried them to dispatchers. It worked because the information structure was simple enough to survive without technology.
What we can learn from this?
Complexity is the enemy. The dispatcher said it directly: "The more moving parts there are, and if you put a technology glitch in the way, it's miserable." Every design decision we made prioritized speed, scannability, and resilience over feature richness.
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
The dispatcher manages three separate screens during a shift. We consolidated everything into one view.
Main Dashboard
Three data layers in one screen: incoming tickets, unit status, and resources. No context switching.
Incident List
Incidents sorted by time, flagged live. Mirrors the color-coded board dispatchers already use mentally.
Real-time Map
Replaces the physical corkboard with a live digital map. Units update automatically as they're dispatched.
Resource Dashboard
Active personnel, vehicle status, and equipment availability in one persistent view. No hunting through separate systems.
Solution #2
Optimizing the Dispatching Process
The most time-critical moment is matching the right resource to the right incident. We designed this entire flow around that single decision.
Incident Discovery & Resource Allocation
Incident list and map sit side by side. See the incident, find the nearest available unit, dispatch — without switching screens.
Filtered Incident List
Filterable by severity, type, and status. Cuts through noise so the highest priority incidents surface immediately.
Interactive Map
Clicking a station shows available units and equipment. Makes coverage gaps visible so the one-truck-per-station rule is never accidentally violated.
Solution #3
Importing, Analyzing, and Displaying Data
Post-incident reports were being filled out manually. The data already existed in the system, we just made it importable.
Post-Incident Report
Enter an incident number. Fields auto-populate from the existing record. Responders only fill in what the system doesn't already know.
Importing the Data
One number, full record. Review, fill gaps, submit. A manual form becomes a confirmation step.
Additional Details
Injuries, property damage, and witnesses appear after the import. Responders only see fields they actually need.
Data Analytics
Post-incident reports feed a live analytics layer. Response times, high-risk areas, and trends visible across historical data.
Live Incident Tracker
Today's busiest stations with unassigned and available unit counts. One click to resource allocation.
Informative Map
Historical incidents overlaid on the city map by response type and hotspot patterns. Spatial view of where demand concentrates over time.
Trends
Year-over-year response times against national benchmarks. Makes patterns visible before they become systemic problems.
Conclusion
Challenges
Time Restriction
30 hours left no time for usability testing. We shipped on research and instinct.
Scope creep
We tried to solve every problem on the list. In hindsight, going deeper on one flow would have told a stronger design story.
What I would do different?
Focus on a Flow
The dispatching and resource allocation screen was the most time-critical moment in the system. Given more time, I'd have focused the entire project there — deeper research, more iterations, usability testing with real dispatchers.
Validate the UI
The dispatcher interview gave us real operational insight, but we never tested the interface with a dispatcher. That's the gap I'd close first.
What this project proved
Primary research changes everything.
Most hackathon teams skip it. One 30-minute call with a real dispatcher reshaped every design decision we made — from the dashboard layout to the resource allocation flow to the reporting system. That instinct to go to the source before opening Figma is something I bring to every project.