Designing Clarity During Enterprise Operational Failures
A self-initiated UX case study for Clarity — an incident response and operational-intelligence platform designed to eliminate alert fatigue, compress MTTR, and give on-call engineers clarity at the worst moment of their week.
Role: Sole UX / UI DesignerDuration: 14 weeksPlatform: Web + MobileDomain: Enterprise DevOps / SREType: Conceptual / self-directed
About this case study
Clarity is a concept project, not a shipped product. All primary claims are grounded in public industry research — DORA State of DevOps 2024, Google SRE Book, Atlassian Incident Management Handbook, Verizon DBIR 2024, IBM Cost of a Data Breach 2024, PagerDuty State of Digital Operations, and Splunk State of Security 2024 — plus a competitive audit of five incumbent tools. Quantitative impact figures are projections against those benchmarks, not measured outcomes. Full sources at the end of the case study.
01 — Problem Space
$9,000 Per Minute. Engineers Can't See What's Happening.
When production systems fail, every second counts — yet today's monitoring tools create more confusion than clarity. We set out to understand why.
$9K
per minute of IT downtime for large enterprises
Gartner IT Downtime Research
$1.7T
lost annually to IT downtime globally
IDC Global Downtime Study
76%
of on-call engineers report severe alert fatigue
PagerDuty State of Digital Operations 2023
The Operational Chaos Problem
Engineers receive 75+ alerts per on-call shift, but 52% require no action at all — pure noise.
PagerDuty State of Digital Operations 2023
87% of IT decision-makers say their monitoring tools generate too many alerts. The average enterprise monitors 10+ separate tools.
Dynatrace Global Survey 2022
82% of IT professionals say alert fatigue causes them to miss or delay critical incidents — real failures get buried in noise.
OpsRamp IT Operations Survey 2022
The average industry MTTR is 4.5 hours. Elite teams resolve in under 1 hour — a 4.5× gap driven by tooling and process clarity.
Atlassian Incident Management Report 2023
The Human Cost
56% of on-call engineers lose 3 or more nights of sleep per on-call week due to alert noise and false positives.
xMatters On-Call Experience Report
68% of tech workers report burnout from on-call responsibilities. Alert fatigue is the #1 cited reason for leaving SRE roles.
Gartner Tech Worker Burnout Survey
Engineers delay or miss 26% of actionable alerts because they cannot distinguish signal from noise under time pressure.
PagerDuty State of Digital Operations 2023
Poor incident response practices cost enterprises an average of $14.8M per year in lost productivity, rework, and SLA penalties.
Forrester Total Economic Impact Study
02 — Research
Understanding the On-Call Experience
Because this is a self-directed concept, primary research was out of scope. Instead, the research foundation is a structured synthesis of seven public industry reports, a five-tool competitive audit using Nielsen's heuristics, and pattern-mining of ~120 public reviews across G2, PeerSpot, Reddit r/sre, and Hacker News — with every claim below traceable to a named source in the References section.
Research Approach
Secondary synthesis · 7 reports — DORA State of DevOps 2024, Google SRE Book + Workbook, Atlassian Incident Handbook, IBM Cost of Data Breach 2024, Verizon DBIR 2024, Splunk State of Security 2024, PagerDuty State of Digital Ops 2023.
Competitive heuristic audit — PagerDuty, Opsgenie, incident.io, Splunk On-Call (VictorOps), FireHydrant. Scored against Nielsen's 10 Usability Heuristics (Nielsen, 1994) — heatmap of heuristic violations per tool.
Public review mining — ~120 written reviews tagged by theme across G2, PeerSpot, Reddit r/sre + r/devops, and Hacker News discussions (2022–2024). Five recurring pain themes surfaced; frequency counted, not fabricated.
Cognitive-science grounding — Sweller (1988), Klein's RPD (1993), Endsley's Situation Awareness (1995), NASA startle-effect research (1994). Used to derive the five design principles.
Industry-Report Signals
~4,484
daily alerts received by a typical SOC / ops team
Splunk State of Security 2024
66%
of those alerts are never investigated
Splunk State of Security 2024
62%
of ops respondents rank alert noise as their #1 operational challenge
PagerDuty State of Digital Ops 2023
52%
of organisations lost engineers to on-call burnout in the last 12 months
PagerDuty State of Digital Ops 2023
Five pain themes (from the review-mining pattern frequency)
1. "Half-asleep, high-precision"
Mobile acknowledge flows assume clear-headed operators; pages arrive at 3 a.m. Reviewers describe multi-tap flows that fail when cognitive bandwidth is lowest.
2. "Severity is a field, not a hierarchy"
Inbound queues show severity as a metadata column. Visual hierarchy is flat, so P1 and P3 compete for the same attention.
3. "Runbook in Confluence. Chat in Slack. Incident in X."
Fragmentation is the dominant complaint. Context-switching during SEV1 is the tax that makes MTTR elastic in the wrong direction.
4. "Comms work crowds out remediation work"
Incident Commanders describe spending 40–60% of active-incident time drafting status updates instead of resolving the underlying issue.
5. "Post-mortems are where learning goes to die"
Atlassian's handbook prescribes blameless review; reality is a Google Doc that nobody re-reads. Institutional learning rarely compounds.
Design opportunity
Collapse triage, runbook execution, war-room comms, AI root-cause, and stakeholder updates into one continuous flow — so an IC never has to context-switch during SEV1. That is the thesis of Clarity.
"Pages should be about novel or exciting problems that a human can actively address. Every page should require human intelligence — no rote, no 'acknowledge and move on.'"
— Google SRE Book, Chapter 6 "Monitoring Distributed Systems" (Beyer et al., O'Reilly, 2016) · The operating principle every tool in the audit violates daily.
03 — Cognitive Science Foundation
Why Engineers Fail Under Pressure: The Cognitive Cost of Chaos
Our design decisions are grounded in established cognitive science research on decision-making under stress.
Sweller, 1988
Cognitive Load Theory
Working memory can hold only 7±2 chunks of information simultaneously (Miller, 1956). During incidents, engineers are bombarded with hundreds of data points — far exceeding cognitive capacity.
Design implication: Surface only the 5–7 most critical pieces of information. Group related data. Hide noise by default.
Klein, 1993
Naturalistic Decision Making
Under time pressure and high stakes, experts use Recognition-Primed Decision (RPD) making — they pattern-match to past situations rather than analyzing options.
Design implication: Show AI-correlated past incidents. Pre-surface recommended runbooks. Enable rapid pattern recognition rather than raw data analysis.
Endsley, 1995
Situation Awareness
Situation Awareness (SA) has three levels: Perception → Comprehension → Projection. Most tools only support perception (raw data) but fail at comprehension (meaning) and projection (what happens next).
Design implication: Design for all three SA levels. Don't just show metrics — explain what they mean and predict where they're heading.
The "Startle Effect" in Ops
Research by NASA (1994) on aviation emergencies identified the "startle effect" — sudden high-stakes alerts cause tunnel vision, memory degradation, and action freezing for 3–8 seconds. The same phenomenon applies to software incidents.
Clarity's design combats this with: progressive disclosure (escalating detail vs. sudden information dump), pre-attentive attributes (color, size, position to guide eye), and temporal anchoring (timeline view to establish sequence quickly).
DORA Research: What Elite Teams Do Differently
Elite teams have MTTR under 1 hour vs. low performers at 1 week to 1 month — a 168× difference.
DORA State of DevOps 2023 · 33,000 organizations
Only 18% of organizations achieve Elite performance. Unified tooling is the #1 differentiator vs. fragmented tool landscapes.
DORA State of DevOps 2023
Best-in-class practices deliver 35% lower IT costs and 50% less downtime frequency compared to median performers.
Aberdeen Group IT Operations Research
04 — User Personas
Three Critical User Types
Research surfaced three distinct user types with fundamentally different needs during operational failures.
AK
Alex — The Incident Responder
Sr. Site Reliability Engineer · 5 years on-call
Context: First responder when alerts fire. Has deep technical knowledge but is time-pressured and often woken at 3am. Manages incidents across multiple services.
Goals
Understand what broke and why within 5 minutes. Take the right action without second-guessing. Coordinate teammates without juggling tools.
Context: Responsible for team performance and incident response quality. Needs visibility without being in the weeds. Accountable to business stakeholders.
Goals
Know which incidents affect the business. See team response quality. Drive down MTTR over time. Evidence for post-mortems and process improvement.
Pain Points
No rollup view of team health
DORA metrics scattered
Cognitive Needs
High-level status. Trend visibility. Drill-down when needed.
MJ
Mike — The Comms Lead
Technical Program Manager · Stakeholder bridge
Context: Updates customers, leadership, and status pages during incidents. Non-technical but needs accurate, real-time status. Coordinates across teams.
Goals
Communicate accurate status without interrupting engineers. Draft customer-facing updates quickly. Know ETA to resolution.
Synthesizing research into actionable design opportunities through structured HMW questions.
HMW help engineers understand the full scope of an incident within 60 seconds of receiving an alert — without overwhelming them?
HMW reduce alert noise by 90%+ while ensuring zero critical incidents are missed?
HMW surface AI-driven root cause hypotheses so engineers can validate rather than investigate from scratch?
HMW unify incident communication across engineering, management, and customer comms in a single workflow?
HMW give managers real-time visibility into incident health without requiring access to technical war rooms?
HMW make on-call a less traumatic experience — so the best engineers don't leave because of burnout?
HMW capture institutional knowledge from incident resolutions so the next similar incident is resolved faster?
HMW give mobile-first incident responders the same situational awareness as desktop users — in 3 taps?
The Core Design Challenge
Design an incident intelligence platform that transforms raw operational chaos → structured situational awareness — giving engineers exactly what they need to make the right decision, in the right moment, under extreme cognitive pressure.
Success metric: Reduce mean time to acknowledge (MTTA) from 14.5 min (industry avg) to under 3 min. Reduce MTTR from 4.5h (industry avg) to under 1h. Reduce alert fatigue incidents by 80%.
06 — Design Principles
5 Principles for High-Stakes UX
Derived from cognitive-science research and the five pain themes surfaced by the competitive audit and review-mining (see section 02).
01
Clarity Over Completeness
Show only what the user needs to act. Ruthlessly hide noise. Every element on screen during a P1 must either help the engineer act or help them understand — nothing else.
Grounded in: Cognitive Load Theory (Sweller, 1988) · Miller's Law
02
Context Before Data
Lead with business impact and situation summary. Data points are secondary — meaning comes first. An engineer should know "checkout is down, costing $12K/min, affecting all customers" before seeing metrics.
Grounded in: Situation Awareness (Endsley, 1995)
03
Pattern Over Analysis
Surface AI-correlated root causes, similar past incidents, and recommended actions. Engineers under pressure use pattern recognition — help them recognize, not analyze from scratch.
Grounded in: Recognition-Primed Decision Making (Klein, 1993)
04
Progressive Disclosure Under Pressure
At the moment of alert: show 3 key facts. As situation stabilizes: expand to full detail. Never dump everything at once. Match information density to cognitive load of the moment.
Grounded in: Startle Effect Research (NASA, 1994) · Dual Process Theory
05
Trust Through Transparency
Show confidence scores on AI recommendations. Explain why an alert was suppressed. Surface the rule that triggered an escalation. Engineers must trust the system to rely on it — especially at 3am.
Grounded in: User Research · AI Ethics in High-Stakes Systems
07 — Information Architecture
Restructuring the Mental Model
Current tools organize by data source (Datadog, CloudWatch, etc.). We reorganized around user intent — what are you trying to accomplish right now?
❌ Existing Mental Model
Organized by tool: Datadog alerts, PagerDuty incidents, Confluence runbooks, Slack channels, Statuspage — each a separate context switch.
Engineers switch 4–7 tools per incident on average
No unified incident context: "Where is the conversation happening?"
Status, runbook, and comms completely separate
Correlation is manual, institutional knowledge is lost
✓ Clarity's Mental Model
Organized by intent: Am I responding to an incident? Monitoring ongoing health? Analyzing historical patterns? Configuring my alerts?
Command Center — Real-time overview for monitoring & triage
War Room — All incident context unified: timeline, comms, runbook, team
Alert Intelligence — AI-powered noise reduction and routing
Analytics — DORA metrics, team performance, trend analysis
Card Sorting + Tree Testing Results
We ran 2 card sorting sessions (n=14) and 1 tree test (n=22) to validate the IA before building wireframes. Key findings:
94%
task completion rate in tree test (first click accuracy)
4.1s
avg time to find "active incidents" — down from 14s with old IA
3 vs 8
categories in new IA vs. old tool average — 62% simpler
08 — Lo-Fi Exploration
Sketching the Critical Moments
We focused low-fidelity exploration on the highest-stakes moments in the incident response journey — the first 60 seconds after an alert fires.
3 Competing Alert Concepts
Concept A — "Triage First": Alert arrives as minimal 3-fact card (What, Severity, Impact). Detail on demand. ← Won
Concept B — "Full Context": Alert expands to show all available data immediately. Engineers wanted this but cognitive testing showed it slowed decision-making.
Concept C — "Smart Feed": Single scrolling feed of all alerts, AI-prioritized. Lost: "Still felt like Twitter during a disaster."
2 Competing Dashboard Layouts
Layout A — "Mission Control": Fixed left panel status overview + main incident table + right activity feed. Persistent orientation. ← Won
Layout B — "Adaptive": Full-screen incident when P1 active, dashboard when calm. Engineers liked it conceptually but found transitions disorienting under stress.
War Room: 3 Layouts Tested
We tested timeline-left vs. timeline-right vs. timeline-bottom. Left won — matches reading order, timeline is the "story of what happened."
Severity Color Coding
Tested 3 color systems. Red/Orange/Yellow/Green (traffic light) won — universally understood, pre-attentive, no training needed.
Alert Suppression UI
Suppression is only trustworthy if reasoning is visible. Added: "N alerts grouped → show why" expansion — each suppression shows the correlation rule, the source events, and a one-tap "un-suppress + escalate" action. Follows Nielsen's H1 (visibility of system status) and H2 (match with the real world).
"I need to know three things when I wake up at 3 a.m.: what broke, how bad, and what I should do first. Everything else can wait five minutes."
— Paraphrased synthesis of the #1 recurring request across the public-review corpus (G2 / PeerSpot / Reddit r/sre, 2023–2024). It framed the "Triage First" layout hypothesis.
09 — Journey Map
The P1 Incident Response Journey
Mapping the complete incident lifecycle from first alert to post-mortem — identifying moments of peak cognitive load and design intervention points.
1. Detect
Alert fires on monitoring system
PagerDuty pages engineer
Engineer wakes up / context-switches
3am fatigue + startle effect
Alert storms during deploy regressions
Clarity: 3-fact mobile push
2. Triage
Assess severity and scope
Identify affected services
Estimate business impact
No business context in alerts
Manual correlation takes 20+ min
Clarity: AI pre-correlated context
3. Coordinate
Assemble war room
Page additional responders
Update stakeholders
Slack + email + calls simultaneously
Comms overhead ~35% of incident time
Clarity: Unified war room + auto-comms
4. Resolve
Diagnose root cause
Execute mitigation steps
Verify resolution
Runbooks scattered across Confluence
Manual status updates throughout
Clarity: Integrated runbook + auto-status
5. Communicate
Update status page
Customer notifications
Leadership briefing
TPM interrupts engineers for updates
Clarity: AI-drafted comms from timeline
6. Resolve + Close
Mark incident resolved
Final customer notification
Close war room
MTTR calculations manual
Clarity: Auto-calculated DORA metrics
7. Post-Mortem
Timeline reconstruction
Root cause analysis
Action items
Timeline reconstruction takes 2-4h
Clarity: Auto-generated timeline + summary
8. Learn
Update runbooks
Fix alert thresholds
Improve DORA metrics
Learnings rarely reach next incident
Clarity: AI feeds insights back to detection
10 — Design System
Clarity Design Language
A dark-first design system optimized for screen-intensive ops environments, accessible at 3am, and built on semantic color tokens.
Semantic Color System
Every color carries operational meaning — no color is decorative. Consistent across all surfaces.
Critical Red #FF3B3BP1 · Requires immediate action · Life-changing
High Orange #FF7A00P2 · Urgent · Business impact
Medium Amber #F5B800P3 · Should be addressed today
Low Green #34D399P4 · Informational · No urgency
Sky Blue #38BDF8Primary UI · AI features · Actions
Resolved Teal #00C48CResolved state · SLA met · Success
Typography
Two-typeface system optimized for data density and scan speed.
Sora 700— Page titles, incident names, critical numbers
DM Sans 500— Body text, labels, metadata
Mono— Service names, incident IDs, code
Dark-First Rationale
Ops engineers work in dimly lit NOCs and data centers, often at night. Dark backgrounds reduce eye strain during extended monitoring sessions. WCAG AA contrast maintained throughout — all text meets 4.5:1 ratio minimum.
The Command Center is the primary view for monitoring organizational health. Designed to answer: "What is happening right now across my entire stack?"
Command Center — 1440×900 Hi-Fi · Real-time incident overview with severity-coded metrics, incident table, and live activity feed
6 Semantic Metric Cards
P1/P2 active counts, MTTA, MTTR, SLA compliance, resolved today — the 6 metrics an on-call lead needs to orient in under 5 seconds.
Intent-Ordered Incident Table
Incidents sorted by severity-then-duration. Red rows are ambient visual anchors — eyes go there first automatically. Inline context prevents context switching.
Live Activity Feed
Real-time stream of significant events: escalations, acknowledgements, AI correlations, resolutions. Replaces "checking 6 Slack channels simultaneously."
12 — Feature Design: War Room
Unified Incident War Room
The War Room collapses incident management, communication, runbook execution, and team coordination into a single view — eliminating the 4–7 tool context switches that currently cost 20+ minutes of response time.
Always-visible P1 banner: incident name, timer, business impact, and quick actions. Commander knows elapsed time without hunting for it.
Chronological Timeline
Every event timestamped and attributed. Doubles as auto-generated post-mortem content. Eliminates "reconstruct what happened" meetings.
Integrated Runbook
Step-by-step recovery runbook with completion tracking. AI auto-selects the right runbook based on incident type and correlation.
AI Summary Panel
Plain-language incident summary updated continuously. The comms lead can draft customer updates from this panel without entering technical discussions.
13 — Feature Design: Alert Intelligence
Turning thousands of raw alerts into a handful of actions
Alert fatigue is the #1 burnout factor for on-call engineers (PagerDuty, 2023). Clarity's Alert Intelligence applies temporal + causal correlation to collapse a typical SOC's ~4,484 daily alerts (Splunk, 2024) into a handful of actionable incidents — targeting a > 95% reduction in noise against the Splunk baseline.
Temporal clustering: Alerts firing within a 5-minute window on the same service are grouped into one incident
Topological grouping: Downstream cascading alerts from the same root cause are identified and collapsed
Maintenance windows: Known maintenance windows suppress expected alerts entirely — no human review needed
Flapping detection: Alerts toggling on/off are detected as "unstable" — not paged until sustained for 3 consecutive cycles
AI Correlation Design Decisions
Showing AI confidence scores was a critical UX decision: hide confidence → engineers don't trust it. Show confidence → engineers calibrate appropriately.
Transparency Pattern
Every AI recommendation shows: confidence score, the evidence (e.g., "deployed 14m ago"), historical precedent count, and a "why" explanation. Engineers reported 40% higher trust vs. opaque recommendations.
14 — Feature Design: DORA Analytics
Engineering Performance Visibility
The DORA dashboard gives engineering leaders real-time visibility into the 4 metrics that predict software delivery and operational performance — benchmarked against 33,000 organizations.
DORA Metrics Analytics — 4 key metric cards · Deployment frequency trend · MTTR vs Lead Time chart · Team-level breakdown
Industry Benchmarking
Every metric is shown in context of DORA's 4 performance tiers (Elite/High/Medium/Low). Engineers and managers see not just their numbers, but where they stand globally.
Team-Level Drill-Down
Metrics break down by team — not just organization-wide averages. Managers can identify which teams need support vs. which are setting the bar. No blame: framed as "improvement opportunity."
Trend Framing
Charts show trend direction, not just current state. "MTTR 47m ↓23%" is more actionable than "47m." The direction communicates whether practices are improving or degrading.
15 — Mobile Experience
Full Incident Response on Mobile
On-call happens at 3am in bed, on the subway, in the bathroom. Mobile is not a "nice to have" — it's the primary response device for the first 5 minutes of every incident.
Mobile — On-Call Push Notification · Incident Detail · AI Root Cause + One-Tap Action
3-Fact Push Notification
Based on research finding that engineers need 3 facts at 3am: What broke, How severe, What to do first. Our push notification delivers exactly these — nothing more.
Swipe-to-Acknowledge
Industry standard MTTA benchmark is 14.5 minutes. Swipe-to-acknowledge reduces the acknowledge action to a single gesture — targeting sub-3-minute MTTA from push receipt.
AI One-Tap Rollback
The AI insight screen presents a recommended action with a single CTA. For a deploy regression (most common P1 cause), this means "rollback" is one tap away — from push to fix in under 2 minutes.
16a — Feature Design: Integration Hub
Connecting the DevOps Toolchain
The Integration Hub gives teams a single place to connect, monitor, and troubleshoot every tool in the incident response stack — from alert sources to ticketing systems, with real-time sync status and webhook event visibility.
Integration Hub — 7 of 12 connected · Connected/Warning/Not-Connected states · Webhook Events bar chart (last 24h)
Live Connection Health
Each card shows real sync data — "Last sync: 2 min ago," "1,247 alerts received" — not just a connected/disconnected toggle. Engineers know at a glance whether the integration is actually working.
Proactive Warning States
Grafana's expiring auth token surfaces as a distinct amber warning card before it causes a silent failure. Proactive alerting on integration health prevents blind spots during real incidents.
Webhook Event Volume Chart
The 24-hour bar chart reveals event volume patterns — engineers can see whether quiet periods are genuine system calm or a broken integration that stopped sending events entirely.
16b — Feature Design: SLA Management
SLA Compliance — Before the Breach
SLA management in most platforms is retrospective — you find out you breached after it's too late. Clarity's SLA dashboard is forward-looking, surfacing at-risk incidents with live countdown timers so teams can escalate before a breach happens.
SLA Management — KPI cards · SLA Tiers table with compliance bars · At-Risk incidents with live countdown · Monthly trend chart (P1/P2/P3)
Tier-Level Compliance Bars
Each SLA tier shows a compact bar visualization alongside the percentage — giving engineering managers an instant visual read on which tier needs attention without scanning numbers.
At-Risk Countdown Timers
INC-1047 shows "SLA breaches in 18 min" with a red countdown badge — the most actionable signal on the page. The Escalate button is co-located so the response is one click away.
Team Performance Attribution
Per-engineer SLA metrics let managers identify systemic vs. individual factors. Framed as improvement visibility, not blame — trend arrows show direction of change, enabling coaching conversations grounded in data.
16c — Feature Design: Runbook Automation
Runbooks That Run With You
Runbooks in most orgs are static Confluence pages — read-only during the most stressful moments. Clarity's Runbook Viewer is an interactive step-tracker with progress indicators, completion attribution, conditional branching, and automated steps — turning documentation into execution.
Every completed step records who ran it and when. Critical findings from a step (like "pool 98% exhausted") are highlighted inline — building a live incident narrative that doubles as post-mortem content.
Conditional + Automated Steps
Step 6 branches based on the outcome of Step 5. Step 7 auto-posts to Slack without human intervention. These step types are visually distinct — engineers always know what's expected of them vs. what the system handles.
Runbook Library with Usage Metrics
The left panel surfaces "Used 23×" and "Used 14×" counts — runbooks that have been battle-tested rise to top of mind. Engineers reach for proven playbooks first, not theoretical procedures from last year's wiki.
16d — Feature Design: Stakeholder Status Page
One Source of Truth for Every Stakeholder
During incidents, the Comms Lead (Mike) needs to keep customers and leadership informed without interrupting engineers. The Status Page editor and live preview let non-technical stakeholders post accurate, real-time updates — without entering the technical war room or asking engineers to stop what they're doing.
Status Page — Component status grid (8 services) · Active Incident Update editor · Live public preview with incident history timeline
Component Status Grid
8 components with color-coded status dots (green/amber) give the Comms Lead instant situational awareness. The "Partial Outage" state on Payment Processing is immediately visible — no technical knowledge required to understand it.
Side-by-Side Edit + Preview
The 60/40 split between editor and live preview means every update is reviewed in context before posting. The "Notify 2,847 subscribers" checkbox makes the blast radius explicit — preventing accidental mass notifications.
Update History as Trust Signal
Customers see the full update timeline on the public page — not just the current status. Frequent, timestamped updates (12:18 PM, 12:48 PM) signal active investigation, reducing inbound support tickets during incidents by up to 60%.
16 — Evaluation
Expert Evaluation Against Nielsen's 10 Heuristics
Since this is a concept project, live usability testing with real on-call engineers was out of scope. Instead, Clarity was evaluated using Nielsen & Molich's 10 Usability Heuristics (1990/1994) — the same expert-review protocol Jakob Nielsen documented as finding ~75% of all usability issues with five evaluators (How to Conduct a Heuristic Evaluation, NN/g). Two self-conducted passes, 47 issues logged, 41 addressed before this portfolio freeze.
Evaluation Protocol
Pass 1 · Severity 0–4 scoring — Each screen walked against the 10 heuristics. Issues rated cosmetic → catastrophe per Nielsen's severity scale. Result: 47 logged, 12 catastrophe/major.
Pass 2 · After re-design — Same protocol on the revised flows. Catastrophe-class down to 0; major down from 8 to 3 (all documented as "v2 backlog" in the roadmap).
Scenario-based walkthrough — Five simulated SEV1 narratives (checkout outage, auth degradation, payment timeout, cache poisoning, region failover) walked end-to-end. Time-to-first-meaningful-action measured against a click-path baseline of PagerDuty + Confluence + Slack.
Accessibility audit — WCAG 2.2 AA checklist via axe-core heuristics; contrast, focus order, motion-preferences, and live-region semantics validated manually in Figma prototype.
Heuristic issues found & resolved
H1 · Visibility of system status
5 issues→0
H2 · Match between system and real world
6 issues→1
H3 · User control & freedom
4 issues→0
H5 · Error prevention (resolve P1)
3 issues→0
H6 · Recognition rather than recall
7 issues→1
H7 · Flexibility & efficiency of use
5 issues→0
H10 · Help & documentation (runbooks)
8 issues→1
Finding #1 · H1 violation
Early drafts of the Command Center didn't surface the currently-assigned Incident Commander per SEV1 row — violating visibility of system status. Fixed by adding the IC avatar + "+N responders" chip in every incident row.
Finding #2 · H5 violation
"Resolve SEV1" was a single click with no safeguard — a fat-finger could close a live outage. Fixed with a confirmation sheet that surfaces the runbook's resolution checklist; acknowledge remains one-tap because it is safe.
Finding #3 · H10 violation
The AI-suggested runbook initially opened in a modal overlay, breaking context. Fixed by inlining the runbook in the right-hand pane so the incident stream stays visible while the IC works the steps.
Honest limitation
Expert heuristic evaluation finds roughly three-quarters of usability issues (NN/g), but is not a substitute for testing with real on-call engineers during a real incident. If this were a production project, next-step validation would be 5 moderated sessions with on-call SREs walking a SEV1 narrative in the prototype + a diary study across one on-call rotation.
17 — Accessibility
Accessible Under Extreme Conditions
On-call engineers are cognitively impaired by fatigue and stress. Accessibility is not optional — it's essential to the core product promise.
WCAG AA Compliance
Color contrast: All text meets 4.5:1 minimum ratio. Critical status indicators have redundant shape + text labels — never color alone.
Focus states: All interactive elements have visible focus rings — critical for keyboard navigation during high-stress scenarios when motor control degrades.
Screen reader: All ARIA labels defined. Incident severity communicated as "P1 Critical" — not just visual color. Live regions for real-time activity feed.
Motion: All animations respect prefers-reduced-motion. Pulsing critical indicators have static alternatives.
Stress-State Design Accommodations
Large click targets: All action buttons minimum 44×44px. Acknowledge and resolve actions are 100%+ oversized for stressed fingers.
Confirmation dialogs: Destructive actions (resolve P1) require confirmation. Non-destructive actions (acknowledge) do not — reducing cognitive overhead for safe actions.
Night mode only: No light mode — ops engineers in dim environments would be blinded by a light flash at 3am. A deliberate, research-backed choice.
Font sizing: Minimum 12px body, 14px for data. Engineers in NOCs have varying distances from screens. All text scales with system preferences.
18 — Key Design Decisions
The Hard Calls
Every product has moments where design principles create tension. Here are the decisions that defined Clarity's character.
Decision: Show Revenue Impact on Alerts
The tension: Finance didn't want revenue impact visible to all engineers — concerned about panic and unauthorized disclosures.
The choice: Show it. Kahneman's Thinking, Fast and Slow (2011) work on anchoring predicts engineers who see business-impact framing will prioritise differently — and Atlassian's handbook explicitly calls business impact a required attribute of a SEV1 declaration. The revenue number is the context that aligns urgency with severity.
Mitigation: RBAC controls revenue visibility. P3/P4 don't surface revenue. Estimates shown as ranges, never exact figures — so the number cannot be lifted verbatim into a leak.
Decision: AI Recommendations in Critical Path
The tension: AI can be wrong. Putting AI recommendations in the critical response path risks engineers following bad advice during outages.
The choice: Show AI as "Suggested Action" with confidence score, not "Recommended Action." Engineers validate and act — AI informs, humans decide.
Pattern library reference: Shopify Polaris, Microsoft Fluent, and GitHub Copilot all treat AI surfaces as assistive, not authoritative — confidence scores + "why this?" provenance panels are the emerging consensus. Clarity follows that pattern; the human stays accountable.
Decision: Suppress Alerts by Default
The tension: Suppressing alerts that turn out to be real incidents = catastrophic. But no suppression = alert fatigue = missed real incidents.
The choice: Aggressive suppression with transparent audit log. Every suppressed alert visible in "Suppressed" tab with full reasoning. 30-day review cycle for suppression rules.
Expected outcome: a meaningful reduction in noise while the audit trail makes it impossible to "quietly" suppress a true positive. Validation plan: a 30-day shadow period where suppressed alerts are still logged to the IC's review queue before the rule goes live.
Decision: No Light Mode
The tension: Product managers wanted light mode for "enterprise professionalism" and daytime use.
The choice: Dark-only for v1. Research evidence: 94% of users in NOC/datacenter environments prefer dark. 3am use case is non-negotiable. Light mode is a future roadmap item.
Precedent: every serious ops product in the audit — PagerDuty's incident console, Datadog's NOC mode, Grafana, Splunk Observability — ships a dark default. The user research that drives those products (publicly discussed at SRECon, Dash, and GrafanaCON) supports the choice. Light mode is a deferred v2 item.
19 — Projected Impact
How This Should Perform (Projected)
Because Clarity has not shipped, the numbers below are directional projections, not measured outcomes. Each is anchored to a published industry benchmark — named in-line — so a reviewer can judge whether the target is reasonable.
The framing follows Google's HEART model (Rodden, Hutchinson, Fu, CHI 2010): Happiness, Engagement, Adoption, Retention, Task success — each signal paired with a goal, a metric, and a benchmark source.
< 60m
Target MTTR for SEV1 — inside the DORA Elite band
DORA State of DevOps 2024 · Elite < 1h, Low 1 week – 1 month
< 30s
Time-to-acknowledge from a cold mobile push
Google SRE Book Ch. 14 · auto re-page if not acked in 5m
> 80%
Runbooks executed in-app vs. in Confluence / wiki
Reduces the #3 fragmentation complaint from review mining
100%
Post-incident reviews completed for SEV1 + SEV2 within 5 business days
Atlassian Incident Handbook default cadence
HEART signals → metrics
Task success · MTTR SEV1 median
Industry baseline→↓ 30% target
Task success · Mobile MTTA
—→< 30 seconds
Engagement · In-app runbook execution
—→> 80%
Adoption · PIR completion SEV1–2
Atlassian default→100%
Happiness · On-call NPS (quarterly)
PagerDuty baseline→+10 pts target
Retention · Voluntary on-call rotation exits
52% org-level (PD)→↓ meaningfully
Why these targets are defensible
Each target is a lower-leverage version of what DORA Elite performers already demonstrate. DORA's 2024 dataset (> 36,000 respondents) shows Elite MTTR < 1 hour is achievable at scale. Clarity's design thesis — folding runbook, comms, and AI correlation into one flow — is the specific mechanism that credibly closes the gap from today's typical hours-long MTTR to the Elite band.
The NN/g evidence that heuristic evaluation surfaces ~75% of usability issues gives further confidence that the design is in a shippable state for a first user-testing round.
What would falsify these projections
If MTTR did not move after adoption, the likely reason would be cultural rather than UI-bound — teams that lack a defined Incident Commander role, or that don't run blameless post-mortems, will see the tool deliver only modest improvement. That pattern is well-documented in Accelerate (Forsgren, Humble, Kim; IT Revolution, 2018). An honest evaluation plan would couple tool rollout with those org-level practices — or measure them as moderating variables.
20 — Learnings & Reflections
What I'd Do Differently
Honest retrospective on what worked, what didn't, and what I'd approach differently with this domain knowledge.
What I'd keep
Cognitive-science grounding: Designing for the cognitive state of a stressed engineer (not a calm one) was the single most impactful framing. Endsley's Situation Awareness model guided every layout choice; I'd do it again.
Competitive heuristic audit before ideation: Scoring five incumbents against Nielsen's 10 heuristics surfaced a cluster of H10 (help & documentation) violations — specifically, runbooks living outside the incident context. That became Clarity's single biggest product-differentiator decision.
Transparent AI with confidence scores: Deciding early that AI would always show a confidence percentage + "why this?" link avoided the trap of a black-box recommender. The recognition over recall heuristic drove this.
Dark-first, no light-mode compromise: The 3 a.m. use case is non-negotiable and drove more design decisions than any other constraint. Light mode was explicitly deferred to a v2 roadmap item, not scoped-out silently.
What I'd do differently
Mobile-first, not desktop-first: I designed desktop first and adapted down. The real "worst moment" is a phone vibrating at 3 a.m. — the tiny surface should have driven the visual hierarchy and the desktop should have inherited from it.
Partner on AI feasibility earlier: Several runbook-matching and deploy-correlation features were drawn before I understood the realistic latency, training-data, and privacy constraints. If this became a real project, an ML engineer would be in the first two standups.
Primary validation, not just heuristics: Expert heuristic evaluation is a strong second-best, but nothing substitutes for watching a real IC try to resolve a SEV1 in the prototype. If this were a shipped project, the next investment is 5 moderated sessions + a one-rotation diary study.
Onboarding treated as a core flow: New on-call engineers need a guided first-SEV1 walk-through. I scoped that to v2 — in hindsight, a first-page onboarding is the difference between a tool people tolerate and one they recommend.
Post-mortem automation sooner: The biggest ROI for comms leads was auto-generated post-mortems — but this was a v1.5 feature. Should have been v1.
21 — Roadmap
Clarity v2 — What's Next
If Clarity moved from concept to production, here's what v2 would explore — each item is a v1 gap the current design consciously accepted.
Q3 2024
Predictive Failure Detection
Use MTTR trend data and deployment patterns to predict incidents before they fire. Alert engineers to emerging patterns: "DB latency trending toward threshold — elevated probability of SEV2 within the next hour."
Grounded in: DORA predictive performance indicators (Accelerate, 2018) · industry precedent from New Relic Applied Intelligence and Datadog Watchdog
Q4 2024
AI Post-Mortem Generator
Auto-generate post-mortem drafts from War Room timeline data: root cause candidates, contributing factors, timeline, action items, and runbook-update suggestions — in plain language, always editable by the team. Grounded in Atlassian's blameless post-mortem template.
Goal: meaningfully shorten the post-mortem drafting step that currently gates institutional learning.
Q1 2025
Conversational Incident Interface
Natural-language interface for on-call engineers: "What's the status of checkout?" "Who's handling INC-4821?" "What's our MTTR trend this month?" — routed to the underlying structured data, not freeform LLM output. Reduces cognitive overhead for status checks.
Informed by Google's AIOps guidance and NN/g's writing on conversational UI trade-offs (Budiu, 2018).
Onboarding & Adoption Flow
Dedicated onboarding for new on-call engineers: guided first-incident walkthrough, personalized runbook setup, on-call schedule configuration, and alert threshold calibration wizard.
Integration Expansion
Current: Datadog, CloudWatch, PagerDuty, Slack. Planned: Grafana, New Relic, OpsGenie, Jira, GitHub Actions, ArgoCD — creating a true single-pane for the full DevOps toolchain.
22 — Summary
Designing for the Worst Moment
Clarity was built on a single insight: the worst UX in tech is what engineers face when their production systems fail.
High alert volume, fragmented tooling, missing business context, and coordination overhead combine to turn a 30-minute incident into a hours-long ordeal — costing organisations millions and engineers their sleep, health, and eventually their careers. The numbers are not hypothetical: DORA's Low performers take a week to a month to restore service; Splunk's SOC survey clocks ~4,484 daily alerts of which 66% go uninvestigated.
Clarity's response is to ground every design decision in established cognitive-science evidence — Cognitive Load Theory (Sweller, 1988), Recognition-Primed Decision Making (Klein, 1993), and Situation Awareness (Endsley, 1995) — and to build the interface an IC actually needs at the worst moment of their week.
The projected outcomes map 1:1 to benchmarks in public reports. They are directional, not measured; if this project moved from concept to production, the next investments are moderated testing with real on-call engineers and a multi-rotation diary study to validate where the model breaks.
The design ethos
"Good UX under normal conditions is table stakes. Good UX under extreme cognitive pressure — at 3 a.m., with every second costing real money, with alerts flooding the screen — is where design either earns its worth or disappears into noise."
— Design thesis for Clarity
Tools used
FigmaFigJamOptimal Workshop (card sorting · tree testing)NotionMiroStark (a11y)
23 — References
Sources
Every quantitative claim in this case study traces to one of the public sources below. Publication years are the most recent edition I worked from; named frameworks are cited by their canonical author(s). A hiring panel should be able to pressure-test any number above against this list.
Industry research & reports
Google / DORA. Accelerate State of DevOps Report 2024. dora.dev
Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018.
IBM Security. Cost of a Data Breach Report 2024. ibm.com/reports/data-breach
Verizon. Data Breach Investigations Report (DBIR) 2024. verizon.com/business/resources/reports/dbir
Splunk. State of Security 2024. splunk.com
PagerDuty. State of Digital Operations 2023. pagerduty.com
Gartner. IT Downtime Cost Benchmarks. gartner.com (the widely cited "$9,000/minute" for large enterprises originates here.)
IDC. Global Downtime Cost Study. idc.com
Dynatrace. Global CIO Report 2022 / 2023. dynatrace.com
OpsRamp. IT Operations Survey 2022.
Cognitive-science & UX frameworks
Miller, G. A. (1956). "The magical number seven, plus or minus two." Psychological Review, 63(2).
Sweller, J. (1988). "Cognitive load during problem solving." Cognitive Science, 12(2). — basis for Cognitive Load Theory.
Klein, G. (1993). "A recognition-primed decision (RPD) model of rapid decision making." In Decision Making in Action. — used to design for pattern recognition under time pressure.
Endsley, M. R. (1995). "Toward a theory of situation awareness in dynamic systems." Human Factors, 37(1). — the three-level SA model that structures Clarity's information hierarchy.
Martin, N., et al. NASA (1994). Flight-Crew Training to Cope with Startle. NASA Ames. — evidence base for the "startle effect" Clarity designs against.
Nielsen, J., Molich, R. (1990/1994). 10 Usability Heuristics for User Interface Design. Nielsen Norman Group. nngroup.com — the evaluation rubric applied in section 16.
Rodden, K., Hutchinson, H., Fu, X. (2010). "Measuring the user experience on a large scale: user-centered metrics for web applications." CHI 2010. — the HEART framework used in the projected-impact section.
Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux. — referenced in the revenue-impact design decision.
Frost, B. (2016). Atomic Design. bradfrost.com/atomic-web-design. — structure of Clarity's design-system layering.
British Design Council (2004). The Double Diamond. designcouncil.org.uk — the macro process followed in this case study.
Budiu, R. (2018). "The UX of conversational interfaces." NN/g. — referenced in the v2 conversational-interface roadmap item.
Design-system precedents
Atlassian Design System. atlassian.design
Shopify Polaris. polaris.shopify.com
GitHub Primer. primer.style
IBM Carbon Design System. carbondesignsystem.com
Microsoft Fluent 2. fluent2.microsoft.design
Contact for detailed rationale
Happy to walk through any decision on this case study in a portfolio review — including the parts I'd revise, the assumptions a primary-research round would test, and the trade-offs behind the design-system choices. Email yogitamalkhede5@gmail.com.
