Dashboard Requirements Gathering: The Template Every BI Team Needs

Dashboard requirements gathering is the process of defining what a dashboard should contain, who it's for, and what decisions it supports, before anyone opens a BI tool.

Most of it comes down to one question the stakeholder usually can't answer on the first try: what will you do differently after seeing this? If there isn't one, they've asked for a report rather than a dashboard, and it should be built as one.

The template below is what I'd fill in with them while asking it.

---

Why Most Dashboard Projects Skip Requirements (And Pay for It Later)

The typical BI project starts the same way. A stakeholder says "I need a dashboard," the analyst asks what should go on it, and the stakeholder says "the usual: revenue, costs, maybe some trends." Two weeks later the dashboard is built and nobody opens it.

The analyst's skills get the blame, or the tool does. In most of these the analyst was capable and the tool could have done more than it was asked to do. What was missing is a written answer to what useful means here, agreed before the build, so there was nothing to check the finished dashboard against and no point in the project where checking was anybody's job.

Requirements get skipped because the request sounds complete. "A dashboard to track sales performance" has a subject, a verb and a deadline attached, so it reads like a specification. It names a category. The specification is the part the stakeholder is hoping you already have.

That is the bill that arrives later: the rebuild, plus the two weeks that went into the version nobody opened.

---

The Dashboard Requirements Framework

Five questions cover a dashboard spec. Answer them and you can hand the result to a developer. Leave one open and it gets decided during the build, by whoever is building, without the stakeholder in the room.

1. Who is the audience?

Be specific. "The sales team" is not an audience.

• Role: VP of Sales, regional sales rep, sales ops
• Technical level: will they apply filters and drill down, or read the top line and close the tab?
• Frequency: daily check-in, or a monthly review?

The audience sizes the dashboard before you know a single metric. An executive wants three to five KPIs and a trend line, then wants the page to get out of the way. A rep wants their own pipeline, filtered to their territory, with drill-through to the deal.

Write the audience into the template as a sentence rather than a noun: "Regional Sales Managers, every Monday, reviewing last week's pipeline movement."

2. What decisions will this dashboard support?

This question decides the other four, and it is the one that gets skipped.

Good decision statements:

• "Should we increase ad spend in the Southeast region?"
• "Are we on track to hit Q2 revenue targets?"
• "Which product lines need pricing adjustments?"

Bad decision statements:

• "I want to see our data"
• "Show me everything"
• "Just the usual metrics"

Push back on the vague ones, and push with the same question every time: what will you do differently after seeing this?

If the stakeholder can't answer it, they have asked for a report. That is a legitimate thing to want. A report justifies a delivery instead of a decision, and it gets specified by a different document. Building it as a dashboard is what costs you the two weeks.

3. What metrics and KPIs are needed?

Audience and decision narrow the list before you start writing it. Capture six fields for each metric that survives:

• Name: Revenue MTD
• Definition: sum of closed-won opportunity amounts in the current month
• Source: Salesforce Opportunities table
• Granularity: daily, weekly, monthly
• Comparison: against target, prior period, or prior year
• Chart type: KPI card, line chart, bar chart

The definition column is the one stakeholders want to skip and the one to hold them to. "Revenue" is gross to one team and net to another, booked in the finance pack and recognised in the ledger, ARR in the board deck and MRR in the product review. Get the arithmetic into the cell, in their words, while they are still in the room.

Fill the comparison column too. It is the field people leave blank and the one that decides whether the card is worth building, so settle it here rather than in review.

4. What filters and interactivity are required?

Filters are the most argued-about element in dashboard design. Settle them in the template rather than in the build review.

• Global filters: date range, business unit, geography
• Page-level filters: product category, sales rep
• Drill-through: can someone click a region and see the deals inside it?
• Cross-filtering: does clicking a bar filter the table below it?

Let the headcount size the list. One or two people on a fixed view need almost no filters. Twenty people who each want their own slice need the filters, and they need defaults that land each person on their own slice without touching anything.

On an executive view, make every filter justify itself. An executive who has to filter before the page answers "are we on track" has been handed an exploration tool they never asked for.

5. What are the constraints?

Constraints decide more of the build than the metric list does, and left alone they surface last. Ask for them in the meeting:

• Data refresh frequency: real-time, daily, weekly
• Data access: row-level security, and who enforces it
• Platform: Power BI, Tableau, Looker Studio, or open
• Performance: how many rows, and what query time looks like at that size
• Timeline: the date this has to ship
• Mobile: is anyone opening this on a phone?

