Designing dashboards for your audience

Start from the audience, not the data

A dashboard is a product with readers. The same telemetry supports very different boards depending on who is looking — and boards that try to serve everyone end up read by no one. Before adding a single widget, answer two questions: who checks this board, and what decision do they make from it?

Audience	They ask	The top row should show
Executives	“Are we okay? Is it getting better or worse?”	3–6 outcome numbers vs targets
Team leads	“Where should the team spend this week?”	A scorecard ranking services / owners
SREs / engineers	“What is broken, and why?”	Firing alerts + the golden signals
Business stakeholders	“Is it being used? What does it cost?”	Adoption and spend KPIs

The 5-second rule: a first-time viewer should grasp the state of the world — good or bad — within five seconds of the board rendering. If they have to hunt, the layout is wrong.

Layout principles that always apply

• Top-left is prime real estate. Readers scan in an F-pattern: across the top row, then down the left edge. Put the single most important signal top-left and let importance decay toward the bottom-right.
• Three altitude bands. Row 1: state — Stat/Gauge/Heartbeat widgets with thresholds. Rows 2–3: trends — Line/Area/Bar charts explaining the numbers above. Bottom: detail — Tables and Top lists for the people who scroll.
• Group correlated widgets on one row — CPU, memory, and disk side by side lets a saturation story read as one glance, not three.
• 8–12 widgets per screen. Beyond that, comprehension and load time both degrade. A glanceable board must fit one screen without scrolling; if you scroll, you have two dashboards wearing one name.
• Name outcomes, not metrics. “Checkout availability”, not http_5xx_rate. Widget titles are the narration of the board.
• Be consistent with units and colors. Pick per-widget display units once (auto-scaling bytes, millisecond durations) so 2,147,483,648 reads as 2 GiB, and keep threshold colors meaning the same thing everywhere.
• Use a Markdown widget as the board’s caption. One small widget saying what the board answers, who owns it, and where the runbook lives saves every future viewer a Slack question.

Time range and refresh: match the reading rhythm

Auto-refresh re-runs every widget, so pick the slowest interval that still serves the audience. Time-series widgets on relative ranges refresh incrementally and identical queries are cached for 30 seconds, but a 10-second refresh on a 40-widget wall is still a load multiplier — and nobody reads an executive KPI every 10 seconds.

Board	Default range	Auto-refresh
Live ops / NOC screen	1–3 hours	10–30s
Service / on-call board	3–6 hours	30s–1m
Team weekly review	7 days	15m or Off
Executive / KPI board	30 days	1h
Capacity / trend planning	30–90 days	Off

Individual widgets can override the global range (a 30-day trend widget on a 1-hour ops board) — use that sparingly and label it in the widget title (“last 30 days”).

Executive and C-level boards

Executives read dashboards the way they read a one-page brief: a handful of numbers, each with a direction and a judgment. Everything else is noise.

• Few numbers, big type. 3–6 Stat widgets across the top: availability, error rate, active users, spend proxy. Configure thresholds so each number carries its own verdict color — the board should say “green” without anyone parsing digits.
• Trend vs target, not raw telemetry. Under each number, one Line/Area chart over 30–90 days. If a target exists, make it visible (a threshold line) so the gap is the message.
• Frame in cost, risk, and customers. “Failed checkouts”, “hours of degraded service”, “tools per employee” land; p99_gc_pause does not.
• Distribute, don’t invite. Generate a permalink — optionally locked to a fixed range and variable values so every recipient sees the same view — and embed it in the wiki or leave it on an office screen in fullscreen TV mode (press f).
• Slow the refresh. Monthly-scale questions don’t need sub-minute answers; 1 hour is plenty.

Team-lead boards: scorecards and weekly reviews

• Default the range to 7 days and run the weekly review straight off the board, top-left to bottom-right — the layout is the agenda.
• Rank, don’t average. Top list widgets turn “how are we doing” into “what do we fix first”: services by error count, endpoints by p95, hosts by saturation. Ranked lists assign the conversation an order.
• Show workload and ownership. Group by the labels your telemetry carries (service, team, owner) in Top lists and Tables so the board answers “whose plate is fullest” — alert counts per service, deploys per repo, noisy rules per owner.
• Compare weeks with Bar charts — discrete buckets read as “this week vs last” far better than a continuous line.
• One golden board per team, cloned, not re-invented. Build the team template once, clone it per service, and keep every copy in the team’s folder. Ask members to favorite it — favorites sort first in the dashboard list.

