Interface Lab
Login
Back to knowledge
Design Systems Page Patterns

Dashboard KPI Alert Triage Contract

Operations dashboards should organize KPIs, alerts, thresholds, owners, evidence, and next actions into a scannable triage system instead of an equal-weight wall of charts.

dashboardkpialertsoperationsincident

Design Principle

A good dashboard first answers whether action is needed, severity, blast radius, ownership, and evidence path; charts are evidence layers that support triage.

Large Theory

An operations dashboard is not a metric showroom. Its core task is helping users quickly answer what changed, how bad it is, where it affects, who owns it, and what should happen next. KPI cards, alert rails, trend charts, tables, logs, and detail drawers should form one triage path: status first, anomaly next, evidence after that, then action or escalation.

Small Points

  1. Write the triage question before layout: What changed? How bad? Where? Who owns it? What next?
  1. Layer metrics: primary KPIs decide whether action is needed, diagnostic metrics explain why, context metrics support comparison, and decorative metrics are removed or demoted.
  1. The first row holds only 3-5 decision KPIs. Each KPI includes value, unit, period, baseline, delta/trend, threshold, freshness, severity label, explanation, and evidence link.
  1. Alert severity cannot rely only on color. Critical/warning/info/success/neutral states use text labels, icons/shapes, borders/semantic color, trend, and helper copy.
  1. Thresholds need provenance: SLA, percentile, anomaly, manual, or static. Users need to know whether a rule or model made the state abnormal.
  1. The alert rail sorts by severity, recency, blast radius, owner, and state. Critical alerts need owner, next action, escalation, and evidence path.
  1. Acknowledged, muted, and resolved are states, not deletion. Acknowledged alerts are calmer but visible, muted alerts show reason and expiry, and resolved alerts move to history/audit trail.
  1. The analysis area explains the top signal only: trend, cohort, table, map, or logs answer why the abnormal state happened instead of showing every drawable metric.
  1. Mobile is alert-first: top status summary, key KPIs, collapsible filters, alert list, and primary action. Do not shrink desktop charts until they are unreadable.

Design Judgment

The dashboard works when an operator can state current health, most severe anomaly, blast radius, owner, next action, and evidence path within 30 seconds. If users see many attractive charts but cannot tell whether to act, who acts, or how, it is a metric wall.

Implementation Advice

Define a DashboardTriageModel: audience, systemName, timeScope, freshness, filters, primaryKpis, diagnosticMetrics, contextMetrics, alerts, thresholdSources, owners, actions, auditStates, and detailPanels. KPI components expose accessible names with metric, value, unit, period, and state; use tabular numbers, stable grid/card dimensions, URL-reproducible filters/time range, data freshness/timezone, loading/empty/error/stale/partial-data branches, and semantic CSS variables. Alert actions use real buttons/links; acknowledge/mute/resolve cannot be hover-only icons.

Counterexamples/Risks

All cards have equal color and weight; a red number lacks threshold and explanation; alerts have no owner or next action; muted alerts lack reason and expiry; resolved alerts disappear so audit is impossible; abnormal values appear only on hover; data freshness is absent; mobile has whole-page horizontal scroll; animated metric changes make values hard to read.

Case Analysis

NN/g defines dashboards as single-page collections of data visualizations that provide at-a-glance information users can act on quickly, and its dashboard visualization guidance emphasizes preattentive processing for fast understanding. Grafana alerting best practices frame real alerting around complex systems, imperfect signals, and humans on call; Grafana also links alert rules to dashboard panels so responders know where to investigate. Carbon status indicators help users notice important changes, prioritized tasks, and statuses; Carbon notification guidance separates inline, toast, and actionable feedback locations. Atlassian badge, lozenge, and flag separate numeric status, object status, and short feedback into distinct component semantics. Together these sources show that dashboard alert design must layer signals, severity, evidence, feedback, and action scope.

Source Links

NN/g Dashboards: https://www.nngroup.com/articles/dashboards-preattentive/

NN/g Data Visualizations for Dashboards: https://www.nngroup.com/videos/data-visualizations-dashboards/

Grafana Alerting Best Practices: https://grafana.com/docs/grafana/latest/alerting/guides/best-practices/

Grafana Link Alert Rules to Panels: https://grafana.com/docs/grafana/latest/alerting/alerting-rules/link-alert-rules-to-panels/

Carbon Status Indicators: https://carbondesignsystem.com/patterns/status-indicator-pattern/

Carbon Notifications: https://carbondesignsystem.com/components/notification/usage/

Atlassian Badge: https://atlassian.design/components/badge/badge/usage

Atlassian Lozenge: https://atlassian.design/components/lozenge

Atlassian Flag: https://atlassian.design/components/flag

Agent Directive

Write the triage question first; classify metrics as primary/diagnostic/context/decorative; keep 3-5 decision KPIs at the top; sort alerts by severity, recency, blast radius, owner, and state; every abnormal state has owner, next action, evidence link, and acknowledge/mute/resolve/audit states.