12 Power BI Dashboard Rules (Canvas, 10 Visuals, Fast DAX)

Most slow Power BI reports were already slow before anyone opened the design view. The model is wrong, and no amount of visual tidying fixes a bad star schema.

That reframes most of what follows. The 8-to-10 visual limit is a query budget: every visual fires its own DAX query, so the count is a performance decision that happens to also reduce clutter. The canvas size is a guess about your users' screens, made by Microsoft, and you are free to check it. Twelve rules below, all specific to Power BI, and not one of them is "use more white space".

Work in Tableau instead? See the companion guide: Tableau dashboard rules.

---

1. Start with the Canvas Size

Power BI opens on a 1280×720 canvas at 16:9, which suits a dashboard projected in a meeting room or opened on a standard monitor. Three sizes cover the alternatives:

• 1280×720. Standard. Best for meeting-room presentations and most desktop views.
• 1920×1080. Full HD, more room for a dense page, and every element looks small on a lower-resolution display.
• Custom, 1440×900 or 1280×960. Matched to the resolution your audience runs.

1280×720 is a guess about your users' screens, and almost nobody checks. Ask IT for the resolution spread, or run a one-question survey, then size the canvas to the answer. A page designed at 1920×1080 and opened on a 1366×768 laptop asks for a scroll, and the reader skips whatever sits below the fold rather than going looking for it.

For phones, use Power BI's phone layout instead of trying to make the desktop page flex. Build it separately: fewer visuals, bigger text, one column.

---

2. Limit Visuals per Page to 8-10

Eight visuals on a 1280x720 canvas. Each one is a separate DAX query on every filter change.

Every visual on a page fires its own DAX query. Ten visuals means ten queries on load, and ten more on every filter click. Microsoft's optimization guide for Power BI (opens in a new tab) puts reducing the number of visuals on a page among the highest-impact changes available for render time.

Most advice states the limit as "don't clutter your dashboard", which hides the reason and makes the limit easy to argue with. A stakeholder who wants an eleventh chart wins the clutter argument, because taste is arguable and a second of load time is not. Tell them what the eleventh chart costs everyone who opens the page.

• Executive pages: 4-6 visuals
• Management pages: 6-8
• Operational and detail pages: 8-10

Past ten, split the page and connect the halves with drill-through. (For the full breakdown by page type, see how many visuals should be on a Power BI dashboard.)

Open Performance Analyzer (View → Performance Analyzer), record a page load, and sort by duration. Anything over two seconds needs the DAX simplified, the model trimmed, or the visual cut.

---

3. Use Card Visuals for KPIs (Not Tables)

A matrix carrying the headline numbers is the most common KPI mistake in Power BI. Tables hold detail. Cards carry the headline.

• Card or Multi-row Card for top-line KPIs
• The value, a comparison against target or against last period, and a conditional icon or colour
• A horizontal row across the top of the page

The comparison is the piece people drop, and it is the piece doing the work. A card reading $1.24M needs a second measure beside it before it means anything, and in Power BI that is one more DAX expression, not one more visual. Write the comparison measure when you write the base one.

The New Card visual, available since late 2024, carries reference labels, sparklines and conditional formatting in one component. It puts the comparison on the page without spending a second visual from the budget in rule 2.

---

4. Master Report Page Tooltips

Page tooltips stay underused, and they buy back room on a crowded page.

Set a page's size to Tooltip (320×240), build the detail visuals on it, and mark it as a tooltip page. Hovering a bar or a data point on the main page pops it up in context.

Say the main page shows revenue by region as a bar chart. The tooltip page can carry that region's top five accounts, its month-over-month trend and its win rate, none of which needs a permanent home on the main canvas.

Build tooltip pages for the two or three drill-down questions people ask you most. Anything rarer belongs on a drill-through page, where someone can read it without holding the mouse still.

---

5. Bookmarks, and the Structure They Hide

Bookmarks capture the state of a page: which visuals are visible, which filters are applied, what is selected. Wire them to buttons and you get tabs without leaving the page.

1. Build the visuals for View A and View B on one page
2. Bookmark A shows View A and hides View B
3. Bookmark B shows View B and hides View A
4. Two buttons across the top, Overview to Bookmark A and Detail to Bookmark B

Nothing reloads, so it feels faster than page navigation. It is also, most of the time, a workaround for a page that should have been two pages. The complexity moves into a bookmark list that the next person to open the file has to reverse-engineer, usually with no documentation and no way to tell which visuals belong to which state.

Toggling one chart between two measures is worth a bookmark. Once a button hides half the report, you have built a second page and given it a worse address.

---

6. Apply a Consistent Color Palette

Power BI defaults to a rainbow. Replace it before you build anything on top of it.

1. View → Themes → Customize current theme
2. Pick 6-8 sequential colours that sit together, warm to cool or light to dark inside one hue
3. Reserve one accent colour for highlights: targets, alerts, the selected item
4. Save it as a JSON theme file and apply it to every report in the organisation