Technical and SRE boards

• Structure service boards with RED: Rate, Errors, Duration — one row, three charts, per service. Structure resource boards with USE: Utilization, Saturation, Errors per host, node, or pool. The two methods are checklists for what a board must not omit.
• Put alerts on the board. An Active Alerts widget wired to the service’s rules belongs top-left on an on-call board — the board should open on “what is firing”, then explain it. Add Alerts by Severity for the week’s risk picture.
• Order for drill-down. Symptoms at the top (SLO burn, error rate), causes below (latency by endpoint, saturation by host), evidence at the bottom (Tables, Time-series tables). An investigator should never scroll up to go deeper.
• Parameterize with variables. One board with $service, $host, $env dropdowns replaces a board per service — and keeps every copy from drifting. Query-backed variables populate the dropdown from live label values.
• Use Heatmaps where lines turn to spaghetti — error density per service, load across a fleet — and Heartbeat widgets for the dependencies you only care about as up/down.
• Link the escape hatches. A Markdown widget with the runbook, the Data Explorer for the ad-hoc follow-up question, and Vera when you want the investigation done conversationally.

Business stakeholder boards

• Lead with adoption and spend KPIs — active users, installs, licensed seats in use — as Stat widgets with 30–90 day trend charts beneath.
• Rollups over raw events. Top lists of tools by host count, Pies of usage by department, Tables of “what is installed where” — the shadow-IT / tool-sprawl style of view that turns telemetry into a procurement conversation.
• Count distinct things, not samples: uniq(…) over hosts, users, or sessions answers “how many actually use it”.
• Hide the mechanics. No SQL-flavored titles, no host names, no units an accountant would query. Share a range-locked permalink so the numbers under discussion don’t shift mid-meeting.

Shared, cross-team dashboards

• Adopt a naming convention and let search do the rest: Team — Purpose (Environment), e.g. “Payments — API Health (prod)”. Names like “Dashboard 2 (copy)” are where trust goes to die. Descriptions and tags are searchable too — use them.
• Folders are the shared taxonomy — one per team or domain, assigned on the dashboard and filterable in the list. Favorites are personal: your shortlist, sorted first, no effect on anyone else.
• Give every shared board one owner. Shared editing without ownership produces widget graveyards. Others clone before experimenting.
• Standardize variables across boards — the same $env and $service names everywhere make boards feel like one product and let muscle memory transfer.
• Version-control the important ones. Export to JSON, commit, review — and import to promote a board from staging to production.
• Wall screens: fullscreen TV mode (press f) on a dedicated browser, or a permalink for kiosks that shouldn’t hold a login. Permalinks can be revoked and given expiry dates — treat them as shared secrets.

When to split a dashboard

Split when any of these appear — many focused boards beat one wall of everything:

• Two audiences — the moment you add an executive row to an SRE board, both audiences get a worse board.
• Two refresh rhythms — live triage (seconds) and monthly trends don’t belong on one refresh interval.
• Scrolling — content below the fold is content nobody monitors.
• Slow loads — widget queries are capped at 30 seconds each, but forty widgets at once is still forty queries; split before you tune.
• Diverging variables — if half the board ignores the $service dropdown, that half is a different dashboard.

Quick reference

Audience	Range / refresh	Widgets that carry the board	Count
Executives	30d / 1h	Stat (thresholds), Line vs target, Markdown caption	4–8
Team leads	7d / 15m	Top list, Bar (week-over-week), Table, Stat	6–10
SRE / on-call	1–6h / 30s	Active Alerts, Stat, Line (RED/USE), Heatmap, Heartbeat	8–12
Business	30–90d / Off–1h	Stat KPIs, Top list, Pie, Table	5–8
Shared / NOC wall	1–3h / 10–30s	Stat, Heartbeat, Active Alerts, Line	6–10 (TV mode)

Prototype the queries in the Data Explorer or the Query Workbench first, start the board from a template, and revisit it quarterly: delete what nobody has looked at — view counts don’t lie.