Dashboards against reports

Why this matters

Results are delivered in two broad forms: the dashboard, a live, usually interactive view that people return to, and the report, a document that answers a question at a point in time. Each suits some needs and fails others. A dashboard built when a one-off report was needed goes unused; a static report sent where people needed to monitor something daily is out of date on arrival.

The exam's reporting objective asks you to deliver dashboards or summaries using appropriate methods. This lesson covers the types of dashboard, when a static report is right, choosing KPIs, dashboard layout, and gathering requirements before building.

The lesson

Operational, strategic and analytical dashboards

A dashboard gathers the most important measures for a purpose onto one screen, usually refreshed automatically from its data sources. Dashboards are commonly grouped into three types.

An operational dashboard monitors activity as it happens, for people who act on it the same day: orders awaiting dispatch, calls in the queue, system errors this hour. It needs fresh data, often near real time, clear thresholds and alerts, and very little analysis on screen.

A strategic (or executive) dashboard tracks performance against goals over longer periods, for leaders: monthly revenue against target, customer retention this quarter, year-over-year growth. It needs few, well-chosen KPIs, trends and comparisons with targets, and is refreshed daily or less often.

An analytical dashboard supports investigation, for analysts and managers exploring why something happened: sales by product, region and channel, with filters and drill-down. It is more detailed and interactive, and slower to read.

Many dashboards fail by mixing the three, so they are too detailed for executives and too slow for operations. Deciding which type is being built, and for whom, comes first.

Static reports, and when a PDF is the right answer

A static report, such as a PDF, a slide deck or a printed document, presents a fixed set of results at a point in time. It has advantages a dashboard lacks.

• It is a record: it shows exactly what was known and reported on a date, which matters for board papers, regulatory submissions and audits.
• It carries narrative: explanation, context, caveats and recommendations alongside the numbers.
• It is controlled: everyone sees the same thing, with no filters set differently.
• It needs no special access: it can be emailed, printed and read offline.

A static report is the right answer for one-off analyses, periodic formal reporting, decisions that need a documented basis, and audiences who will not use an interactive tool. A dashboard is right for ongoing monitoring by people who will return to it. Often both are used together: a dashboard for day-to-day monitoring, and a monthly report that snapshots it with commentary.

Choosing the KPIs a dashboard shows

A dashboard's value depends mostly on which measures it shows, and the common failure is showing too many. A screen of thirty numbers is a data dump, and none of them gets attention.

Good KPI selection starts from the dashboard's purpose and audience: what decisions are made with it, and which measures show whether things are on track. Useful principles include:

• Few: a handful of headline KPIs, with detail available on demand.
• Defined: each KPI has an agreed, documented calculation, the same one used everywhere else.
• With context: a number alone says little, so each KPI is shown against a target, a previous period or a benchmark, often with an indicator of direction.
• Actionable: someone can influence it, and a change in it would prompt action.
• Balanced: a mix that avoids optimising one measure at another's expense, such as speed alongside quality.

Measures that look impressive but prompt no decision, sometimes called vanity metrics, such as total page views without context, are better left off.

Layout: the most important number first

Readers scan a screen in a predictable pattern, usually starting at the top left in left-to-right languages. Dashboard layout uses that.

• Put the most important information top left: the headline KPIs, often as large numbers on cards with their comparison to target.
• Place supporting charts below or to the right, from summary to detail.
• Group related measures together, with clear section headings.
• Keep filters in a consistent place, usually along the top or side, and show which are applied.
• Use consistent scales, colours and formats so related charts can be compared.
• Leave white space: crowding makes everything harder to read.

A dashboard should answer its main question in a few seconds, before any interaction. If a reader must click or scroll to find the key number, the layout has failed.

Mock-ups and requirements before building

Dashboards are expensive to build and change, so the design should be agreed before the build.

Requirements gathering establishes who will use the dashboard, what decisions they make, which measures and breakdowns they need, how fresh the data must be, how they will access it, and who may see what. It also establishes data availability: whether the data for each requested measure exists, at the needed grain and freshness.

A mock-up or wireframe, a sketch of the layout with placeholder charts, lets users react to the design before any data work is done. Changes at that stage cost minutes; after the build they cost days. Reviewing the mock-up with real users often reveals that half the requested measures are not needed and one essential one was missing.

After release, feedback and usage data, such as which dashboards are opened and which filters are used, show whether the dashboard is doing its job, and unused dashboards are candidates for retirement.