Overview
Curated: · Written: · Reviewed:
Design a dashboard around a decision, not a collection of charts
Review status: awaiting review.
How this question is asked
"Design a dashboard for [X]" shows up in system-design and analytics-product loops, and it is usually a trap. The trap is that candidates who can build charts start describing charts: a time series here, a pie there, maybe a filter bar. The interviewer is testing whether you can move up one level of abstraction and reason about what the dashboard is for before deciding what it looks like.
The interview answer to open with: name the audience, the recurring decision, the cadence, and the action. Who opens this dashboard, what question they need answered, how quickly they need it, what comparison or threshold changes what they do, and what they do next. An executive monitoring revenue, an on-call engineer responding to incidents, and an analyst exploring churn may sit on the same data warehouse but need different granularity, latency, controls, and explanation. A dashboard that contains every available metric obscures the few signals that matter — and "everything on one page" is the request the stakeholder will actually make in the follow-up.
The follow-up you should expect: the VP wants all 40 metrics on it anyway. What do you cut? A weak answer negotiates vaguely or promises filters. A strong answer says what a metric must do to earn space: each one has to be able to change a decision. Anything that cannot change the decision goes to a detail view or nowhere, and the ability to remove metrics is what distinguishes a designed dashboard from an accumulated one. That habit — name the decision and the metric before touching the layout — is the single thing the interviewer is checking.
The interview checklist for this question
Run your answer through these five checks; interviewers probe each:
- Purpose and KPIs. Who consumes this, what decision does it inform, and which 4–6 KPIs follow from that decision? If you cannot derive each KPI from the decision, you are decorating.
- Hierarchy. Where does the eye land first, and is that the decision-critical number? Is summary layered over detail — headline KPIs, then trends, then breakdowns?
- Chart choice. Does each encoding match its analytical question — comparison, trend, distribution, composition, relationship — or was it picked because it looks impressive?
- Clutter. Would removing gridlines, borders, legends, and a dimension make the chart better? If yes, remove them.
- Colour. Does colour encode meaning consistently, or decorate?
Weak answers sound like a feature list: "I'd use Grafana with a 12-column grid and add alerting." Strong answers sound like reasoning: "On-call triage means the anomaly indicator beats the absolute value, so the first tile is deviation from baseline, not raw throughput."
Layout follows attention, not data structure
Reading pattern runs top-left to bottom-right in an F or Z shape, so the decision-critical figure goes where the eye lands first — highest, largest, first scan path. Group related measures near each other, keep a consistent grid and consistent units, and put diagnostic detail behind progressive disclosure or a linked exploration view. Anything below the fold is effectively optional; treat that as a feature, because it forces you to rank what matters.
Layer summary over detail in three tiers: headline KPIs with their comparison, trend charts that explain how the headline got here, and breakdowns that locate the change in a segment. A big KPI without denominator, timeframe, or definition is decoration rather than evidence, so preserve enough context to interpret every number: definition, scope, period, comparison baseline, target, freshness, and uncertainty.
Comparison is what makes a number interpretable. Revenue of 4.2 million means nothing alone; against last month, plan, last year, or a control group it becomes a finding. Choose the comparison from the decision rather than defaulting to the previous period — a seasonal business compared month-on-month reports a crisis every January. State the comparison in the label, and show uncertainty where the sample is small: a conversion rate from 40 sessions moves several points on one extra conversion, so one decimal place implies precision the data does not have.
Chart selection by analytical question
Pick the encoding from the task, not from what the tool renders easily:
| Analytical question | Right encoding | Notes |
|---|---|---|
| Compare categories | Horizontal bar, sorted by value | Length on a common scale supports precise comparison |
| Trend over time | Line | Ordered time; dual axes can manufacture correlation |
| Distribution | Histogram, density, box plot, quantiles | Rarely needed on an executive view; common in ops |
| Composition | Stacked bar; rarely pie | Part-to-whole judgments are imprecise past a few slices |
| Relationship | Scatter | Only when location/relationship is the question |
| Exact values, many dimensions | Table | Tables beat charts when users need lookup, not impression |
Rule of thumb for line versus bar: time and continuous order get lines; unordered categories get bars. And a single big number with its comparison beats any chart when the decision is a threshold check — "is p99 under 300 ms" is better served by one number and its target than by a ribbon chart.
Bars require a meaningful zero because they encode value in length; a bar chart starting at 95 truncates length comparison and lies. Truncated line axes are defensible when the task is detecting small changes and the axis is clearly labeled — a line chart of latency from 40 ms to 60 ms is fine, a bar chart of the same data is not.
Declutter: data-ink over chartjunk
Every mark should carry information. Remove 3D and perspective (they distort values), heavy gridlines, decorative borders, redundant legends — if the series is labeled directly, the legend is a lookup cost — and any dimension that does not change the reading. Sort bars meaningfully (by value, usually, not alphabetically). One message per chart: if a chart supports two conclusions, it is two charts.
Label directly on the data where possible. The interviewer's probe here is visual: they will sketch a cluttered chart and ask what you would change. The weak answer adds a tooltip; the strong answer deletes ink until only the message remains.
Honest scales extend this. Show missing data as missing, not zero — a gap in the line reads as a data problem, a drop to zero reads as an outage. Annotate structural breaks and definition changes so instrumentation changes are not misread as business events. Explain smoothing, binning, normalization, and log scales in a note rather than applying them silently.
Colour as encoding, not decoration
Three palette types map to three questions: categorical palettes for unordered classes, sequential palettes for ordered magnitude, diverging palettes for deviation from a meaningful midpoint. Sequential data in a rainbow palette is a common failure — its perceptual ordering does not match the data's.
Use one saturated accent colour for the thing that should interrupt someone's day and grey for context. Reserve attention colours for exceptions; if everything is red, nothing is. Keep colour meaning consistent across charts — red means the same thing on every tile.
Colour must never be the only carrier of status. About 8% of men have a colour-vision deficiency, and every dashboard is eventually screenshotted into a document or printed where the palette dies. Pair colour with a label, shape, or position; test with a deuteranopia simulation; check contrast in dark and light themes. This is not a compliance nicety — "how would this look to a colour-blind user or in a black-and-white export" is a standard follow-up, and the correct answer is that the redundancy was designed in, not bolted on.
Beyond the visual: what senior candidates add
The visual design is table stakes; senior answers differentiate on what surrounds it.
Freshness and quality are part of the interface. Show last successful data time and coverage, not page-render time. Distinguish live, delayed, partial, stale, and failed states — an old green status presented as current is worse than an honest failure. Handle empty, loading, error, and permission states deliberately rather than zero-filling a chart.
Interactions preserve meaning. Filters need names, defaults, visible active state, reset, and scope. Cross-filtering and drill-down show what changed and offer a path back. Validate query parameters server-side and enforce row- and object-level authorization independently of the visual layer — deep links must not become a data-exfiltration path. Avoid defaults that silently exclude a region or pick a flattering comparison.
Performance shapes trust. Aggregate at the level the decision needs, limit initial tiles and expensive queries, load detail progressively, and make one failing tile not block the page. Measure time to meaningful content and query cost across realistic devices and data volumes, not on a laptop against a sample dataset.
Accessibility is a product requirement. Every visual gets a title and a text alternative or underlying accessible table; keyboard focus order, visible focus, and no hover-only essential values. Automated scanners catch a fraction of this; test with a keyboard and a screen reader.
The closing follow-up, often: how would you know this dashboard is working? Not page views. Track whether the intended user detects the anomaly, finds the affected segment, and takes the action without coaching — time to detection, drill-through rate, decisions changed, stale or unused tiles. And retire dashboards that duplicate definitions or no longer support an owned decision; a graveyard of unowned dashboards is where most deployments end up, and saying so shows you have operated one.