The Dashboard Planning Checklist Every BI Team Needs

A BI analyst gets a request that fits in a Slack message ("can you build us a sales dashboard?"), builds for three weeks, and hears "this isn't what I had in mind" at the demo. The data was right and the tool was capable. The person who asked and the person who built were answering different questions, and nothing in between them forced a comparison.

Another week of development buys a more polished version of the wrong dashboard. The gap closes in conversation instead, before anyone opens a BI tool. That conversation takes about twenty minutes, and the checklist below is what I take into it.

---

Why Dashboard Planning Gets Skipped

Planning gets skipped because it feels like overhead. You want to get into the data, the stakeholder wants something on a screen, and both of you treat the requirements as obvious enough to leave unwritten.

They are not obvious. "A sales dashboard" means live pipeline and deal health to a VP of Sales. To a rep it means their own quota progress against the month. To an ops manager it means territory coverage and rep activity. Same two words, three builds that share almost nothing.

Run the checklist live, out loud, with the person who asked for it. Requirements collected over email come back contradictory and half-specified, and twenty minutes on a call settles more than a two-week thread does.

---

The Dashboard Planning Checklist

Five phases and twenty-three questions. Phase 1 decides whether the other four are worth running.

Phase 1: Define the Purpose

• What decision does this dashboard support? "Track performance" is not a decision. "Decide whether to move budget out of the regions running under plan" is. Ask it in the sharper form: what will you do differently after seeing this? If nobody can answer, the request is for a report rather than a dashboard, and a report gets specified by a different document.

• Who is the primary user? One dashboard cannot serve everyone equally. Name one role. Everyone else is secondary and gets what is left.

• Who else will use it? List the other user types and write down where their needs diverge. You are deciding in advance which requests you will turn down.

• How will users open it? Desktop, mobile, a published portal, embedded in another tool. This constrains Phase 3 harder than any choice you make inside it.

• How often will they look at it? Daily, weekly or monthly. That answer sets the refresh requirement and the level of detail.

---

Phase 2: Define the Metrics

• List every metric the dashboard should show Write them all down, then cut. A page carrying more than the right number of KPIs for its audience (3–5 executive, 5–7 management, 7–9 operational) is a report laid out like a dashboard.

• For each metric, confirm four things

  • The business definition (is "revenue" gross or net, does it include returns, is it FX-adjusted)
  • The data source (which table, in which system)
  • The owner (who answers when the number looks wrong)
  • The update frequency (real-time, daily, weekly)

• Define what good looks like What threshold makes someone act? That answer becomes your target lines, your conditional formatting and your alerts. Skip it and you ship numbers with no opinion attached to them.

• Identify the comparisons Prior period, target, budget, year-ago. Settle it here. A KPI card without a comparison is just a number: it says where you are without saying whether that is good, so the reader goes somewhere else to find out. Adding the logic after the model is built costs more than naming it now.

• Identify the dimensions and filters Region, product, team, period, segment. Name the ones the user will slice by. Each is a requirement. On an executive view each is also a small failure, since executives want "are we on track" answered on arrival rather than a tool to explore with.

---

Phase 3: Define the Layout

Phase 3 turns the answers into a page. You can wireframe it, sketch it on a whiteboard, or drop rectangles into slides.

• Decide the visual hierarchy Name the single most important number and put it top-left. Everything else takes its position from that one. Layout decides whether the page answers its question in about three seconds, and colour work does not move that number.

• Choose a chart type for each metric

  • Trend over time: line chart
  • Comparison across categories: bar chart
  • Single KPI against a target: KPI card with an indicator
  • Breakdown or composition: pie, donut, or stacked bar
  • Geographic: map
  • Detailed list: table

• Draw the layout Boxes and rough labels are enough to run the conversation. Paper works. So does datawirefra.me (opens in a new tab), if you would rather not redraw a KPI card from scratch every time.

• Get the sign-off in words Ask the primary stakeholder for a written "yes, this is what I want". A thumbs-up on the link is politeness, and politeness arrives instead of an objection.

---

Phase 4: Technical Requirements

• Confirm the data exists Does the data you need exist yet, and is anyone already arguing about its quality? Find that out before you promise a date.

• Define the refresh cadence If the user asks for "live", get them to put a number on it. Every fifteen minutes and once a day are two different systems.

• List the transformations Joins, aggregations, business logic. Flag the metrics that need a calculation nobody has written yet, because those are the ones that slip.

• Define row-level security Can everyone see everything, or do reps see only their own accounts? This shapes the data model, so it cannot wait until Phase 5.

• Confirm how it gets published Power BI Service, Tableau Server or Cloud, a Looker Studio link, embedded in a web app, dropped into a data portal.

---

Phase 5: Launch & Iteration Plan

• Set the first review date Agree a date for the first draft review, then double the estimate you made in your head.

• Agree how feedback arrives A meeting, an email, or comments in a shared doc. Pick one before the first draft goes out, or you will get all three and reconcile them yourself.

• Write down what "done" means What is in v1, and what is out? The out-of-scope list is the half that protects you, and it only works if somebody wrote it.

• Name the owner after launch Who do users contact when the data looks wrong, and who handles the next request for one more filter? Answer while the answer is still cheap.

---

Common Planning Mistakes (and How to Avoid Them)

"The stakeholder will know what they want when they see it." They will. That is an argument for showing them something early, not for building the first version blind. Every round of seeing it costs whatever you spent making it.

Skipping the metric definitions. "Revenue" means something different to Sales, Finance and Marketing. Write the calculation next to the metric name, in the requirements doc, before anyone builds against it.

Building for "the team" rather than one person. Each extra persona brings its own requirements, and the compromise that satisfies all of them serves nobody first. Build for the primary user and make the rest optional.

No written scope boundary. Without one, every conversation adds a metric. The scope note does not have to be long. It has to exist before development starts.

Treating data quality as somebody else's problem. Building the dashboard is how the quality issues surface. Budget time for that, because the work will not be only visualization.

---

What Should a Stakeholder Sign Off On?

Ask someone what they want on a dashboard and you get a category. Show them a layout and you get corrections: not that bar chart, this one number, move those cards to the top, that filter belongs to someone else's job. Same person, same ten minutes, and a much better answer. People specify badly and criticise well.

A sign-off on something polished is worth less than a sign-off on something rough. Finish work signals that the decisions are already made, and a reviewer who believes that stops hunting for what is wrong. Keep phase 3 at the level of boxes and labels, and the corrections arrive while they still cost nothing.

Phases 1, 2, 4 and 5 sign off fine in a document. Phase 3 needs a picture, and the picture does not need a tool. I built datawirefra.me (opens in a new tab) because sketching a dashboard in a design tool takes longer than the meeting it feeds, and an analyst with a stakeholder call on Thursday skips anything that costs more than the call.

Draw the layout you want argued with → (opens in a new tab)

---

Related Resources

• Dashboard requirements gathering, the full framework behind Phases 1 and 2, plus a free downloadable template
• How to wireframe a dashboard: step-by-step guide
• 12 dashboard layout patterns, a structure to start Phase 3 from
• Why dashboards fail, the alignment gap this checklist closes