The Dashboard Planning Template I Use Before Anyone Opens Power BI

Here's a confession from someone who builds dashboards for a living: the dashboard is the easy part.

I can make a beautiful one in an afternoon. What I can't do in an afternoon is fix a dashboard nobody asked the right questions for. I've seen gorgeous dashboards with 40 charts get opened twice and abandoned, and ugly ones with four numbers run a whole organization's Monday meeting for years.

The difference is always the planning. So I made the planning tool I wish every client had filled out before calling me. It's free. Download the Dashboard Planning Template (PDF).

Here's how to use it, page by page.

Why most dashboards fail

Page one starts with the warning signs, because you've probably seen them: too many metrics on one screen, nobody trusts the numbers, no clear owner, built for reporting instead of decisions, no action tied to what it shows, different teams defining the same number differently, and dashboards that are still live but nobody opens.

Every one of those is a planning failure, not a design failure. Nobody decided who it was for or what it was supposed to change.

So before anyone opens Power BI, Tableau, Looker or a spreadsheet, you answer five questions:

1. What decisions should this dashboard help people make?
2. Who will use it?
3. What actions should happen when the numbers change?
4. Where does each number come from?
5. Who owns each metric?

If you can't answer those, you're not ready to build. You're ready to have a conversation.

Page 1: The dashboard planning canvas

The canvas is three steps on one page:

Step 1: Who is this dashboard for? Pick one primary audience. Executive leadership, a board, department managers, program staff, operations, finance, funders, the community. You can have secondary audiences, but one person or group has to be the main reader.

Step 2: What decisions must it support? Write down the top five questions leadership needs answered. Not "what data do we have," but "what do you need to know to decide something?"

Step 3: Convert questions into KPIs. For each question, the one number that answers it.

Example from the template: "Are we meeting our goals?" becomes "Outcome Achievement Rate." "Where should we focus resources?" becomes something you can sort and compare.

There's also a quick self-assessment on page one. If you score low, fix that before you build anything.

Page 2: Executive vs. operational

This is the page that saves the most arguments. An executive dashboard and an operational dashboard are different products:

When someone asks for "one dashboard for everyone," that's usually two dashboards fighting for one screen. Build two, and link them.

Page 3: Choosing the right KPIs

The rule I live by: the right KPIs turn data into decisions. The wrong ones create noise.

A good KPI is relevant to a decision, actionable, measurable, timely, easy to understand, comparable over time, and owned by someone. The template uses the SMART check (specific, measurable, attainable, relevant, time-bound) and shows good vs. poor examples side by side.

The poor ones are almost always things that are easy to count but don't change a decision: total meetings held, page views, number of emails sent. If the number went up 20% tomorrow, would anyone do anything differently? If not, it's not a KPI. It might be useful context, but it doesn't get a headline spot.

If you work in nonprofits, this is the same lesson as outputs vs. outcomes. Counts of activity are outputs. The KPIs that matter most usually describe change.

Page 4: Mapping questions to metrics

This is the heart of the template. A table that walks each question all the way through:

Question → metric → insight → action.

For each one you write the leadership question, the metric that answers it, how it's calculated, the data source, how often it updates, and who owns it. Then a data quality check: is the source complete, accurate, consistent, timely and accessible?

Doing this on paper surfaces the problems early. You find out that the "enrollment" number lives in two systems that disagree, or that the survey only runs once a year, before you've built a chart on top of it. That's the kind of thing I wrote about in why you need a data house before AI: the foundation decides whether anything built on top can be trusted.

Page 5: Layout blueprint

A dashboard should read like a story at a glance. The layout page gives you the pattern that works for most executive dashboards:

• Top row: the four to six headline KPIs, big and simple, with a comparison to target or last period.
• Middle: trends over time and the main breakdown.
• Bottom: detail, lists and anything someone might drill into.

Most important information top left, because that's where eyes land first. Group related metrics. Use color to mean something, like status, not to decorate. Leave white space. The page lists do's and don'ts so you can check your sketch.

Page 6: Choosing the right chart

The visualization guide matches what you're trying to show to the chart that shows it:

If you're not sure, use a bar chart. It's almost never wrong. Pie charts with nine slices almost always are.

Page 7: Wireframe worksheet

Sketch it before you build it. The wireframe page has a grid to draw the layout, boxes for dashboard information and device considerations (desktop, tablet, phone), filters and controls, and a visual-to-metric table so every chart on the sketch maps back to a metric on page four.

Show the sketch to the main audience. It takes ten minutes, and it's a lot cheaper to move a box on paper than to rebuild a data model.

Page 8: Your dashboard build plan

The last page turns the plan into a project: an executive summary of what the dashboard is for, stakeholders and owners, an implementation roadmap (plan, build, test, launch, improve), a data readiness checklist, a maintenance plan so someone keeps it alive, risks and assumptions, and a launch and communication plan.

That maintenance section matters more than people think. Every dashboard needs an owner, a refresh schedule and a date to ask "is anyone still using this?"

Start with one page

You don't have to fill out all eight pages for a small dashboard. If you only do one thing, do page one: who it's for, the five questions, and one metric per question. That alone will put you ahead of most dashboards I see.

Download the free Dashboard Planning Template (PDF), print it, and fill it in with the people who'll actually use the dashboard in the room.

And if you run programs and your dashboard is really a funder report in disguise, that's what Storyhouse was built for: the plan, the questions and the records in one place, with every number linked to where it came from.