Three months. Evenings, a couple of genuinely slow sprints, and one weekend I'm not proud of. That's what went into the regional performance report I built for leadership last year: drill-throughs on every visual, bookmarks that reset the whole page to a clean view, tooltips explaining every metric, a custom theme that matched the company's slide template down to the hex code. I wanted it to be the report people pointed at when they explained what Power BI could actually do.
The demo went exactly the way I'd hoped. The regional leads leaned in. Someone said "this is exactly what we need" out loud, in the room, in front of their boss. I left that meeting certain I'd built the thing.
Six weeks later I opened the workspace's usage metrics report almost by accident, looking for something else. Four opens. Three of them were mine.
The demo lied to me
Not on purpose. Nobody in that room was being polite for my benefit; they meant it when they said it looked useful. But a demo is a rigged experiment. Someone, me, is narrating exactly which button proves the value, the data is fresh and dramatic because I picked the week that made the trend line interesting, and everyone in the room has already blocked out thirty minutes to sit and look at a screen. None of those conditions exist on a Tuesday morning, when the same person has forty unread emails and a report that requires them to remember it exists, open a browser tab, and choose it over the export they already trust.
A good demo tells you the report can hold someone's attention for the length of a meeting. It tells you nothing about whether it can win five unscheduled minutes against everything else competing for them. I'd optimised for the first question and quietly assumed the answer to the second.
Polish is for the portfolio, not the workflow
Here's the part that actually stings: almost none of the three months went into anything the usage numbers would have rewarded. The bookmarks, the tooltip copy, the theme matching the slide deck: that's the stuff that makes a report look finished in a screenshot. It's also the stuff I was most proud of, because it's the stuff that's fun to build and easy to show off.
None of it is what makes someone open a report unprompted at 9am on a Wednesday. That's earned by the report answering a question the person already has to answer that week, faster than their current method. Without ever deciding to, I'd built for the version of this project that would look good in a portfolio or a screenshot, not the version that would get used. Those two projects share a file extension and almost nothing else.
Nobody's Tuesday changed
The report was, to be fair to past me, reasonably well modelled. Real relationships, a sensible star schema, DAX that didn't do anything embarrassing under the hood. That's worth saying, because it means the failure here isn't the one I'll cover on the 22nd, where the actual problem is a flat table wearing slicers as a costume. This report would have passed that audit fine. It still went unopened.
It went unopened because nothing about anyone's week required it. Before I built it, the regional leads got a number from an export someone already trusted, on a cadence nobody had to think about. After I built it, that export still existed, still arrived the same way, and still got opened first, because opening it was already the habit. My dashboard was a second, better route to information people had already found an acceptable first route to. Better doesn't beat already-a-habit. It has to beat it by enough to be worth the friction of switching, and "it looks nicer" isn't that.
What I build differently now
Two things changed after this one. First, before I open Power BI Desktop at all, I ask who is going to open this report, and on what day, instead of what it should show. If nobody can name a specific person and a specific recurring moment, I don't have a dashboard project yet. I have a one-off analysis that wants to be an email.
Second, the ugly version ships first, into an existing meeting, not into a demo scheduled to show it off. If a rough table with the right three numbers gets referenced out loud in a standup, that's the signal to keep going. If it doesn't get mentioned, no bookmark or tooltip fixes that, and I've lost a week instead of three months finding it out.
The Hot Take landing on the 22nd covers what happens when the model itself is the problem. The star schema build on the 28th covers what modelling one properly, from a single flat file, actually looks like. This post sits underneath both of them: you can get the model completely right and still build something nobody needed enough to open.
The way to think about it
A dashboard's real success metric isn't how it looks in the meeting where you unveil it. It's whether, a month later, it has quietly become the thing someone reaches for without being reminded it exists. That's a habit, and habits don't form because the underlying visual is well designed. They form because the thing replaced a worse option in someone's actual week.
I still think the report I built was decent work. It wasn't a decent project, because I never checked whether anyone had a Tuesday that needed it before spending three months making sure it would look good on the day I showed it off.
Frequently Asked Questions
Does this mean the stakeholders lied when they said they needed it?
No. They meant it in the room. Intent expressed in a meeting is real, it just doesn't survive contact with a full inbox and an existing habit. Treat enthusiasm in a demo as interest, not as evidence that a workflow is about to change.
Isn't "nobody opened it" the wrong metric? What if the two or three people who actually mattered checked it?
Worth checking before you panic, and I did. In this case the near-zero was real: the regional leads who'd nodded along in the demo were among the four opens, once each, in six weeks. If your low number turns out to be low-but-correct, hiding a handful of the right people using it properly, that's a different, better problem to have. Check who, not just how many, before you write the post-mortem.
How do you check adoption without it feeling like surveillance?
Power BI's built-in usage metrics report gives you aggregate opens and active users for a workspace or app, not a log of who specifically looked at what, when. Treat it as a health check on the report, not a way to monitor a person.
Isn't this really an organisational politics problem, not a design one?
Partly, and I'm not pretending otherwise. But design still carries some of it: a report that isn't embedded into an existing meeting, or handed a specific owner who references it out loud, has no mechanism to become a habit, regardless of who signed off on building it.
What would you build first if you were starting this project again?
The ugliest version that answers one question, shown inside a meeting that already exists, before any bookmark or tooltip gets built. If that rough version doesn't get referenced unprompted within two weeks, that's the answer, and it's cheaper to learn in week one than in month three.
Does this apply if the report is only for one senior stakeholder, not a whole team?
If anything, more so. A single-person report is easier to verify and easier to lose. Ask that person directly whether they open it without being reminded, rather than reading their reaction in the room where you first showed it to them.