Business Intelligence & Dashboards

01

What BI actually is

BI sits between the database and the decision-maker. Its job is self-service: let a manager, an executive, or a minister's office answer their own questions — "how are we tracking this quarter?", "where are the hotspots?" — interactively, without an analyst in the loop for every query. A report is a detailed, often multi-page view of the data; a dashboard is a single screen of the most important indicators at a glance.

The distinction that matters: BI is mostly about analytical reading of data — the OLAP side of the database page — not transactional updates. You're summarising history to inform a decision, which shapes both the data model and the design.

02

The data model underneath

The most important part of a good dashboard is invisible: the data model. Beginners point a tool at a giant flat spreadsheet and wonder why it's slow and the numbers don't add up. Professionals build a star schema — the standard BI model — first.

A star schema splits data into fact tables (the events you measure — sales, cases, incidents, one row each) surrounded by dimension tables (the context you slice by — date, location, category, person). They connect by keys, exactly like the relational joins from the database page. This structure is what makes a dashboard both fast and correct: filters propagate cleanly from dimensions to facts, and the same measure stays consistent across every chart. Get the model right and the visuals are easy; get it wrong and no amount of design saves you.

03

Measures and metrics

On top of the model sit measures — the calculations that turn raw rows into the numbers people care about: a total, an average, a year-on-year change, a rate per capita. In Power BI these are written in a formula language (DAX); the key idea is that a measure is dynamic — it recalculates for whatever the user has filtered to, so "total cases" instantly becomes "total cases for this district, this month" as they click.

The discipline is to define each metric once, centrally, and reuse it everywhere — so "open cases" means the same thing on every page and in every conversation. Inconsistent or ad-hoc metrics are how two dashboards end up disagreeing and trust collapses. A small, well-defined set of trusted measures is worth more than a sprawl of one-off calculations.

04

One question per page

The most important design rule, and the one most often broken: each page should answer a single question. "How is the branch performing this quarter?" or "Where are open cases concentrated?" — one focused question per screen. Cramming several questions onto one page dilutes the message, overwhelms the reader, and slows the page down.

This forces the healthy discipline of knowing what each view is for. If you can't say the one question a page answers, it's not finished — it's a pile of charts. Multiple questions become multiple pages, navigable but distinct.

05

Visual hierarchy

People read a dashboard the way they read a page: top to bottom, left to right. So the layout should put the most important thing — the headline KPIs, the answer to the page's question — in the top-left, where the eye lands first, and let detail flow down and right. A clear visual hierarchy guides attention without the reader having to hunt.

The undervalued tool here is white space. Empty space isn't wasted — it's what separates groups, reduces clutter, and directs the eye to what matters. A clean, well-spaced dashboard with consistent fonts, colours, and alignment reads as trustworthy; a cramped, mismatched one reads as amateur, whatever the numbers say.

06

Performance

A dashboard that takes ten seconds to load is a dashboard people stop opening, so performance is a design constraint, not an afterthought. A few concrete rules from practice:

• Cap the visuals per page — roughly 8–12. Past ~15, load times become noticeably sluggish, especially on older devices.
• Filter at the source — pull only the data you need; high-cardinality columns and huge unfiltered tables are the usual culprits behind slow pages.
• Keep assets light — large background images (over ~2 MB) and heavy custom visuals drag the whole report down.

Most of this traces back to the data model: a tidy star schema with the right granularity is the single biggest lever on speed.

07

Design for the audience

The most common dashboard mistake isn't technical — it's psychological: you design for yourself, not your audience. As the analyst you want to show everything you found; the executive wants the few KPIs that bear on their decision. The fix is the same as on the communication page — start from who's reading and what they decide, then ruthlessly cut everything that doesn't serve that. Pick the handful of KPIs aligned to the audience's goals, and send the rest to a detail page they can drill into if they want.

08

Mobile and accessibility

Decision-makers read on phones, so a dashboard often needs a mobile layout — and that's not the desktop view shrunk. Design the phone version deliberately: 3–5 key metrics, stacked vertically for thumb-scrolling, with touch targets big enough to tap (around 44 pixels). Power BI lets you build this mobile layout alongside the desktop one.

Accessibility belongs here too — sufficient colour contrast, not relying on colour alone to carry meaning, sensible labels. In government work it's frequently a requirement, not a nicety, and it's simply good design: a dashboard everyone can read is a dashboard that does its job.

09

Where it shows up in my work

10

Refresh in 60 seconds

Practical limits and rules on this page reflect current Power BI design guidance (Microsoft Learn and practitioner write-ups) alongside hands-on experience.