Context & Problem
The landscape
IMR is an incident management platform. Engineering teams use it to detect, triage, and resolve system failures. The web app is where most of the work happens. The mobile app existed mainly to wake people up.
The problem
Incidents don’t happen at desks.
Engineers respond to pages from their phones, often at 3 AM, often with one hand. The mobile app handled the notification part. It didn't handle the response part.
I used the app daily while testing builds. The pattern was consistent: open the app, read the alert, then reach for a laptop to actually do something. Most engineers I worked with did the same thing.
Diagnosis & Constraints
The hierarchy was inverted.
Status chips and incident IDs dominated each card. The incident title and affected service sat in smaller, lighter type. You had to read past the metadata to find out what broke.
The visual foundation was also inconsistent.
The original app was built by a single developer without a designer. Spacing, type scales, and color usage varied across screens. Components like buttons and inputs had no shared system behind them. I brought in the Ensō design system tokens from the web platform and adapted the core components for mobile, which gave the app consistent spacing, type, and color for the first time.
Constraints
This redesign was shaped by a few hard constraints.
Lean team
1 designer and 1 engineer, 10 weeks. I had to prioritise reuse and high-impact changes over building new systems.
Zero disruption
Engineers used the app during live incidents. I couldn't introduce interaction patterns that broke what they already relied on. Acknowledge, resolve, escalate had to stay familiar even if the layout around them changed.
Key Product Decisions
1. Hybrid design system over building from scratch
We considered building a separate mobile design system. With one designer and 10 weeks, that wasn't realistic. Starting from zero would have meant reinventing components that already worked well on web. Instead, I created Mobile Ensō as an extension of the web design system. Tokens, common components, and styles came directly from the parent system. Where mobile needed different interaction patterns (thumb-reachable actions, compact card layouts, bottom sheets), I built optimized variants that still shared the same foundation. This gave us consistency across platforms without pretending a phone works like a desktop.
2. Design for one handed, high stress use
Engineers respond to incidents from their phones at 3 AM, often holding the phone in one hand. The old app placed Acknowledge and Resolve inside the detail screen, near the top. Reaching those buttons under pressure meant navigating deeper and stretching higher.
I made one-handed reachability the primary layout constraint. Critical actions had to sit in the thumb zone. Triage had to be possible from the list itself, without opening a detail page first.
3. Restoring the web scheduling model
The previous mobile app simplified the web's layer-based scheduling into a flat list. That decision assumed layers were too complex for a small screen.
I disagreed. Engineers who manage schedules on web and check them on mobile shouldn't have to learn two different views of the same data. The layer model (overrides, primary, secondary) carries real meaning about escalation order. Flattening it removed that meaning. I kept the layers and focused on making them work on a smaller canvas instead.
The System in Action
1. High speed triage (Incident list & quick actions)
Enabling engineers to triage and resolve incidents without losing their place in the scanning flow.
Scanability & filtering
I prioritised incident status and severity over secondary metadata in the card layout. I added quick filters (My Open, All Incidents, Resolved) so responders can isolate relevant incidents from the list.
Signal over noise
I reduced the chip sizes and gave the incident title, service name, and status more visual weight. The card now leads with what broke and how bad it is.
The quick action bridge
To eliminate the friction of opening complex detail pages, I introduced a contextual bottom sheet triggered by a long-press on any incident card. This acts as a lightweight triage view, adapting to the incident's state and surfacing core actions like Acknowledge, Resolve, and Escalate directly from the list.
2. Deep context on the go (Incident Details)
Providing full situational awareness without hiding information behind tabs, while keeping actions within thumb reach.
Consolidated detail view
In the old app, finding who else was responding meant digging through tabs. I pulled responders, roles, and SLA state into the primary Details view so everything shows on one screen.
The thumb zone
I grouped common actions (Reassign, Add Responders, Escalate To) into a sticky horizontal bar at the bottom of the screen. The bar stays pinned as the user scrolls, so actions remain reachable regardless of scroll position.
3. Enterprise scheduling on a mobile canvas
Translating the web scheduling architecture to mobile, focusing on what engineers do most while away from their desks.
Layer based timeline
I brought the web's layer model to mobile. Overrides, L1, and L2 show as horizontal tracks, same as web. Users can switch between Day, Week, and Month views, and scale the timeline with zoom controls.
Contextual overrides
Core schedules get built on web. Ad-hoc overrides happen on mobile. I designed two entry points based on urgency:
Shift specific override (Planned)
Tap an upcoming shift block. The system pre-fills the start and end times of that rotation, so engineers don't have to enter times manually.
Global override (Immediate):
Tap the main override button. The form anchors to the current time. Pick a covering user and save. Two taps to secure backup.
Schedule & layer configuration
Translating enterprise schedule creation to a small screen required extreme care to prevent user errors. I designed a streamlined configuration flow:
Managing layers
Engineers can create new rotation layers, define shift lengths, and manage handoff times directly from their device.
User allocation
I built a clear, step-by-step selection pattern for adding or removing users within a specific layer, ensuring teams can dynamically update their rosters during an incident.
Review & save
Because schedule changes have massive operational impact, I ensured the 'save' flow provides clear confirmation of the structural changes before making them live.
Landscape mode
Portrait mode constrains the horizontal timeline. Rotating to landscape reveals the full multi-day view. Engineers can create overrides, manage layers, and inspect shifts from the expanded canvas. Same functionality as portrait, more space to work with.
Contextual onboarding
Three setup steps that prevent missed incidents before they happen.
The app asks for notification access during onboarding with context: real-time updates for incidents, shift changes, and critical events. Engineers who skip this step miss pages entirely.
Next, the flow prompts users to save the Zarant IMR contact card. IMR triggers phone calls for high-urgency incidents, and call loggers like Truecaller block unknown numbers by default. Saving the contact ensures critical calls bypass spam filters.
Finally, users pick separate sounds for high-urgency and low-urgency incidents. We shipped the most used sounds from the existing user base and scoped V1 to what engineers already recognized.
Product Trade-offs
AI features & Root Cause Analysis
I cut Root Cause Analysis from V1. RCA is a multi-monitor desk activity where engineers compare logs, metrics, and deployment history side by side. That doesn't translate to a phone screen.
I also excluded AI features like incident summarisation and conversational AI (Sera AI). Beyond the same concern about trust during high-stress response, AI on mobile was still too new to rely on. The interaction patterns for AI on a small screen aren't established yet, and adding unproven features to a tool engineers depend on at 3 AM wasn't a risk worth taking.
Outcomes & Reflections
Outcome
One designer, one engineer, 10 weeks from kickoff to internal alpha. Using Mobile Ensō instead of building a new system from scratch is what made that timeline possible. The mobile app now shares a design foundation with the web platform. New components built for either platform can be adapted for the other, which reduces the cost of future work on both sides.
Reflections & learnings
Designing an enterprise tool for high-stress, 3 AM emergencies requires a completely different mindset than designing a standard consumer app:
Going against the mobile convention for scheduling
The developer pitched a calendar-based approach for on-call schedules, modeled after how PagerDuty, incident.io, and Google Calendar handle it. The standard mobile pattern uses the native calendar package for iOS and Android.
I considered it, but decided against it. The web's layer view shows overrides, primary, and secondary rotations as distinct horizontal tracks. A calendar view collapses that structure. Engineers on our platform already read schedules as layers on web. Giving them a different model on mobile would have created the same mismatch I was trying to fix.
The approach we shipped gives users the full layer view on a smaller canvas. It doesn't follow the industry pattern, but it preserves the mental model across platforms. I think that trade-off was right.
Designing without a PM
No PM meant no one owned prioritization. Every scoping decision was a back-and-forth between me and the engineer. A PM would have given us a cleaner framework for what to build first and what to cut.
That said, the project stayed on track. The vision was clear enough that we didn't lose time on direction. Where it showed up was in smaller calls, like the sound fade-in feature. I designed fade-in audio for alert ringtones so engineers wouldn't get startled at late night. The developer flagged that hard-coding fade-in variants (5s, 10s, 20s, 30s) for every ringtone would add hundreds of megabytes to the app. We dropped it. A PM might have caught that constraint earlier in scoping, before I designed for it.