Dashboard design questions are not really about listing KPIs. The question underneath is who uses the data, what decisions it supports, and how the design changes with the audience.
This is one of the most common analytical PM interview questions, and it is easy to underperform on by jumping straight to metrics without establishing context.
Start with the user, not the metric
Before you name a single number, ask: who is looking at this dashboard? A VP of Product checking weekly trends needs a fundamentally different view than an ops manager monitoring real-time queue depth. The audience determines everything: the refresh cadence, the level of aggregation, the alert thresholds, and whether the dashboard is a wallboard, a morning email, or an interactive tool.
The three layers of a good dashboard answer
Layer 1: Context and decisions. What business question does this dashboard answer? If someone looks at it and nothing has changed, do they close the tab? If something is wrong, what's the resulting action? A dashboard that does not lead to a decision is a screensaver.
Layer 2: Metric hierarchy. Lead with 2-3 north-star metrics that map directly to the decisions from Layer 1. Below that, add diagnostic metrics that explain movement in the north-star numbers. Avoid showing 15 metrics with equal visual weight. That layout makes the reader do the prioritization the dashboard was supposed to do.
Layer 3: Technical feasibility. What's the source of the data? What is the latency? Are there known gaps or biases in the data pipeline? Dashboards are only as good as the data underneath them, and naming a known pipeline risk out loud is one of the fastest ways to sound like you have shipped one of these before.
Common mistakes
The biggest mistake is treating the question as a metrics-listing exercise. Listing DAU, WAU, retention, revenue, and NPS says nothing about the product or the person reading the numbers. The second mistake is ignoring the audience: a dashboard for the CEO and a dashboard for a feature team should look like two different products.
A framework that works
Try this structure in your answer: (1) clarify the audience and their top decision, (2) propose 2-3 primary metrics tied to that decision, (3) add 3-5 diagnostic metrics that explain movement in the primaries, (4) describe the layout and cadence, (5) name one data quality risk and its mitigation.
This structure treats a dashboard as a tool that supports decisions. Anything that does not change a decision comes off the board.