Power BI visualisation techniques that change decisions

Most advanced visualisation advice is about what a tool can render. The harder question is which of those capabilities change what someone decides, and the answer is a much shorter list than the feature set.

A report that is admired and not used has failed, however sophisticated the visuals.

Start from the question, not the dataset

The most common cause of an unused report is that it was built from what was available rather than from what someone needed to decide.

Before choosing a visual, write down:

• The question this answers, in one sentence
• Who asks it, and how often
• What they do differently depending on the answer

If the third line is empty, no visualisation technique will save it. This is the same discipline that separates a working executive dashboard from a wall display, covered in KPI dashboards that Swiss executives actually use.

Encode comparison, because a number alone means nothing

Revenue of CHF 2.4 million is neither good nor bad until it sits next to something. Almost every genuinely useful visual is a comparison in disguise — against plan, against the previous period, against a threshold, or across a category.

What this means in practice:

• Always show the reference. A KPI card with a target line or a delta answers a question; the same card alone generates one.
• Use small multiples rather than one crowded chart. Eight small charts sharing a scale are read faster than one chart with eight series, because the comparison is spatial rather than by colour.
• Reserve colour for meaning. If colour encodes category in one visual and performance in another, readers stop trusting it. One meaning per report.

Design drill paths that follow how people think

The default drill-down follows the data hierarchy. Useful drill follows the question hierarchy, and they are rarely the same.

Someone seeing revenue below plan asks “which region?”, then “which products in that region?”, then “is this a few large accounts or broad?”. A drill path built on the warehouse structure may go region → country → city, which answers a question nobody asked.

Two techniques worth the effort:

Drill-through to a detail page designed for one follow-up question, rather than generic expansion. It costs more to build and it is the difference between a report that answers and one that requires an analyst.

Cross-filtering that is predictable. Powerful and easy to overdo — when every visual filters every other one, users lose track of what they are looking at. Constrain it deliberately and state what filters what.

Techniques that usually are not worth it

Worth naming, because they consume build time:

• Custom visuals from the marketplace, unless there is a specific need. They add a dependency, a maintenance risk and often a data-handling question about where rendering happens.
• Animation and transitions. Impressive in a demo, noise in daily use.
• Dense multi-axis charts. If a chart needs an explanation, it will be misread by whoever did not attend the explanation.
• Real-time refresh where the decision is weekly. It adds cost and load for no decision benefit.

Performance, because a slow report is an unused report

Advanced visuals fail most often on responsiveness rather than design. Three things account for most of it:

• Model shape. A well-structured star schema outperforms a wide flat table at almost any size. This is a modelling decision, not a visual one.
• Measure complexity. Calculations evaluated per row across a large table are the usual cause of a slow page.
• Visual count per page. Every visual is a query. Twenty on a page is twenty queries on every interaction.

The practical rule: if a page takes more than a few seconds, people stop opening it, and the quality of the design becomes irrelevant.

The Swiss data-protection layer

Reports aggregate personal data more often than their authors intend — customer records, employee metrics, sometimes health or financial detail.

Under revDSG/nDSG, and GDPR wherever EU data is involved, three questions belong in the design rather than in a later review:

• Where is the data processed, and who can reach it? Storage location is the easy half; vendor and support access is the half that gets audited.
• Does the report need personal data at all? Aggregates and pseudonymised data usually answer the business question just as well, at a fraction of the obligation. This is the cheapest available fix and it is routinely skipped.
• Row-level security, applied at the model rather than by hiding visuals. Hidden is not the same as inaccessible.

Related reading

• Leveraging Power BI for business intelligence
• KPI dashboards that Swiss executives actually use
• Data, AI & analytics

If you have reports nobody opens and want to know why, book a call. No obligation.