CASE STUDY · PART 01 · INCIDENT HANDLING — CALL-TAKER

Simplifying a critical operation around the people who use it

A concept for a 911 platform focused on the core emergency-response flow: less friction for call-takers and less unnecessary complexity in the product.

Product DesignProduct AnalysisUX ResearchComplex Systems
01 · Understand 02 · Prioritize 03 · Explore & decide 04 · Build & adapt
Sections
01Understand
CONTEXT

What happens when someone calls 911?

When someone calls 911, a Call-taker answers the call and starts gathering the information needed to understand what is happening.

Through the conversation, they need to determine whether the situation requires an operational response, build enough context to turn it into an incident and allow that response to begin. If the call is actionable, the information becomes an incident record that moves forward to Dispatch.

Call
→
Call-taker
→
Incident
→
Dispatch
→
Response
In just a few minutes — sometimes seconds — a conversation has to become information capable of triggering a response.
THE CHALLENGE

The problem wasn’t just the interface

A CAD (Computer-Aided Dispatch) platform can bring together rules, configurations and capabilities designed to support different emergency-response environments.

This concept started from a different goal: Protect the core of the operation and keep secondary complexity from competing with it.

Simplifying had two dimensions: making the operation easier to perform and making the product itself simpler to build.

Goal

Design a concept for the Call-taker role that prioritized the incident-handling flow and organized the rest of the functionality around it.

RESEARCH

First, I needed to understand where the complexity lived

The research combined operational experience with functional knowledge of the system to understand not only where friction appeared, but how incident handling actually works in practice.

3

Call-takers

They showed how they receive, interpret and turn a call into an incident as part of their day-to-day work.

Interview synthesis

When another call comes in or the task changes, regaining context can become part of the work itself.

Call-takers · qualitative synthesis
“If another call comes in, I can lose what I was entering.”Call-taker · anonymized interview
2

QA profiles

A second perspective on the product.

They brought a broader understanding of the system’s rules, configurations and behavior. Their perspective helped contrast what Call-takers described with the product logic behind it.

“The minimum information required to route an incident should be available on a single screen.”QA · anonymized interview
WHAT KEPT COMING UP

Shared patterns across all interviews conducted.

5/5mentioned issues related to performance or stability.
5/5identified too many steps for certain actions.
4/5reported friction when maintaining context, navigating or accessing critical information.

Recurrence across the five interviews conducted. This does not represent prevalence across the full user population.

WHAT STARTED TO BECOME CLEAR
Available complexity shouldn’t become mandatory complexity.
Emergency information arrives progressively.
Continuity is critical throughout the call.
A Call-taker’s action can trigger the next part of the operation before their own task is finished.
JOURNEY MAP

Incident handling doesn’t begin when an incident record exists

Before thinking about the interface, I reconstructed how a call moves from the moment it comes in to the point where the Call-taker finishes their part of the process.

Swipe to continue →
Enter
Understand
Decide
Create
Add context
Activate
Complete
Finish
What happens
Receives a call or starts a manual incident.
Listens while beginning to capture information.
Determines whether the call requires an operational response.
Turns the call into an incident.
Completes the information needed to move the incident forward.
Classifies the incident.
Continues adding information to the incident.
Ends their participation.
What they need
Start without delays.
Build context as the conversation develops.
Continue or close the call with clarity.
Preserve everything already captured.
Capture information as it becomes available.
Know that the response can now begin.
Move forward without losing what they already know.
Know that their work has been properly recorded.
Where friction appears
PerformanceSlowness or failures can break the rhythm from the very beginning.
ContextMoving between different spaces splits attention.
DecisionCommitting to the full workflow too early can create unnecessary work.
ContextChanging stages can force the Call-taker to rebuild context.
RigidityInformation does not arrive in the same order as a form.
FeedbackThe consequence of an action may not always be visible.
ContinuityView changes or lost state can force users to reconstruct context.
StateAmbiguous states can create uncertainty or repeated actions.
Opportunity
Bring both entry points into the same workspace.
Allow progressive data entry without leaving the current context.
Separate preliminary call handling from incident creation.
Make incident creation a transition, not a restart.
Prioritize critical information without forcing a rigid sequence.
Make the handoff to Dispatch clearly visible.
Keep the call active while the incident continues moving through the operation.
End the task with a clear transition.

Incident handling isn’t a linear form. It starts with incomplete information, evolves throughout the conversation and can trigger a response before data entry is finished.

02Prioritize

To simplify the product, I first needed to define what actually moves the operation forward

Once the journey was clear, I identified the actions that were essential to handling an incident and separated them from everything that could extend or configure the experience.

USER FLOW
Integrated call / Manual entry
→
Capture initial information
→
Does it require an operational response?
No
Mark as non-actionable
↓
Finish
Yes→
Create incident
→
Generate incident record
→
Location · Classification · Description
→
Classify · Send to Dispatch
→
Continue adding information
→
Mark as handled