Ask about the screen out loud. A 1280×720 canvas is a guess about your audience's monitors, and almost nobody checks the guess before wondering why everyone scrolls.

---

The Dashboard Requirements Template

Five rows. The highlighted one is the row that decides whether you're building a dashboard or a report.

Copy this template for every new dashboard request and fill it out with your stakeholder in a 30-minute kickoff. It works as a business intelligence requirements gathering template on any BI platform: Power BI, Tableau, or Looker Studio.

⬇ Download the template (Markdown), then paste it straight into Google Docs, Notion, or your team wiki.

No form, no email wall. I give this away on purpose. A gated template is invisible to Google, which is why the competitors who hide theirs behind a form don't rank for the people searching for one, and it is a poor trade for you as well: you came for a table and you'd leave with a nurture sequence.

Project Overview

Metrics

Filters

Constraints & Notes

• Row-level security: Reps should only see their own territory
• Mobile: VP checks on phone during travel
• Data volumes: ~50K opportunities, should be fine for DirectQuery

---

Running the Requirements Meeting

A 30-minute requirements meeting with the right structure gets you 90% of what you need.

Before the meeting (5 min prep)

• Pre-fill the template with what you already know (data sources, existing reports)
• Send the template to the stakeholder so they can start thinking

During the meeting (30 min)

1. 5 min, audience and decisions: "Who will use this and what will they decide?"
2. 10 min, metrics walkthrough: go through each one and get names, definitions and priorities
3. 5 min, filters and interactivity: "What dimensions do people need to slice by?"
4. 5 min, constraints: refresh, permissions, mobile, timeline
5. 5 min, next steps: "I'll write this up and send it back by [date]"

After the meeting

• Clean up the template and share it back for sign-off
• Show the stakeholder a layout, if you want their reaction while changing it is still cheap

The part that earns the half hour is the read-back. Near the end, say the decision out loud in your own words and then wait. A stakeholder will nod along to their own sentence and stop you on yours, and that correction costs you a line in a table instead of a rebuild.

---

Common Requirements Gathering Mistakes

Mistake 1: Accepting "show me everything"

The stakeholder who asks for everything is the same one who calls the dashboard cluttered once it ships. Push for the decision first and let the metric list fall out of it.

Mistake 2: Not defining metric calculations

A metric with no written calculation is a cell somebody fills in during the build, from whichever query they happened to have open. Get the formula into the Definition column while the person who owns the number is still in the meeting.

Mistake 3: Skipping the priority column

Not everything is a must-have, and an unranked list becomes a 15-chart page that answers nothing in particular. Force-rank into must-have and nice-to-have, then build the must-haves and show those first.

Mistake 4: Gathering requirements by email

Requirements gathered over email are worthless. Threads produce incomplete, contradictory answers, they run for two weeks, and they end without anyone agreeing that they ended. Twenty minutes live beats all of it.

Mistake 5: Treating the requirements doc as the whole spec

The doc lists what goes on the page and says nothing about whether it fits on one. Six metrics and three filters read as a short list in a table and arrive as a crowded canvas at 1280 wide. The template has no column for that, which is fine, as long as you find out before the stakeholder does.

---

From Requirements to Wireframe

The requirements template can't tell you whether the thing will fit on the page. Sketching the layout is one way to find out, and it is optional. Teams close the same gap on a call, reading the decision back and arguing about it in words.

If you do sketch it, keep it rough. Polish reads as a decision already taken, and you want this one still open.

With datawirefra.me (opens in a new tab), the translation from a filled-in template takes about five minutes:

1. Create a new wireframe
2. Add KPI cards for each must-have metric
3. Add charts based on the chart type column
4. Add filter placeholders
5. Share the live URL with your stakeholder

Send your BI developer both. The template settles what each number is and where it comes from, and the layout settles how much room it gets.

---

If You Only Take One Row

Take the decision row.

Audience, metrics, filters and constraints are all recoverable later. You can add a metric in an afternoon. What you can't recover is a dashboard built for a decision nobody was making, because there's no version of that dashboard that works, and no amount of chart polish rescues it.

So ask the question, and be willing to hear the answer: what will you do differently after seeing this? If they can't tell you, they've asked for a report. Build them a report, and it'll get more use than the dashboard would have.

A report is a different document, though, and the dashboard fields above mostly do not apply to it. The BI reporting requirements template covers the seven that do: what arrives, on what cadence, to whom, and what happens the morning it fails.

Copy the template and take it into the next kickoff.