Dashboards executives actually open: designing reports around decisions

The clearest signal of a failed reporting project is a dashboard that was signed off, launched with a presentation, and is now opened by its author and nobody else.

It is rarely a visual design failure. It is that the dashboard answers a question nobody is accountable for, at a cadence that does not match any decision, in a format that cannot be read where the reader actually is.

Start from decisions, not from data

The first conversation should not be about data at all. For each potential audience, establish four things:

1. What recurring decision do you make? Not "I need visibility of sales", "every Monday I decide where to move inventory between depots."
2. How often? Weekly, daily, monthly. This determines the refresh requirement and, more importantly, whether the figure needs to be live or merely current.
3. What would change your mind? The number that, if it moved, would make you act differently. That is your KPI; everything else is context.
4. What do you do today instead? Usually a spreadsheet someone maintains. Understanding it tells you what the report must replace, and why previous attempts failed.

Write the answers down. A dashboard built from a decision inventory has a defensible reason for every element on it, and, just as usefully, a defensible reason to refuse additions.

Choose fewer KPIs than you want to

The pressure in every stakeholder workshop is additive. Everyone has a number they would like on the page, and the path of least resistance produces twenty-four tiles that nobody reads.

Our working rule: one primary metric, three to five supporting metrics, and everything else behind a drill-through. If a stakeholder insists on a sixth, ask which of the existing five it replaces. That question does more for report quality than any design technique.

For each KPI on the page, three things must be true:

• Someone is accountable for it by name.
• It has one agreed definition, visible on the page or one click away.
• A movement in it implies an action, not merely an explanation.

A metric that fails the third test is context. Context belongs below the fold or on a second page.

Present variance honestly

Most executive reporting shows a number and a comparison. How that comparison is framed changes behaviour more than the number does.

State the basis on the page. "vs prior year, comparable period" or "vs budget, excluding FX". A reader who has to ask what the comparison is will stop trusting the figure.

Handle incomplete periods explicitly. A month-to-date figure against a full prior month looks alarming and means nothing. Either compare like for like or label the mismatch. We cover the mechanics in DAX patterns that scale.

Avoid month-on-month as the default. For most businesses it is dominated by noise and calendar effects. Rolling twelve months, or a comparison against the same period last year, tells you more about the business and less about the number of trading days.

Show the distribution, not only the average. "Average delivery time improved to 2.4 days" can coexist with a worsening tail that is what customers actually complain about. A simple range or percentile alongside the mean prevents a specific class of wrong decision.

Structure the page the way people read

The top-left area carries the primary metric and its basis. Supporting metrics sit in one consistent row. Trend sits below the headline, because the direction matters more than the point value in nearly every executive decision. Breakdown (by region, product, channel) sits lower still or on a drill-through.

Two structural habits that help:

One question per page. A page titled "Trading" that mixes revenue, headcount and inventory is three pages in a trench coat. Separate them and the navigation becomes obvious.

Put the answer in the title. "Revenue 4% behind budget, driven by Northern region" is a more useful page title than "Revenue dashboard". It also forces you to know what the page is saying.

Interaction: less than you think

Slicers feel like empowerment and are frequently where reports go to die. Every slicer is a decision the reader has to make before they see anything, and each one is a chance to produce a view that looks wrong.

• Default every slicer to the most useful state, not to "all". A report that opens blank until you choose a date is a report nobody opens twice.
• Use bookmarks sparingly. They are excellent for a guided narrative and terrible as a navigation system; a reader who cannot tell what state they are in will not trust what they see.
• Make drill-through obvious. A hidden right-click path is a feature only the author knows about. Add a visible button.
• Avoid tooltips as the home of important information. They are unavailable on touch devices and invisible when exported.

Accessibility is not a separate workstream

Roughly one in twelve men has some form of colour vision deficiency, and that proportion does not drop among executives.

