Microsoft · Incident response
During a major outage, everything looks urgent. How do you help someone decide what matters now?
Designing for the questions a static dashboard couldn’t answer.
- Role
- Lead designer for key outage experiences and a dashboard redesign; collaborator on an AI-assisted summary; lead designer for an AI-assisted prioritization experience
- Partners
- Product management, engineering, research, operations experts, adjacent design teams
- Timeline
- 2023 to 2026
- Status
- Shipped in phases, latest release in 2026
During an outage, a number can be accurate and still leave the most important question unanswered.
Imagine a dashboard showing 100 customers impacted. Has that number barely moved for hours? Or was it much lower a short time ago and has just jumped? Those situations call for different attention, but a snapshot makes them look the same.
That gap, between seeing information and understanding what it means now, connected my work across an outage hub, a dashboard redesign, and an AI-assisted experience that helps people identify which outages deserve attention first. The primary users of the dashboard were incident managers coordinating active responses and executive incident managers scanning across events. They needed to answer practical questions quickly: What’s happening? What has changed? Is the right response underway? Where should I look first?
What’s happening?
In the earlier hub work, I designed widgets that brought useful outage information closer to where people were already working. I also collaborated on an AI-assisted summary that helped people get oriented without piecing together the situation from multiple places. It was a team effort, not a feature I designed alone.
The summary’s value reached beyond the immediate response team. A senior executive described it as the Copilot capability he used most: it helped him understand an active outage without having to join the live response call. I see that as a particularly meaningful signal, not because a leader liked a feature, but because it showed that the need for a clear, current account of an outage extended to people making decisions around the response.
That work sharpened a larger question for me: What context can the product provide before someone has to leave the page, open another view, or interrupt the response to ask?
Has the impact changed recently?
The dashboard redesign brought that question into focus. Its impact columns showed current totals, but a total alone did not reveal whether something had changed meaningfully in the recent past. Someone scanning outages had to remember earlier values or investigate elsewhere to spot a sudden increase.
I designed impact-momentum indicators to put a signal beside a number that needed attention. In the example above, an arrow next to 100 would not mean “100 is bad” or “the outage is getting worse overall.” It would mean that this particular impact measure had increased enough over a recent comparison window to warrant a closer look. The count supplied magnitude; the arrow supplied context about recent change.
Getting that distinction right changed the visual design. We explored multiple arrows to express different rates of change, but research participants found them too busy for a dashboard they needed to scan quickly. We moved toward a single arrow on the row, with more detailed comparisons available on inspection. We also avoided showing a routine “stable” arrow so the important signals would stand out. In a small validation study, every participant said seeing direction closed a real blind spot.
No arrow did not mean “recovering,” and there was no down arrow either. Recovery is owned by a separate product team, and bringing the story of recovery into the dashboard needed alignment across both teams first. Until then, the arrow had one job: flag a recent increase.
Is anyone on it?
Impact was only part of the picture. The previous dashboard reduced responder engagement to a limited status. Incident managers needed a clearer way to understand where the response stood, for example, whether the people expected to respond had been notified or had acknowledged, without treating those states as interchangeable.
Where I got it wrong
I worked on an at-a-glance engagement treatment, then learned in research that some of our initial icons did not communicate what we intended. An envelope, for instance, read to participants as an email being sent rather than a clear signal about the response. We revised the design rather than expecting people to learn an ambiguous visual code. Under pressure, an icon’s first reading matters more than the explanation behind it.
Which one needs attention first?
Making individual rows clearer did not solve the whole problem. When many outages appeared together, the dashboard still asked people to scan a flat set of results and determine for themselves where to focus. I led the design of a prioritization layer that brings potentially important outages forward and explains why they were surfaced.
The principle was to keep the signals behind that prioritization understandable and inspectable. AI could help explain context, but it should not quietly become the source of truth for what mattered most. I owned the work from research through engineering handoff, and it shipped in May 2026.
What happened
The earlier hub work was associated with improved user satisfaction, and the AI-assisted summary was reported to save responders time. Its use by a senior executive was another signal that a concise, current summary addressed a real need. The redesigned dashboard’s impact and engagement indicators shipped, and so did the prioritization experience, while research both supported the value of the direction and exposed details we needed to change. These are meaningful outcomes, but they are not proof that my design reduced outage duration or mitigation time.
The harder problem remains one of trust. An arrow can make a recent jump visible; it cannot tell a responder why the jump happened. Research surfaced cases where a newly linked record could make impact appear to spike. Was that new impact, or a change in how existing impact was recorded? The interface could draw attention to the change, but it could not settle that question on its own.
What I took away
Across these efforts, my focus shifted from presenting outage information to helping people interpret it without overstating what the data knows. The most important change was not an arrow, a status icon, or a summary in isolation. It was designing around the questions people actually had when the situation was still unfolding.