Amazon · Summer 2024
Redesigning a dashboard used by Amazon's security investigators — built into an existing case management system — to help them prioritize work, track progress, and act without friction.
Photos of an unreleased Amazon Echo appear online. The product hasn't been announced. How did this get out?
A security investigator — let's call her Lisa — gets assigned to find the source of the leak before more information escapes.
Lisa opens the Investigations Dashboard. She has 17 active cases and no idea where to start. The tool she relies on most is working against her.
I surveyed and interviewed 18 security investigators. What I found was people adapting to a broken tool rather than the tool adapting to them.
"I feel like I'm guessing what to do next. I just open cases randomly and hope I pick the right one."
— Security Investigator, survey responseThree challenges surfaced in nearly every interview: knowing which case to work on first, tracking progress across a large caseload, and reaching supporting teams when a case got stuck waiting on someone else.
The dashboard shows a wall of case IDs and subjects. Nothing about status, urgency, or what needs attention today. Investigators have to memorize which numbers map to which cases.
With 17 average active cases, there's no system for surfacing what's most critical. Investigators click through cases one by one, hoping to stumble onto something urgent.
Cases stuck waiting on another team showed no signal. Raj's missed deadlines happened because nothing in the interface communicated that a case had stalled — or who was responsible for unblocking it.
Before proposing anything, I audited the existing dashboard. The fundamental problem: every case was represented as a row in a table, with only the case ID and subject visible. Nothing else.
| Case ID | Subject | Opened | Status |
|---|---|---|---|
| SEC-2847 | Unreleased Product Photo Leak | Apr 2 | Active |
| SEC-2831 | Unauthorized Data Access — AWS | Mar 29 | Active |
| SEC-2819 | Supplier NDA Breach Investigation | Mar 25 | Active |
| SEC-2807 | Insider Threat — Finance Team | Mar 20 | Active |
| SEC-2794 | Third-Party Vendor Access Audit | Mar 15 | Active |
| SEC-2781 | Phishing Campaign — EU Region | Mar 10 | Active |
| SEC-2770 | Code Repository Exfiltration | Mar 6 | Active |
| SEC-2762 | Employee Device Compromise | Mar 1 | Active |
| SEC-2751 | Access Control Policy Violation | Feb 25 | Active |
| SEC-2743 | Social Engineering Attempt — HR | Feb 20 | Active |
The audit logs were just as unhelpful — timestamped entries with no context. And there was no visual distinction between a P1 case that needed immediate action and a low-priority case from three weeks ago. Everything looked the same.
The core problem
The system was built around data storage, not decision support. It showed investigators everything equally, which meant it helped them with nothing specifically.
The goal: let investigators pin specific cases to surface focused status at the top of their queue — cutting through 17 cases to show what actually needs attention that day.
I explored three directions, each with a different approach to how much information a pinned case should show.
Design B was validated through preference tests with 12 investigators and data sufficiency tests — confirming that the card showed exactly what was needed to take action without opening the full case. Engineers implemented it; I then ran usability tests measuring time-to-first-action, information clarity, and error rate.
With 17 cases to manage, investigators needed a way to quickly recall what was happening in a case without clicking into it. I tested three popover designs that appeared when hovering a case ID — each showing a different amount of information. The core question: how much detail is helpful before it becomes disruptive?
Key finding
The dense popover gave investigators enough information to assess and act on a case without opening it — effectively a triage tool that didn't interrupt their flow. Investigators using option C were significantly faster at identifying bottlenecks than those using any pop-up or full-card alternative.
| Case ID ↕ | Investigation | Opened ↓ | Lead | Status |
|---|---|---|---|---|
|
SEC-2847
|
Unreleased Product Photo Leak | Apr 2 | L. Chen | Investigating |
|
SEC-2831
|
Unauthorized Data Access — AWS | Mar 29 | R. Patel | Bottlenecked |
|
SEC-2819
|
Supplier NDA Breach Investigation | Mar 25 | L. Chen | Active |
Early in research I assumed the problem was investigators couldn't identify bottlenecked cases. I was wrong. They knew cases were stalled — what they didn't know was where in the process the stall was occurring and who owned it.
I designed a stage tracker embedded within each case, showing the investigation lifecycle as a series of steps with clear ownership and status at each one. The key insight: show investigators not just that a case is stalled, but exactly which step owns the block — and whether that block is preventing downstream steps from starting at all.
This component was validated through concept and usability testing. The design shown above — stage bar with ownership labels, days stalled, and escalation contact — was consistently preferred. Investigators described it as "finally seeing where the fire actually is."
Across all three features, the redesigned dashboard showed substantial improvements in every usability dimension measured. The system went from something investigators actively avoided to a primary tool for starting and managing their day.
Measured results
SUS 61 → 88 — usability score across all three features. Time-to-first-action dropped significantly on the priority queue. Bottleneck identification went from "unknown" to correctly located on the first try for every test participant.
User-centered design is only as good as the research behind it. The bottleneck insight — that investigators needed location, not detection — only came from going deeper than surface-level complaints. If I'd stopped at "they can't find bottlenecks," I would have built the wrong thing.
Iteration isn't just changing the design. Each round of testing with investigators produced specific, actionable feedback that changed not just the visuals but the underlying information hierarchy. The SUS jump from 61 to 88 didn't come from polish — it came from repeatedly asking "does this actually reduce your decision-making time?"
Collaboration across functions changes what you build. Working closely with engineers shaped what was feasible; working with investigators shaped what was necessary. Neither alone would have produced the same outcome.