Power BI report design principles: dashboards people actually read

A dashboard people actually read answers one reader's questions on one screen. Start from the decision they make, put the headline number top left, keep only the visuals that change what they would do, match each chart to its comparison, then check usage data. Most Power BI reports fail on focus, not polish.

This guide is about those choices, in the order you make them. For the wider theory of charts and tools, see our complete guide to data visualisation.

Why do people stop reading a dashboard?

In our view, the report is rarely wrong. It just doesn't answer anything quickly. The reader opens it, can't tell in a few seconds whether things are going well, and goes back to the spreadsheet they trust. This is opinion rather than survey data, but these are the causes we would check first:

• No named reader. The page tries to serve the managing director, the sales team and finance at once.
• Numbers without context. A revenue figure means little without a target, a prior period or a trend.
• Every available field gets a chart. The page shows what the data can do, not what the reader needs.
• It is slow. A page that takes a long time to load teaches people not to open it.

Is it a dashboard or a report in Power BI?

The two words mean different things in Power BI, and it affects what you can build. Microsoft's dashboards versus reports comparison is the reference:

	Dashboard	Report
Pages	One	One or more
Data sources	One or more reports and semantic models	A single semantic model
Filtering and slicing	No	Yes
Built in Power BI Desktop	No, Power BI service only	Yes
Data alerts	Yes, on tiles in certain circumstances	No

What most businesses call "the dashboard" is really the first page of a report. The principles below apply to both, and "page" here means either. Use a true dashboard when someone needs one view across several reports or wants tile alerts.

Who is the page for, and what will they decide?

Write this down before opening Power BI Desktop: the reader's job, how often they look, and the two or three decisions the page should inform. Microsoft's dashboard design tips ask the same questions: how does your audience use it, and which metrics help them decide? Its accessibility guidance adds the practical step: talk to some of the people who will read the report before you place a visual, and show them a first draft.

Then choose the headline measures. If you can't name a target and an owner for a number, it probably isn't a headline; our guide to choosing KPIs covers how to narrow them down to three or four.

Two readers with really different questions usually need two pages. If they differ only in which measure or breakdown they want, field parameters can let one page serve both.

How should you lay out a report page?

Microsoft's advice is short and worth following literally: "Put the highest level of data at the top left corner" and show more detail as you move in the direction people read. In practice that gives a three-layer page:

1. Top row: the headline. Three or four KPI visuals or cards, each with its target or comparison, because Microsoft's guidance is to accent the important number and "provide context" for it.
2. Middle: the explanation. Two or three charts that show why a headline moved, such as the trend over time and the breakdown by region or product.
3. Elsewhere: the detail. Long tables and row-level records go on a drillthrough page, not the first screen.

A few smaller habits make a page feel considered:

• Fit one screen. Microsoft says having everything on one screen is best for a page read at a glance, and asks whether you can avoid scroll bars.
• Keep slicers in the same place on every page. People stop hunting for them, and it's on Microsoft's accessibility checklist.
• Scale your numbers. "3.4 million" reads faster than "3,400,000". Microsoft suggests one or two numerals left of the decimal point.
• Don't mix time frames. A chart of last month beside one filtered to a different month invites a wrong comparison.
• Sort deliberately. Sort by the measure to show the highest or lowest, and by the axis when people need to find a category.

Which chart should you use?

Choose by the comparison, not by variety. Microsoft warns against "variety for the sake of variety", and the Government Analysis Function's guidance on charts starts from the single message the chart should convey.

The reader's question	Use	Watch out for
How are we doing against target?	KPI visual or card	A number with no comparison
How does this change over time?	Line chart	More than about four lines
Which is biggest or smallest?	Sorted bar or column chart	Unsorted categories
Is the current status near the goal?	Gauge, sparingly	A row of gauges taking up space
What share is each part?	Bar chart; pie only for very few parts	Many similar-sized slices
What are the exact values?	Table, usually on a detail page	A long table on the first screen

The two sources differ on pie charts. Microsoft says they are best below eight categories, while the Government Analysis Function says five or fewer, forming a meaningful whole, with one dominant. We follow the stricter rule. Both agree on 3D, and on keeping clutter out: no shadows, heavy gridlines or unnecessary borders.

Watch mixed scales too. A measure in millions next to one in thousands flattens the smaller one, so Microsoft suggests a visual with a second axis; we would usually split them into two charts.

How many visuals is too many?

Microsoft gives no page limit. Its accessibility guidance says to keep the number of visuals on a page to a minimum and warns that too many can slow the report as well as overwhelm the reader. The widely repeated "no more than eight" is a practitioner rule of thumb, not a Microsoft one.

Our working rule, explained in the Power BI performance tuning guide, is to question any page with more than about a dozen visuals. As of November 2026 Microsoft documents two related limits: it recommends 10 to 20 fields per visual for readability and performance, with an upper limit of 100.

