- UX Research
- SaaS
SFD Dispatch
A 30-hour hackathon redesign of the Seattle Fire Department's dispatch system
Dispatchers were tracking fire trucks by moving paper cutouts on a corkboard. In 30 hours we designed what should replace it.
Role
UI/UX designer and UX researcher
Timeline
30 hours, May 4–5, 2024
Team
5: 3 UX designers, 1 project lead, 1 CS student
Event
Protothon
3 → 1
Screens consolidated into one dashboard
+2.3%
Emergency calls, 2022–2023
Responses up 5% over the same period
30 hrs
Research to prototype
Jump to a section
Overview
A rapid design sprint against a real constraint: emergency demand rising faster than the tools handling it.
Our five-person team was given one prompt: help the Seattle Fire Department go digital. Between 2022 and 2023, emergency calls rose 2.3% and responses rose 5%, and the system absorbing that increase was legacy software spread across three separate screens.
I worked as one of three UX designers on a five-person team. I ran the primary research and owned the dashboard and incident discovery UI.
One phone call that changed everything
We had 30 hours. We spent a meaningful share of them on a single interview, and it was the right call.
I interviewed an active dispatcher at E-Comm, which handles 911 dispatch for 99% of British Columbia. Three findings came out of it, and all three contradicted assumptions we'd made from secondary research.
Resources were tracked physically
Dispatchers moved fire truck cutouts around a corkboard by hand. There was no digital automation for the single most time-critical piece of information in the room.
Three screens, plus a radio
Operators managed colour-coded incident tickets, live unit status tables, and parallel radio communication simultaneously, holding state across surfaces that didn't talk to each other.
An 8-hour outage run on paper
During a system failure, dispatch continued with pen and paper. That detail reframed the whole brief: whatever we designed had to degrade gracefully, and simple information architecture was a resilience feature, not an aesthetic preference.
“The more moving parts there are, and if you put a technology glitch in the way, it's miserable.”
Speed and resilience over features
The interview pushed the team toward a principle we held for the rest of the sprint: prioritise speed, scannability and resilience over feature richness.
That is an unusual thing to conclude in a hackathon, where the incentive runs hard the other way. It also meant deliberately not designing things: no clever automation that a dispatcher would have to second-guess at 3am.
Steep learning curve
The legacy interface slowed new dispatchers down at precisely the moment errors are most costly.
Manual resource allocation
Assessing availability by hand introduced delay into the most time-critical step in the process.
Post-incident reporting by hand
Responders spent time on manual forms that the system already had the data to fill.
Three screens into one
The core move was consolidation: a single dashboard replacing the three-screen split, with the incident list sorted by time and flagged by colour-coded priority, a live digital map in place of the corkboard, and a persistent resource panel covering personnel, vehicle status and equipment.
Allocation without leaving the screen
The incident list and map sit side by side, so a dispatcher can assess an incident and assign units in one field of view. The list filters by severity, type and status.
A map that shows gaps
The interactive map surfaces coverage gaps and station-level availability: the thing the corkboard was doing, done in a way that updates itself.
Reporting that fills itself in
Post-incident fields auto-populate from the existing record. A dispatcher enters one incident number instead of completing a form.
On top of that we layered analytics: response times, high-risk areas, historical trends, a live tracker of the day's busiest stations, and year-over-year benchmarking against national standards.
What 30 hours cost us
Given the time again, I'd cut everything except the most time-critical moment, dispatching and resource allocation, and spend the recovered hours validating it with actual dispatchers.
The larger takeaway was about research economics. One conversation with someone who does the job reshaped the dashboard layout, the allocation flow and the reporting system. Under severe time pressure, the instinct is to skip primary research because it feels slow. It was the highest-leverage thing we did.