The core journey wasn’t a stripped-down version of the CAD. It was the foundation everything else needed to work around.

SCOPE

Scope was a design decision, too

The goal wasn’t to reproduce every possible CAD capability. It was to define what needed to be present for the product to create value for its users.

01
What moves the operation forward
The essential actions required to handle a call and create an incident.
02
What protects continuity
The context and states that allow Call-takers to keep working without reconstructing the task.
03
What extends the product
Configurations and capabilities that add value depending on the needs of each implementation.
03Explore & decide

What I learned became product decisions

With the core flow defined, I translated the findings into concrete product behaviors.

What I learnedWhat the operation needsHow the concept responds
Not every call should become an incidentUnderstand the situation first, decide what to do with it second.Allows context to be captured before determining whether the call is actionable and creating the incident record.
Information arrives progressivelyCapture information as the conversation unfolds.Gives greater prominence to location, classification and description, while allowing sections to be reorganized around different ways of working.
Continuity is critical during a callKeep working without rebuilding context.Keeps active information visible to reduce unnecessary jumps between views.
Classification activates the responseAllow Dispatch to begin without waiting for data entry to be completed.Sends the incident to Dispatch while the Call-taker can continue adding information.
The map should provide context without competing with the taskCheck location without sacrificing the space required for call handling.The map acts as contextual support and gives up space when data entry needs more room.
Performance affects continuityMaintain the pace of an intensive operation.Reduces unnecessary load around the core journey and makes waiting states visible.
The core flow keeps the operation movingKeep critical actions clear and accessible.Organizes the interface around the actions that move an incident forward.
The system needs to communicate what is happeningWork with confidence about the state of each action.Important transitions provide visible feedback and clear state changes.

Simplifying didn’t mean removing capabilities. It meant protecting what keeps the operation moving so secondary complexity wouldn’t compete with what matters most.

04Build & adapt

The decisions that shaped the concept

The screens aren’t the starting point of this case study. They’re the result of decisions around hierarchy, flexibility and continuity within the operation.

ModularLegibleFlexibleContextualEfficient
01

A clearer workspace

The interface is designed as a modular system that brings critical information together and keeps the tools Call-takers need close to the task.

  • Modular architecture. Independent panels group related functions without fragmenting the operation.
  • Essential information first. Location, classification, description and status receive stronger visual hierarchy.
  • Map as support. It remains available for locating and validating context without dominating the workspace.
  • Less navigation. The actions needed to handle the incident remain within the same workspace.
Propuesta conceptual — espacio de trabajo modular
02

Data entry that adapts to the operation

The concept aims to reduce visual and cognitive load so the system supports the way people actually work instead of forcing them into a rigid structure.

  • Reorderable panels. Sections can move without changing the underlying system logic.
  • More legible fields. Better spacing, hierarchy and readability during data entry.
  • Fewer clicks. Critical information and primary actions stay within the same view.
  • Visible status. The system communicates what is happening and when an action has already activated Dispatch.

Classification doesn’t end data entry. It activates the response.

Propuesta conceptual — captura activa y envío a Despacho
03

Look things up without losing context

The lookup experience preserves the same mental model and lets Call-takers recover information without rebuilding the task from scratch.

  • Multiple open incidents. A tab system allows Call-takers to move between incident records without losing orientation.
  • Quick incident overview. Status, location and key information remain accessible.
  • Continuity between entry and lookup. The interaction model remains consistent.
  • Recoverable context. The Call-taker can return to an incident and continue where they left off.
Propuesta conceptual — consulta de incidentes con tabs
CLOSING

Conclusions & next steps

Simplifying a critical operation doesn’t mean eliminating complexity. It means deciding where that complexity should live so the parts that keep emergency response moving remain protected.

Protect what matters most

In a critical operation, the actions that move an incident forward need to be clear, fast and reliable.

Design for different people

Call-takers can have different ages, levels of digital experience and ways of working. The system needs to accommodate that diversity.

Respect operational expertise

The person handling the call may not be a technology expert, but they are an expert in emergency response. The tool should reduce friction rather than require unnecessary technical knowledge.

Add flexibility with intention

Customization creates value when it supports the way people actually work: reorderable panels, prioritized information and readily available context.

In 911, time isn’t just about efficiency

Every second can affect how quickly an emergency begins receiving a response. Performance, clarity and continuity are part of the experience.

What I would still want to validate

Experience

  • Whether the reorderable structure supports different ways of working.
  • Whether critical information can be found faster.
  • Whether the concept reduces steps and context switching.
  • Whether the tab model helps Call-takers manage multiple incidents without losing orientation.

Product

  • How much performance improves when complexity around the core flow is reduced.
  • How much configuration each operation still needs.
  • Whether the modular architecture can scale without making the experience cluttered again.
The goal wasn’t to build a CAD with fewer capabilities. It was to design a tool that could adapt to the people who already know how to do the most important part: handle an emergency.
← Back to case studies