How to Present KPIs So People Actually Read Them

Every team has a KPI dashboard. Almost no team has a KPI dashboard people open voluntarily.

The usual failure mode isn't the data — it's the format. A grid of tiles, a dozen filters, and an assumption that the viewer will do the work of finding the one number that matters to them. That assumption is wrong more often than not. Most people looking at a KPI report want an answer, not an exploration tool.

This post is about the gap between a KPI dashboard and a KPI report — and a few concrete changes that make the difference.

The dashboard is for you. The report is for them.

Dashboards are exploration surfaces. They're built by the person closest to the data, for the person closest to the data. That's fine — until that same surface gets forwarded to a VP, a client, or a board member who has ninety seconds and no context.

The fix isn't "make a simpler dashboard." It's recognizing these are two different jobs:

• Exploration — filters, drill-downs, ad hoc queries. Built for analysts.
• Delivery — a fixed, opinionated view with a clear takeaway. Built for decision-makers.

Most teams only build the first one, then ship it to people who needed the second.

Three things that actually move the needle

1. Lead with the delta, not the number. "$482,000 revenue" tells a reader nothing on its own. "$482,000 revenue, up 12% vs. last quarter, ahead of forecast" tells them everything they need in one sentence. If your KPI report doesn't answer "is this good or bad?" in the first three seconds, it's not doing its job.

2. One KPI per screen's worth of attention, not twelve. The instinct is to show everything, because someone might ask. Resist it. A report with twelve equally-weighted metrics has zero hierarchy — the reader has to build the hierarchy themselves, and most won't bother. Pick the two or three that matter this week and let the rest live one click away.

3. Annotate the "why," not just the "what." A chart showing a dip in week 34 is a question mark. A chart showing a dip in week 34 with a one-line annotation — "planned maintenance, 3 days" — is a closed loop. The annotation is often more valuable than the chart itself, and it's the thing most tools make hardest to add.

What this looks like end to end

Here's the same underlying dataset — quarterly revenue by region, from the Northwind dataset — taken from raw query to something you'd actually send someone.

Start with the query. This is a workspace-level object, not tied to any one view:

select
  region,
  date_trunc('quarter', order_date) as quarter,
  sum(unit_price * quantity * (1 - discount)) as revenue
from orders
join order_details using (order_id)
join customers using (customer_id)
group by region, quarter
order by quarter

From there, the same data can go two directions. As a dashboard tile, it's a line chart with a region filter — useful for whoever's actively digging into the numbers. As a report, it's a single annotated view: this quarter, this region, this delta, this one sentence of context.

The point isn't that one is right and one is wrong. It's that they're different jobs, and most tools force you to use the exploration surface for both.

Building this in Infigured

This is close to the default posture in Infigured — the same underlying query backs both the exploration canvas and the published report, but they're genuinely separate surfaces. You build the dashboard for yourself on the Canvas, then publish an opinionated, annotated version as a Document or Presentation without duplicating the query or rebuilding the chart.

If you're currently doing this by taking screenshots of a BI tool and pasting them into slides once a month, that gap — between the thing you built and the thing you can actually hand someone — is exactly the problem this solves.

---

Next in this series: how the same underlying data can support four completely different output surfaces without rebuilding anything — using this same Northwind dataset as the running example.