The number matters less than this test: for each visual, ask what the reader would do differently if it moved. No answer means it can go, or move to a detail page. Microsoft's accessibility guidance suggests a squint test: if your eye goes to the labels before the data, turn them off.

How do you handle colour and accessibility?

Set colour once, through a report theme, rather than visual by visual. Microsoft calls using theme colours best practice, because visuals then update automatically when the theme changes. You can export the theme as a JSON file and import it into your other reports, which is the cheapest way to make a set of reports look related.

One trap is easy to miss. Power BI assigns series colours in the order they appear in each visual, so North can be one colour in one chart and another in the next when the regions differ. If a colour stands for something, assign it to that member explicitly.

For accessibility, these checks come from Microsoft's report checklist and take little time, as of November 2026:

• Text contrast of at least 4.5:1 against the background.
• Colour is never the only signal: add text, icons or line markers. Microsoft lists red and green among the combinations to avoid together.
• Alt text on every non-decorative visual (250 characters at most, and it can be dynamic through a measure).
• A tab order that matches the reading order, with decorative shapes removed from it.
• Titles without acronyms or jargon: Microsoft's example replaces "CY Totals" with a title that says what is being totalled.
• Nothing important hidden in a tooltip or behind an interaction.

Does the page need a phone layout?

Only if people read it on a phone, which is worth asking. Microsoft says reports designed for a computer "can be difficult to read" on phones, and offers a mobile layout view where you arrange just the visuals that matter.

The limitation to remember: mobile-optimised views show only in the Power BI mobile apps, in portrait. In a web browser, even on a phone, people get the standard layout. So a sales team using the browser on their phones won't see your mobile layout.

What does this look like on a page?

This example is illustrative, not a client project. Picture a monthly sales page for the sales director of a small wholesaler, built by adding a chart for each field the export contained:

	Before	After
Reader	"The business"	Sales director, weekly
Top of page	A logo, a title and six slicers	Revenue, margin %, and orders, each against target
Trend	Three separate charts, one per year	One line chart, this year against last
Breakdown	Pie chart with 14 product groups	Bar chart sorted by margin, top 8 plus "other"
Customer detail	400-row table on the first page	Drillthrough page from any bar
Colour	A different colour per chart	One theme; one accent colour for below target

The "after" page has fewer visuals, and it answers the question the director opens it with: are we on target, and if not, where is it going wrong? If the numbers themselves can't be sliced cleanly, the fix sits underneath in the model, and a star schema is usually where that starts.

How do you find out whether people read it?

Measure it instead of guessing. Power BI's usage metrics report is the honest feedback most report authors never open. As of November 2026 it covers the last 30 days, excluding today, and shows report views, page views and unique viewers, plus typical opening times. Its workspace report list includes a count of unused reports.

• Who can run it: someone with a Pro or Premium Per User licence and edit access to the report. A Viewer role isn't enough, and your Power BI admin must have the feature enabled.
• What to read carefully: Microsoft says page view figures depend on client telemetry and can undercount or overcount, for example because of ad blockers. Report views are the firmer number. The improved report is still labelled preview.
• What it doesn't cover: dashboards still use the older version of the usage report.

We would look at it 30 days after launch. A page nobody opens is a candidate to cut, and a report that is slow to open points you back to performance tuning. Then ask two or three readers what they did with it last week, because usage tells you that they opened it but not whether it helped.

If your team has the data and the dashboards but still reaches for the spreadsheet, that is what our data visualisation and report design work addresses, alongside our Power BI and Fabric consultancy and the rest of our data and BI practice.

Frequently asked questions

What are the most important dashboard design principles?

Design for one named reader and the decisions they make, keep the page to one screen, put the headline number top left, match each chart to the comparison it makes, and use colour to carry meaning rather than decorate. Then check usage data to see whether anyone reads it.

How many visuals should a Power BI report page have?

Microsoft gives no fixed number; it advises keeping visuals to a minimum and avoiding redundancy. Our working rule is to question any page with more than about a dozen visuals. The better test is whether each visual changes what the reader would do.

What is the difference between a Power BI dashboard and a report?

A dashboard is a single page of tiles built in the Power BI service, which can draw on several reports and semantic models but cannot be filtered or sliced. A report can have many pages, is built on one semantic model, and supports filtering and drilling down.

Should I use pie charts in Power BI?

Rarely. The Government Analysis Function says to use them only with five categories or fewer, where the categories form a meaningful whole and one dominates. Otherwise a sorted bar chart is easier to read, because people can compare the values side by side.

How can I tell whether people use my Power BI report?

Open the usage metrics report from the workspace. It shows report views, page views and unique viewers for the last 30 days, excluding today. You need a Pro or Premium Per User licence and edit access to the report, and your admin must have the feature enabled.

---

Easy Insight is a UK consultancy for AI, web, apps and data — senior specialists only, no juniors.