A bad operational risk dashboard is worse than no dashboard. It eats the team's attention budget, trains the on-call lead to ignore alerts, and gets blamed when the actually-bad event finally lands. After 50+ production deployments across freight forwarders, energy SOCs, newsrooms and regional government risk units, three design patterns separate the dashboards that get used from the ones that get muted.
This post is the field guide.
Pattern 1: One number, not ten
Every dashboard project starts the same way. Three feeds, then five, then ten. Each feed has its own severity scale. The "All events" page becomes a wall of mixed-units numbers — magnitude on the quake card, category on the storm card, Goldstein score on the conflict card. The on-call lead has to mentally translate every card every time.
The fix is brutal: normalise every event to a 0-100 score at ingest time. Everything else is presentation. The card layout, the severity colour, the threshold filter — all key off that one number.
This is the single most underrated decision in risk monitoring UI. Teams that ship it succeed. Teams that don't end up with a wall of cards nobody reads.
Pattern 2: The "what changed" view, not the "what is" view
Most dashboards default to a "current state" view: here are the open issues, here are the active storms, here are the live alerts. Useful, but not what an on-call lead actually wants when they wake up at 3am.
What they want is "what changed since I last looked at this." The dashboard's home view should be a chronological list of events that moved into the actionable severity band in the last N hours, with the events that exited (resolved, expired, snoozed) at the bottom.
The implementation is a delta computed against the user's last dashboard load timestamp. Stored in localStorage works fine. Three-line component.
Pattern 3: Severity colour, not source colour
Every OSINT product starts by colour-coding by source. USGS is yellow, NHC is purple, GDELT is teal. Looks pretty in the design mock. Trains nobody to recognise the pattern that matters.
Replace source colour with severity colour. The eye should track red → orange → green even before reading the text. Add a thin source indicator (icon or text label) but make it secondary. Three colours, three meanings:
- Red — severity 70-100. Critical. Wake somebody up.
- Orange — severity 40-69. Elevated. Review within 24h.
- Green — severity 0-39. Background. Search for context only.
Don't add more colours. The eye doesn't track six-colour palettes; it tracks three.
The one mistake every team makes
Showing too many active alerts. The "default view" should show the top 5-10 critical alerts. Everything else lives behind a "show all" link.
Most dashboards default to showing 100+ alerts. The on-call lead scans the first three, glazes over, and misses the genuinely-important one buried at position #47.
Cap the default view at 10. Trust the severity score to surface the right ones.
The five-card layout that works
For most teams the productive dashboard layout is:
- Top bar: map + global severity heatmap + last-update timestamp
- Card 1: Critical now — last 24h, severity 70+, max 10 cards
- Card 2: Recently resolved — what closed in the last 24h, why
- Card 3: Snoozed / paused — zones that are off, with countdown
- Card 4: Channel health — Slack / webhook delivery success in last hour
- Card 5: Activity sparkline — 30-day daily count, by source
Six tiles, one screen. Anything more goes on a separate page.
Alert triage UI
The single highest-leverage UI element is the resolve button. Make it one click.
The pattern that works:
- Each alert card has a "✓ Resolve" button visible without hover
- Click resolves immediately, no confirmation modal
- Card animates to greyed-out state and slides down to the resolved section
- Optional note appears on hover for second-click
Reducing the resolve-button click cost from 3 clicks (open, type, submit) to 1 click (resolve) drives a 5-10x increase in resolve-rate per session. We've measured this.
The "explain why" panel
Every alert card should have a tiny "why did this fire?" affordance. Two clicks deep:
- Click card → expand panel
- Panel shows: which zone matched, which feed, severity components, threshold values, optional LLM explainer
This is where the LLM explainer earns its rent. An on-call lead doesn't have time to read the GDELT article. The one-paragraph summary tells them "is this big" in 5 seconds.
What doesn't work
A few patterns we've watched fail repeatedly:
"Heatmap of the world" as the primary view. Looks great in a sales demo. Useless for ops — the colour density carries no information about your asset exposure.
Drill-down hierarchies. "Click feed → click event type → click severity → see alerts." On-call leads don't navigate; they scan. Flatten the hierarchy.
Real-time animation. Pulsing dots, moving lines, sweeping radar visuals. Distracts from reading. Reserve animation for state changes only (alert fires, alert resolves).
Dark/light theme switcher as a visible button. Pick one. Most SOCs operate in dark rooms; dark theme is the right default. The switcher just clutters the chrome.
Mobile is a different product
A mobile SOC dashboard is not a shrunken desktop dashboard. It's a triage notification surface.
- One alert per screen
- Resolve / snooze / escalate as three big buttons
- Map and analytics live on a separate tab the user rarely opens
- No multi-zone overview
Most teams treat mobile as an afterthought. The teams that get it right design it first, then expand to desktop.
Metrics worth tracking on the dashboard itself
Once the alerting layer is mature, the dashboard becomes a meta-tool: what's my signal-to-noise ratio?
- Alerts per day per channel
- Mean time to resolve
- Critical alerts dismissed without action ("we missed it")
- Zones with zero alerts in 30 days (over-tuned, raise the radius)
- Zones with 100+ alerts in 30 days (under-tuned, raise the threshold)
These five numbers, surfaced on a "dashboard health" page, drive the per-week tuning that keeps the alert volume sustainable.
Putting it together
The dashboard that gets used:
- One severity scale (0-100), three colours (red/orange/green)
- Chronological "what changed" home view, capped at 10 cards
- One-click resolve button on every alert
- LLM explainer two clicks deep
- Mobile triage as a separate product
Augur implements this pattern out of the box. Or build your own — the patterns above are vendor-agnostic. The dashboard layer is where the OSINT pipeline either gets adopted or muted; design accordingly.