• Never encode meaning in colour alone. Red and green bars need a label, a sign, or a position difference as well.
• Check contrast for text and for data marks against their background. Brand palettes frequently fail; where a client's palette fails we say so and propose an accessible variant rather than shipping it quietly.
• Write alt text on every visual. It is also what makes an exported or narrated version intelligible.
• Set a sensible tab order and test the page from the keyboard.
• Do not rely on hover. Anything only available on hover is unavailable to a significant share of readers.

This is both a legal expectation in several of our markets and a straightforward quality issue: a report that is hard to read is a report that gets replaced by a spreadsheet.

The mobile layout decides whether it is read

Executives read between meetings, on a phone. A desktop-only report is a report that will be opened once at a laptop and then ignored.

Build the phone layout deliberately: the primary metric, its comparison, the trend, and nothing else. Phone layouts in Power BI are a separate canvas, which is an advantage. It forces the editorial decision about what actually matters.

Validate against the source of record before launch

The fastest way to destroy a reporting programme is a launch meeting in which a finance director finds a number they recognise as wrong.

Before anyone sees it: reconcile every headline figure to the source of record for several periods, including one with known adjustments. Where there is a discrepancy, resolve it and write down the resolution. Where a legacy report turns out to have been wrong, say so explicitly and formally, people have been making decisions on it.

Measure adoption and act on it

After launch, use the activity log. Who opens it, how often, which pages, and which drill-throughs are used.

Then act on what it says. A page nobody has opened in three months should be retired rather than maintained, and a drill-through everyone uses should probably be promoted to the main page. Reporting estates grow by accretion unless someone is willing to delete, and the usage data is what makes deletion defensible.

That same willingness to retire content is what makes a migration affordable, see BI migration without a rollback.

Report performance is a design decision

A report that takes twelve seconds to load is a report that gets opened once. Performance is usually treated as an engineering problem to be fixed afterwards, but most of it is decided when the page is designed.

What costs time, in rough order:

• Too many visuals on one page. Each visual issues at least one query. Twenty visuals is twenty queries competing for the same capacity; eight well-chosen ones feel instant.
• Visuals with high cardinality. A table with 40,000 rows is not a visualisation, it is an export in disguise, and it is the slowest thing on most pages.
• Complex measures evaluated per row. A margin percentage computed inside a matrix across thousands of cells will dominate the page load.
• Custom visuals. Some are excellent and some render badly at scale. Test the specific one with real volumes before standardising on it.
• Bookmarks with many hidden layers. Hidden visuals still query in some configurations.

Our working target is a page that renders in under three seconds on realistic volumes, measured with Performance Analyzer rather than estimated by feel. Where that is not achievable with the current design, the design changes, not the expectation.

The operating rhythm matters more than the report

The most-used reports we have built share something that has nothing to do with design: they are attached to a meeting.

A weekly trading report that is opened at the start of a weekly trading meeting gets used. The same report with no meeting attached gets opened for a fortnight and then forgotten, regardless of how well it is built.

So part of the delivery is agreeing the rhythm:

• Who opens it, when, and what decision follows. If there is no decision, there is no report.
• Who owns the commentary. Numbers without narrative get interpreted inconsistently; a named owner adding two sentences before a meeting is worth more than three extra visuals.
• What happens when it shows a problem. A threshold breach with no defined response trains people to ignore thresholds.

This is why our first workshop is a decision inventory rather than a requirements gathering session. Requirements produce a report; decisions produce a report that is used.

Exports are a signal, not a failure

Report authors tend to treat "they just export it to Excel" as a defeat. It usually is not.

Sometimes export is the correct workflow: the user needs to combine your numbers with something you do not hold, or send a subset to someone outside the organisation. The right response is a clean export path with sensitivity labels applied, not a campaign against spreadsheets.

But a high export rate on a report nobody has asked to extend is a diagnostic. It usually means the report answers a question near the one the user has, and they are doing the last step themselves. Find out what that step is. It is normally a measure you have not built, or a dimension you have not exposed, and the export rate falls on its own.

Either way, the activity log tells you. Watch it.

If the problem you actually have is that the numbers are not trusted rather than that the dashboard is ugly, that is a modelling conversation: semantic model design is where it starts. Either way, a technical review will tell you which of the two you are dealing with.