Reporting and KPIs
How to Create a Dashboard That Leads to Better Decisions
The dashboard creation process, from defining the audience and question through wireframing, building it in Power BI, and publishing it for the right people.
Sajagan Thirugnanam
·
Updated
How to create a dashboard that leads to better decisions: start from the audience and the question it needs to answer, not from the charts you want to build. The dashboard creation process runs in a fixed order: define who it's for and what problem it solves, wireframe the layout, build it, test it, and give the numbers context before anyone else sees it.
This post covers that process end to end. For the size, layout grid and formatting choices once you're building, see our companion post on dashboard layout and formatting.
The Dashboard Creation Process, Step 1: Define the Audience and the Question
Before opening any tool, answer two questions:
Who is the dashboard for?
What business problem will it address?
A dashboard for a CEO does not need to show which account manager brought in the most revenue last quarter. It needs an overview of revenue, profitability, market share and other numbers a leader scans in a few seconds. A dashboard for a customer success team needs the opposite: NPS, retention, and cohort behavior tied to specific accounts.
If you don't know who the audience is from the task brief, ask. Starting the build before you know the audience wastes hours and often produces a dashboard nobody uses.
The second question, the business problem, decides how the dashboard needs to work, not just what it shows. If the audience needs raw-level detail, plan for a drill-down path so they can go from a summary number into the rows behind it. If they need a fixed answer to a fixed question, keep the dashboard simple: a handful of cards and one or two charts, nothing to interact with.
Answering these two questions before you build solves most of the hard part. Everything after this is execution: wireframing, building, validating and publishing, in that order, which the rest of this post covers.
Wireframe the Dashboard Before You Build It
A wireframe is a rough layout of the dashboard: which chart goes where, and how the pieces connect. Building one before you open any BI tool saves rework, because it's much cheaper to move a box on paper than to move a finished visual.
A useful wireframe includes:
The KPIs and metrics that match the business requirement.
The chart type for each visual (bar, line, card, table) and why that type fits the data.
How components interact, for example a filter on one chart updating another.
Notes on data sources and any assumptions.
Any whiteboard, Figma, PowerPoint, or plain paper works. The tool doesn't matter. What matters is getting a rough version of the dashboard in front of the person who requested it before you build anything, so they can move things around while it still costs nothing to change. Treat their feedback on the wireframe as the real requirements gathering, not a formality before the "real" work starts.
Build It in Power BI
Once the wireframe is agreed, the build in Power BI Desktop follows a consistent order:
Connect the data. Home > Get Data, and pick the connector for your source (a database, Excel file, SharePoint list, or a Fabric lakehouse).
Shape the model. Set relationships between tables, mark a date table, and remove columns the dashboard doesn't need. A model built for the dashboard's questions is faster and easier to maintain than one that just mirrors the source tables. If more than one report will need the same numbers, build the model once as a shared semantic model rather than rebuilding it inside every report that needs it.
Write the measures. Every KPI on the wireframe becomes a DAX measure, not a raw column. A basic example:
Total Revenue = SUM ( Sales[Revenue] )
Revenue vs Prior Quarter =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue =
CALCULATE ( [Total Revenue], DATEADD ( 'Date'[Date], -1, QUARTER ) )
RETURN
DIVIDE ( CurrentRevenue - PriorRevenue, PriorRevenue )Our DAX guide covers writing measures like this in more depth.
Lay out the visuals to match the wireframe. Place the highest-priority numbers where the audience looks first. See dashboard layout and formatting for how to decide that order, the page size, and consistent formatting.
Publish. File > Publish > Publish to Power BI, or select Publish on the Home ribbon, and choose the workspace the audience has access to. Publishing to a shared workspace requires a Power BI Pro or Premium Per User (PPU) license.
Share it. For a wide audience, create an app from the workspace (select Create app in the workspace list view) rather than granting workspace access directly. An app gives read-only access without exposing the underlying model to editing.
A Power BI report, the thing you build in Desktop, is not the same object as a Power BI dashboard, which is a single page of tiles pinned from one or more reports, built only in the service, with no filtering of its own. Most of what people mean by "create a dashboard" is building a report with a dashboard-style single page; the term is used loosely across the industry, and this post uses it that way too. Our step-by-step guide to building a dashboard in Power BI walks through the Desktop build in more detail.
Validate and Test Before You Publish
A dashboard that looks right and isn't right is worse than one that's obviously unfinished, because a wrong number that looks polished gets trusted. Before sharing it:
Check the headline totals against the source system directly, not against another report that might share the same bug.
Click through every filter and slicer to confirm they update the visuals the way you expect.
Confirm the refresh actually runs and the dashboard shows current data, not the data from when you built it.
Open it on the screen size the audience will actually use, including mobile if they'll check it there.
Have one other person, ideally someone who wasn't involved in building it, click through it before the audience does. A second set of eyes catches broken interactions and confusing labels the builder stops noticing.
Formatting in particular can break on publish even when it looked correct in the build tool, so treat this step as mandatory, not optional cleanup.
Give the Numbers Context
A raw number rarely means anything on its own. If a dashboard shows 1,534 new customers last quarter, that reads as fine until you learn the prior quarter had 2,235, a 31% drop. Context, usually a comparison to a prior period, a target, or a benchmark, is what turns a number into something a reader can act on. Every KPI on the dashboard should sit next to a comparison, not alone.
Make It Interactive, Where It Helps
Interactivity, filters, slicers, drill-down and cross-filtering between charts, lets a reader explore data instead of reading a fixed picture. It's useful when the audience needs to answer their own follow-up questions. It's a liability when the audience wants one fixed answer fast: extra filters just add clicks between them and the number they came for. Decide this from the audience question in the first section, not by default.
The same dashboard sometimes needs to serve more than one fixed view, for example a monthly view and a year-to-date view of the same charts. Decide whether that's better solved with reader-controlled filters or with a small number of saved states the reader switches between with one click. Either way, resist adding a control just because the tool makes it easy. Every extra filter is something the audience has to understand before they get to the number they came for.
Where This Applies by Use Case
The same process produces different-looking dashboards depending on the audience:
A customer service dashboard tracks health score, NPS, ticket volume, resolution time, and churn or renewal, built for the CX team.
A campaign monitoring dashboard tracks conversion rate, click-through rate, engagement, and A/B test results, built for a marketing team.
A management KPI dashboard tracks revenue versus target, customer acquisition, revenue per customer, and lifetime value, built for executives who want the topline story at a glance.
See our roundup of dashboard types for more examples and what each one is built to answer.
Common Mistakes to Avoid
Overcrowding the dashboard. Packing in every available metric makes it harder, not easier, to find the one that matters. Keep it to what the audience question actually needs.
Skipping validation. Formatting can break on publish, and numbers can be wrong even when the layout looks right. Budget time to test the dashboard against the source data before sharing it.
Ignoring mobile. If the audience will open the dashboard on a phone or tablet, design or test a mobile layout. Retrofitting one after the fact is more work than building it in from the start.
Building before the audience and question are confirmed. The fastest way to redo work is to start building on an assumption instead of an answer to the two questions in the first section of this post.
No owner after launch. Someone needs to be responsible for fixing the dashboard when the source data changes shape, a column gets renamed, or a new region needs adding. Decide who that is before you publish, not after the first thing breaks.
FAQs
How long does it take to build a dashboard?
There's no fixed timeline. It depends on how many data sources feed it, whether a usable data model already exists, and how many rounds of stakeholder review the wireframe and draft go through before sign-off. A dashboard built on a clean, existing model can take hours; one that needs new data connections and a new model takes longer. The validation step in this post is part of that timeline too, not something squeezed in after the "real" work is done.
What's the difference between a dashboard and a report?
In Power BI specifically, a report is the multi-page file you build in Desktop. A dashboard is a single page of tiles pinned from one or more reports, built only in the Power BI service, with no filtering of its own. Outside Power BI, and often within it, "dashboard" is used more loosely to mean any single-page summary view, which is how this post uses the term.
Which tools can I use to build a dashboard?
Power BI, Tableau, Looker, and spreadsheet tools like Excel or Google Sheets can all build dashboards. The process in this post, define the audience, wireframe, build, add context, test, applies regardless of which tool you use. This post shows the Power BI build steps because that's what we work in.
Should I get sign-off on the wireframe before building?
Yes, where the request comes from someone else. A wireframe is cheap to change; a finished dashboard is not. Getting agreement on the layout and metrics before you build avoids rework after the audience sees a version they didn't ask for.
Sources
Publish from Power BI Desktop - Microsoft Learn
Get started with Power BI Desktop - Microsoft Learn
Publish an app in Power BI - Microsoft Learn
Intro to dashboards for Power BI designers - Microsoft Learn
How to create a dashboard that leads to better decisions: start from the audience and the question it needs to answer, not from the charts you want to build. The dashboard creation process runs in a fixed order: define who it's for and what problem it solves, wireframe the layout, build it, test it, and give the numbers context before anyone else sees it.
This post covers that process end to end. For the size, layout grid and formatting choices once you're building, see our companion post on dashboard layout and formatting.
The Dashboard Creation Process, Step 1: Define the Audience and the Question
Before opening any tool, answer two questions:
Who is the dashboard for?
What business problem will it address?
A dashboard for a CEO does not need to show which account manager brought in the most revenue last quarter. It needs an overview of revenue, profitability, market share and other numbers a leader scans in a few seconds. A dashboard for a customer success team needs the opposite: NPS, retention, and cohort behavior tied to specific accounts.
If you don't know who the audience is from the task brief, ask. Starting the build before you know the audience wastes hours and often produces a dashboard nobody uses.
The second question, the business problem, decides how the dashboard needs to work, not just what it shows. If the audience needs raw-level detail, plan for a drill-down path so they can go from a summary number into the rows behind it. If they need a fixed answer to a fixed question, keep the dashboard simple: a handful of cards and one or two charts, nothing to interact with.
Answering these two questions before you build solves most of the hard part. Everything after this is execution: wireframing, building, validating and publishing, in that order, which the rest of this post covers.
Wireframe the Dashboard Before You Build It
A wireframe is a rough layout of the dashboard: which chart goes where, and how the pieces connect. Building one before you open any BI tool saves rework, because it's much cheaper to move a box on paper than to move a finished visual.
A useful wireframe includes:
The KPIs and metrics that match the business requirement.
The chart type for each visual (bar, line, card, table) and why that type fits the data.
How components interact, for example a filter on one chart updating another.
Notes on data sources and any assumptions.
Any whiteboard, Figma, PowerPoint, or plain paper works. The tool doesn't matter. What matters is getting a rough version of the dashboard in front of the person who requested it before you build anything, so they can move things around while it still costs nothing to change. Treat their feedback on the wireframe as the real requirements gathering, not a formality before the "real" work starts.
Build It in Power BI
Once the wireframe is agreed, the build in Power BI Desktop follows a consistent order:
Connect the data. Home > Get Data, and pick the connector for your source (a database, Excel file, SharePoint list, or a Fabric lakehouse).
Shape the model. Set relationships between tables, mark a date table, and remove columns the dashboard doesn't need. A model built for the dashboard's questions is faster and easier to maintain than one that just mirrors the source tables. If more than one report will need the same numbers, build the model once as a shared semantic model rather than rebuilding it inside every report that needs it.
Write the measures. Every KPI on the wireframe becomes a DAX measure, not a raw column. A basic example:
Total Revenue = SUM ( Sales[Revenue] )
Revenue vs Prior Quarter =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue =
CALCULATE ( [Total Revenue], DATEADD ( 'Date'[Date], -1, QUARTER ) )
RETURN
DIVIDE ( CurrentRevenue - PriorRevenue, PriorRevenue )Our DAX guide covers writing measures like this in more depth.
Lay out the visuals to match the wireframe. Place the highest-priority numbers where the audience looks first. See dashboard layout and formatting for how to decide that order, the page size, and consistent formatting.
Publish. File > Publish > Publish to Power BI, or select Publish on the Home ribbon, and choose the workspace the audience has access to. Publishing to a shared workspace requires a Power BI Pro or Premium Per User (PPU) license.
Share it. For a wide audience, create an app from the workspace (select Create app in the workspace list view) rather than granting workspace access directly. An app gives read-only access without exposing the underlying model to editing.
A Power BI report, the thing you build in Desktop, is not the same object as a Power BI dashboard, which is a single page of tiles pinned from one or more reports, built only in the service, with no filtering of its own. Most of what people mean by "create a dashboard" is building a report with a dashboard-style single page; the term is used loosely across the industry, and this post uses it that way too. Our step-by-step guide to building a dashboard in Power BI walks through the Desktop build in more detail.
Validate and Test Before You Publish
A dashboard that looks right and isn't right is worse than one that's obviously unfinished, because a wrong number that looks polished gets trusted. Before sharing it:
Check the headline totals against the source system directly, not against another report that might share the same bug.
Click through every filter and slicer to confirm they update the visuals the way you expect.
Confirm the refresh actually runs and the dashboard shows current data, not the data from when you built it.
Open it on the screen size the audience will actually use, including mobile if they'll check it there.
Have one other person, ideally someone who wasn't involved in building it, click through it before the audience does. A second set of eyes catches broken interactions and confusing labels the builder stops noticing.
Formatting in particular can break on publish even when it looked correct in the build tool, so treat this step as mandatory, not optional cleanup.
Give the Numbers Context
A raw number rarely means anything on its own. If a dashboard shows 1,534 new customers last quarter, that reads as fine until you learn the prior quarter had 2,235, a 31% drop. Context, usually a comparison to a prior period, a target, or a benchmark, is what turns a number into something a reader can act on. Every KPI on the dashboard should sit next to a comparison, not alone.
Make It Interactive, Where It Helps
Interactivity, filters, slicers, drill-down and cross-filtering between charts, lets a reader explore data instead of reading a fixed picture. It's useful when the audience needs to answer their own follow-up questions. It's a liability when the audience wants one fixed answer fast: extra filters just add clicks between them and the number they came for. Decide this from the audience question in the first section, not by default.
The same dashboard sometimes needs to serve more than one fixed view, for example a monthly view and a year-to-date view of the same charts. Decide whether that's better solved with reader-controlled filters or with a small number of saved states the reader switches between with one click. Either way, resist adding a control just because the tool makes it easy. Every extra filter is something the audience has to understand before they get to the number they came for.
Where This Applies by Use Case
The same process produces different-looking dashboards depending on the audience:
A customer service dashboard tracks health score, NPS, ticket volume, resolution time, and churn or renewal, built for the CX team.
A campaign monitoring dashboard tracks conversion rate, click-through rate, engagement, and A/B test results, built for a marketing team.
A management KPI dashboard tracks revenue versus target, customer acquisition, revenue per customer, and lifetime value, built for executives who want the topline story at a glance.
See our roundup of dashboard types for more examples and what each one is built to answer.
Common Mistakes to Avoid
Overcrowding the dashboard. Packing in every available metric makes it harder, not easier, to find the one that matters. Keep it to what the audience question actually needs.
Skipping validation. Formatting can break on publish, and numbers can be wrong even when the layout looks right. Budget time to test the dashboard against the source data before sharing it.
Ignoring mobile. If the audience will open the dashboard on a phone or tablet, design or test a mobile layout. Retrofitting one after the fact is more work than building it in from the start.
Building before the audience and question are confirmed. The fastest way to redo work is to start building on an assumption instead of an answer to the two questions in the first section of this post.
No owner after launch. Someone needs to be responsible for fixing the dashboard when the source data changes shape, a column gets renamed, or a new region needs adding. Decide who that is before you publish, not after the first thing breaks.
FAQs
How long does it take to build a dashboard?
There's no fixed timeline. It depends on how many data sources feed it, whether a usable data model already exists, and how many rounds of stakeholder review the wireframe and draft go through before sign-off. A dashboard built on a clean, existing model can take hours; one that needs new data connections and a new model takes longer. The validation step in this post is part of that timeline too, not something squeezed in after the "real" work is done.
What's the difference between a dashboard and a report?
In Power BI specifically, a report is the multi-page file you build in Desktop. A dashboard is a single page of tiles pinned from one or more reports, built only in the Power BI service, with no filtering of its own. Outside Power BI, and often within it, "dashboard" is used more loosely to mean any single-page summary view, which is how this post uses the term.
Which tools can I use to build a dashboard?
Power BI, Tableau, Looker, and spreadsheet tools like Excel or Google Sheets can all build dashboards. The process in this post, define the audience, wireframe, build, add context, test, applies regardless of which tool you use. This post shows the Power BI build steps because that's what we work in.
Should I get sign-off on the wireframe before building?
Yes, where the request comes from someone else. A wireframe is cheap to change; a finished dashboard is not. Getting agreement on the layout and metrics before you build avoids rework after the audience sees a version they didn't ask for.
Sources
Publish from Power BI Desktop - Microsoft Learn
Get started with Power BI Desktop - Microsoft Learn
Publish an app in Power BI - Microsoft Learn
Intro to dashboards for Power BI designers - Microsoft Learn
Show us your report nobody trusts.
1 · A 30-minute call.
2 · We look at your current reports together.
3 · We tell you what we would do.
Show us your report nobody trusts.
1 · A 30-minute call.
2 · We look at your current reports together.
3 · We tell you what we would do.
Show us your report nobody trusts.
1 · A 30-minute call.
2 · We look at your current reports together.
3 · We tell you what we would do.
CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.
Berlin, Germany
Free tools
CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.
Berlin, Germany
Free tools
CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.
Berlin, Germany