Power BI Dashboard Design Tips - What Works on Real Client Dashboards

A few months ago I stood in a distribution centre in western Sydney looking at a 65 inch TV mounted above the dispatch desk. It was showing a Power BI dashboard with 31 tiles on it. I counted. Nobody on the floor could tell me what any of them meant, and the shift supervisor admitted he had stopped looking at it by about week two. He ran the shift off a whiteboard instead.

That dashboard cost real money to build. The data behind it was good. The model was solid. It failed at the last step, the bit where a person looks at a screen and has to understand something in a few seconds.

Microsoft has a short documentation page called Tips for designing a great Power BI dashboard. It is under a thousand words and most people skip it because it looks like common sense. I think it is one of the more useful pages in the Power BI docs, and I also think it lets people off the hook in a few places. Here is my read on it after a lot of dashboard builds for Australian businesses.

First, a dashboard is not a report

This trips people up constantly. In Power BI, a dashboard is a specific thing: a single canvas in the Power BI service made of tiles pinned from one or more reports. A report is the multi-page, interactive, slicer-heavy thing you build in Desktop.

Microsoft's guidance is clear about the job of each. The dashboard is an overview, one place to monitor the current state of the data. The detail lives in the reports underneath, and readers can click through a tile to get to it. The docs put it bluntly: don't put a detail on the dashboard unless that is what your readers need to monitor.

Most bad dashboards I see are reports that somebody has squashed onto one screen. If you remember nothing else from this post, remember that a dashboard answers "is everything OK?" and a report answers "why not?".

Start with who is looking at it, and where

The documentation opens with audience questions. How will they use it? What metrics help them decide something? What do they need to be successful?

These sound like workshop filler. They aren't. The question I'd add, and the one we always ask in discovery, is "what will you do differently if this number changes?" If the answer is a shrug, the number does not belong on the dashboard. It might belong in a report. It might belong nowhere.

The docs also ask where the dashboard will be displayed, which is the question that would have saved that warehouse TV. A big monitor viewed from a desk can carry more content. A phone carries far less. A wall-mounted screen viewed from eight metres away can carry maybe four or five big numbers and one chart. Design for the actual viewing distance, and if a good share of your audience is on mobile, build the phone layout on purpose instead of hoping the default stacks nicely. It won't.

One screen, no scroll bars

Microsoft's advice here is two questions: can you avoid scroll bars, and is the dashboard too cluttered? Remove everything but the essential information.

I'd go harder than that. Scrolling on a dashboard is a design failure, full stop. Anything below the fold might as well not exist, because the people who needed it will never see it and the people who scroll down to find it would have been better served by a report.

The hard part is not technical. It is political. Every stakeholder in the room wants their metric on the main screen, and the path of least resistance is to say yes to all of them. That is how you end up with 31 tiles. Our rule of thumb on client work is somewhere between six and ten tiles, and every addition past that has to bump something else off. People complain during the workshop and thank you a month later.

Make the important number big

If every tile is the same size, nothing stands out. The docs recommend card visuals for showing a key number prominently, and then add a short sentence that is easy to miss: be sure to provide context.

I'd put that sentence in bold. A card that says "Revenue $3.4M" tells me almost nothing. Is that good? Compared to what? The same card with "vs $3.1M target" or "down 6% on last month" underneath is something I can act on. A number without a comparison is trivia.

Placement matters too. The guidance is to put the highest level information at the top left and add detail as you move right and down, because that is how most of your audience reads. It's simple and it works. I still regularly see the most important KPI parked in the bottom right corner because that was the last tile somebody pinned.

Picking the right chart

This is the longest section of Microsoft's page and the one with the most practical value. The headline is "avoid variety for the sake of variety", which I wish was printed on the Power BI Desktop splash screen. Nobody is impressed that you used nine different visual types.

The specific tips, with my commentary:

No 3D charts. Agreed, and I'd extend it to anything that makes the reader work to decode the shape before they can read the value.

Go easy on pie charts, donuts and gauges. The docs say circular charts "aren't ideal", then in the next breath say pie charts are fine with fewer than eight categories and gauges are great for status against a goal. That is a bit soft for my taste. Eight slices is too many. My limit is three or four, and only when the point is part-to-whole. If people need to compare the slices to each other, use a bar chart, because humans compare lengths far better than angles. On gauges I mostly disagree with Microsoft. A gauge takes up a big square of screen to show one number against one target. A card with a target line does the same job in a quarter of the space.

Keep scales, ordering and colours consistent. If Queensland is blue on one tile it should be blue on every tile. This sounds fussy until you watch an executive misread a chart in a board meeting because the colours swapped between visuals.

Keep numbers short. The docs suggest no more than three or four numerals, scaled to thousands or millions. "3.4 million" reads faster than "3,400,000". Finance teams sometimes push back on this because they want precision. Give them precision in the report. The dashboard is for the glance.

Don't mix time frames. One tile showing last month next to another showing a specific filtered month is a recipe for wrong conclusions. I'd add: put the period in the tile title. "Sales - October" beats "Sales" every time, and it saves you a dozen "what period is this?" emails.

Don't put big and small measures on one axis. If one series is in the millions and the other in the thousands, the small one flattens into the baseline. Use a secondary axis or split it into two charts. My preference is two charts, because dual axes get misread more often than people admit.

Strip unnecessary data labels. Readers can usually judge a bar chart without a number stuck on every bar.

Sort deliberately. Sort by the measure when you want to highlight the highest or lowest. Sort by the category when people need to find a specific item in a long list. Default sort order is rarely what you want, and it is one of the quickest fixes on any dashboard review we do.

What the docs don't cover

A few things I'd add from experience.

Dashboards rot. A dashboard that was right in March is often wrong by September because the business changed and nobody pruned the tiles. Put a review in the calendar every quarter. Check the usage metrics. If a tile gets no clicks and nobody can say what decision it supports, remove it.

Full-screen mode is underused. Microsoft mentions it in one line. For wall displays and meeting presentations it makes a real difference, since the browser chrome and navigation pane disappear and the tiles get the whole screen.

Design skill is a real gap. The docs point to Stephen Few's books, including Information Dashboard Design, and to Edward Tufte. Those recommendations are spot on and I'd take them seriously. Most Power BI developers come from a data background and have never been taught visual design. A weekend with Few's book will improve your dashboards more than any new feature Microsoft ships this year.

Power BI's dashboard feature itself is a little neglected. Honest assessment: most of Microsoft's investment over the last few years has gone into reports, and plenty of teams now build a one-page summary report and skip dashboards entirely. That is a legitimate choice. You lose alerts on tiles and the ability to combine tiles from several reports, but you gain better formatting control. Everything in this post applies either way, since the design problem is the same.

A quick test before you publish

Show the dashboard to someone who was not involved in building it. Give them five seconds, then hide it. Ask them what the most important number was and whether things are going well or badly.

If they can't answer, you are not done. Take things off until they can.

This is the kind of work we do with clients through our Power BI consulting practice, often as part of a broader business intelligence engagement where the dashboard is the final step after the data model is sorted. If you have a dashboard nobody looks at and you'd like a second opinion on why, get in touch. It is usually fixable in less time than it took to build.