United Airlines · Emergency Response

Coordinators were abandoning the emergency tool mid-incident. We fixed the reasons why.

United's Emergency Response Platform activates response teams and tracks incidents across a global airline. Research showed the people who depend on it trusted it least when it mattered most.

ClientUnited Airlines
My roleUX Designer
TeamUX Research + Design + DT
TimelineJan – May 2025
StatusDetails under NDA
–40%task completion time in the redesigned activation flow
+68%reported system confidence after redesign
15interviews across four hub stations, two testing rounds

This work is under NDA. The public version tells the story with details generalized and artifacts removed. The full case study, with screens and research findings, is available on request.

The situation

When something goes wrong at an airline, coordinators use ERP to activate response teams, manage communications, and track incident status across departments. The stakes are as high as software stakes get.

The system worked against its users. The activation flow was slow and gave no feedback. Coordinators told us they sometimes waited 30+ seconds on the launch action during real incidents. Some had stopped using the system at critical moments entirely, building manual workarounds out of Teams meetings and messaging apps. An emergency tool that people route around isn't an emergency tool.

What I did

Research built around stress, not screens

With our research team I ran 60-minute discovery interviews with coordinators across Denver, Newark, San Francisco, and Chicago, covering three roles from network-level coordination to local hub response. The questions weren't about the UI. They were about what an incident actually feels like: what you check first, who you call, what you stop trusting when seconds matter.

The redesign followed the panic path

The findings clustered into three friction categories, and we redesigned the activation flow around the moments of highest stress: fewer clicks to launch, visible system feedback at every step, and workflows that match how coordination actually happens across departments. Low-fidelity prototypes went back in front of eight coordinators for moderated testing before anything was built.

FIG. 01 · The panic path Redrawn abstraction · NDA-safe
T+0 · ACTIVATE NOTIFY COORDINATE RESOLVE SYSTEM FEEDBACK AT EVERY STEP · FALLBACK PATH ALWAYS VISIBLE −40% TASK TIME
The redesign followed the sequence coordinators actually live: activate, notify, coordinate, resolve. Feedback is visible at every step, so waiting never means wondering.
Worth admitting

The biggest problem we found wasn't one we could design away. System latency was an engineering issue. What design could do was stop hiding it: giving users immediate feedback and a fallback path, so waiting never again meant wondering whether the system had heard you.

Impact

Task completion time in the redesigned flow dropped by 40% and reported system confidence rose 68% between testing rounds. The absolute values stay behind the NDA, but the direction was unambiguous: coordinators stopped describing workarounds and started describing the tool.

The full case study is gated

Screens, research artifacts, and detailed findings are protected to respect United's confidentiality. If we're talking about working together, ask and I'll send you the password.

Or email hello@studiogridline.com · I have the password

Next case study

Holding a vendor to the design system