Blue carries the primary series and reads as neutral. Grey takes the comparison series. Red and green stay reserved for conditional states rather than decoration, because a chart already coloured red has nothing left to say on the morning something goes wrong. Five colours in a single chart is already a lot.

Exporting your organisation's brand palette as a JSON theme gets you consistency without asking each analyst to pick well under deadline.

---

7. Design for Drill-Through, Not Scroll-Down

Right-click a data point, land on a detail page already filtered to it. That is drill-through, and it answers "show me more" without a scrollbar.

• Summary page: regional performance, as a bar chart, a map and KPI cards
• Drill-through page: one region, with its trend, top accounts and rep performance
• Right-click North America on the summary and arrive on the detail page filtered to North America

Put a Back button on every drill-through page (Insert → Button → Back). Without one, people reach for the browser and lose the filter context they arrived with.

---

8. Put Filters in Slicers, Not the Filter Pane

Hide the Filter Pane from end users. It exposes filters nobody outside the build should be changing, and it sits in the one corner of the screen a reader never checks.

• Slicer visuals on the canvas for anything user-facing
• Slicers along the top or down the left edge
• Sync them across pages so the filter context survives navigation
• Edit interactions to decide which visuals answer which slicer

A slicer is a visual, so it draws on the same query budget as everything in rule 2. A page carrying seven slicers spent most of that budget before the first chart rendered. When a report needs that many, give them a filter page of their own.

On an executive page the right number of slicers is usually zero. A slicer is a question the page is asking the reader, and that page exists to answer one instead.

---

9. Optimize Your Data Model

Both of these can hold the same eight visuals and the same layout. Only one will feel instant.

This is rule 1 in disguise, and I would put it above every other item on this list. A poorly modeled dataset produces a slow report however well the visuals are arranged, which leaves most of the design view downstream of a decision you already made.

Microsoft recommends the star schema as the modeling approach Power BI is optimized for (opens in a new tab), which makes it the shape the engine was tuned against rather than a matter of taste.

• Star schema: fact tables in the centre, dimension tables around them, relationships one-to-many
• Drop unused columns, since each one adds to model size and costs you speed
• Set "Summarize by: None" on anything that should not aggregate, such as names, IDs and categories
• Prefer measures in DAX to calculated columns
• Turn auto date/time on only when you need the time intelligence hierarchies

A dataset under a million rows that still loads slowly has a model problem or a DAX problem. Volume is the first explanation people reach for and the one that holds least often.

---

10. Use Conditional Formatting Strategically

Conditional formatting changes colours, icons and data bars by value. Aimed at two or three numbers it directs the eye. Sprayed across the page it leaves the reader nowhere to look.

• Apply it to KPI cards, green or red against target, and to table columns, data bars for magnitude and icons for status
• Use rules-based formatting rather than gradient, which makes two close values look identical
• Three status colours at most: green on track, yellow warning, red off track
• Leave chart series out of it

A red card gets its value from how rare red is on that page. Format the fourth metric and you have started spending the third one's meaning.

---

11. Add Alt Text to Every Visual

Power BI takes alt text on every visual, and those two minutes pay twice. A screen reader announces it to someone who cannot see the chart, and the next analyst to open the file reads what you thought the chart was for.

Write what the visual shows, what data sits behind it, and what the reader should look for. "Line chart of monthly revenue for the selected region. Look for the Q4 spike."

Many organisations require alt text for WCAG compliance, which is the reason it gets done at all. Documentation is the reason to do it well.

---

12. Whether to Wireframe First

Power BI's build order runs long: data modeling, DAX measures, visual layout, formatting, testing. Move the layout after the model exists and you re-wire visual bindings, revisit measures and re-test interactions.

That is the argument for sketching first, and it is specific to Power BI. Layout is cheap to change before the model exists and expensive afterwards, because the model gets built to match the layout.

It is a trade rather than a rule. A sketch costs you twenty minutes at the point in a project where twenty minutes feels most expensive, and on a three-visual page, or a rebuild of something you have already shipped, it tells you what you already knew. The trade pays when the metric list is still moving, when somebody has to approve the page before it ships, or when the model will be shaped by the layout you land on.

When you do sketch, this order is the one that saves rework:

1. Settle the metrics, the audience, and the decision the page supports
2. Lay the page out at the canvas size from rule 1, so the count in rule 2 is real
3. Put it in front of the person who asked, while changing it is still free
4. Build the model against the metrics that survived that conversation
5. Lay out the visuals, format, test, deploy

A sheet of paper does this, and so does a slide. datawirefra.me (opens in a new tab) does it in about ten minutes with Power BI-shaped pieces already on the palette. Which one you reach for matters less than whether the layout gets argued with before the model is built to serve it.

Eleven of the twelve rules above are about the design view. The one that decides whether any of them matter is the data model.

So if your report is already slow, don't start by rearranging visuals. Open Performance Analyzer, sort by duration, and look at the model first.

How many visuals belong on one page →