What does a responder need when their phone is the only screen they have?

The mobile app was useful for keeping up with incidents away from a desk. But as its audience broadened, I began to question whether an experience shaped around a narrower set of users and moments could support more of the response itself. A change outside the app made that question urgent: some paths in the app still sent people to a mobile browser that was no longer a dependable fallback.

At first glance, this looked like a feature-parity problem. The app needed more of what was available on desktop. But “add more features” was not a useful enough design brief. A phone has different constraints, and not every desktop task belongs on it.

The question I needed to work through was more specific: What must a responder be able to understand and do when their phone is the only screen they have?

The gap was in the journey, not just the feature list

Consider the path someone might take after receiving an incident alert. They need to work out what happened, whether they are expected to respond, and what action is useful next. They may need to acknowledge a request, check an outage, or find the people already coordinating the response.

A notification can bring them into the app, but it cannot complete that journey. If the first screen makes the situation hard to interpret, they have to hunt for context. If “follow,” “join,” and “acknowledge” are treated as roughly the same kind of engagement, the interface can imply a commitment the person has not made. If an action sends them to a browser they cannot use, the journey stops. These were different problems, but they appeared at connected points in the same response path.

That is why I did not want to define success as reproducing the desktop portal. I wanted to identify the decision-critical moments: what someone needs to know at a glance, which actions need to work on the phone, and where the product must be honest about a limitation.

01

Deciding what belongs on the first screen

Incident and outage cards were one place to make that thinking concrete. A card could contain many useful fields, but putting everything on its first view made it harder to answer the immediate question: Do I need to pay attention to this, and what can I do next?

I worked through what belonged in the collapsed state and what could wait until expansion. Titles needed room to be understood. Ownership and other decision-relevant details needed to be findable. Supporting information still mattered, but it did not all need the same visual priority. When product feedback showed one approach added taps and made people lose their place, we went back to a more readable preview with a simpler way to reveal the rest. I also worked to make incident and outage cards feel related without flattening the differences between them.

The trade-off was not simply “less information.” It was information in the order someone could use it.

02

Making actions mean what they say

The next question was what a person should be able to do from that context. I looked closely at actions that could sound similar but serve different purposes. Following an outage to stay informed is not the same as joining the active response. Acknowledging that you have seen a request is not necessarily taking ownership of the work.

Those distinctions matter on a phone, where someone may be making a quick decision from a small amount of context. The interface needed to make the consequence of an action clear, rather than rely on familiar-sounding labels to carry more meaning than they could support.

03

When the fallback failed

The change outside the app exposed a more immediate problem: some options still offered to open content in a mobile browser, even when that destination could be blocked. I treated those paths differently from genuinely unavailable capabilities.

If an external option was redundant and led nowhere useful, it should not be offered. If the app could not yet support something the person needed, the experience should say so clearly rather than disguise the gap as a working handoff. I designed and discussed that treatment with engineering, and the broader work to remove dead ends went onto the delivery plan.

Tap an actionon a phone, mid-incident

BeforeA silent dead endA browser link that could be blocked, and no next step.

Can’t waitMake it work hereThe parts of the response that can’t reasonably wait.

Redundant linkDon’t offer itIf it leads nowhere useful, it shouldn’t be there.

Not supported yetSay soClearly, not disguised as a working handoff.

The team moved dead ends up the priority list, and a related bug that blocked joining the bridge, the live call where responders coordinate, was fixed. That fixed one path, not every blocked handoff.

This also gave “parity” a more useful definition. The goal was not to put every portal capability on a phone. It was to make the parts of the response that cannot reasonably wait possible from mobile, and to avoid promising a path the app could not complete.

Making the decisions outlast the screens

As the lead and sole mobile designer, I began documenting the reasoning behind these choices, not just the resulting screens: what belongs at a glance, how cards expand, how actions differ, and how to handle a destination the app cannot reach. That guidance was submitted for review so future decisions would not have to start from scratch.

What happened

Clearer outage cards and better-placed response actions shipped in a mobile release, alongside an at-a-glance summary of active outages that I contributed to. A product partner told me the improvements, and the walkthrough I gave stakeholders, landed well. The later work gave the team a clearer way to identify and prioritize gaps: distinguish the information someone needs immediately from deeper detail, make response actions understandable, and address browser handoffs that could strand a user.

What I can’t show yet is whether responders acknowledge or mitigate faster. One question remains especially important to me. The app’s audience had broadened, but some of its assumptions came from an earlier period. I raised the need to understand who was now using mobile, in which moments, and whether the experience we were building matched their actual jobs.

What I took away

My contribution was to move the work beyond a list of missing mobile features. I helped frame the problem as a response journey: from being alerted, to understanding what matters, to taking the next useful action without hitting a dead end. A phone doesn’t have to finish the work. It has to start it well: clear about what matters now, what you can do here, and where you’ll go next.