# Building a BI Dashboard That's Actually Useful > A dashboard is an answer to a recurring question, not a pile of charts. Start from the decision, pick metrics that change minds, and design something people actually open. --- # Building a BI Dashboard That's Actually Useful You opened your BI tool, dragged in some charts, and shipped a dashboard. A month later, nobody's looking at it - except to screenshot a number that goes up and to the right for a slide. The data is correct, the charts are pretty, and it changes exactly zero decisions. It's wall art. This guide is about the other kind of dashboard: the one a real person opens on a Monday because it tells them something they need to *act* on. The trick is not better charts. It's working backward from a decision someone actually makes, choosing metrics that move that decision, and laying it out so the answer hits the eye first. We'll stay tool-agnostic - everything here applies whether you're in Metabase, Looker, Power BI, or a spreadsheet - because the thinking is what's missing, not the software. ## How to read this - **Need to fix a dashboard nobody uses right now?** Jump to [Phase 3: Designing One People Actually Use](03-designing-one-people-use.md) and start with the trap checklist near the top. - **Want it to finally make sense?** Read in order - each phase builds on the last. We start with what BI even *is*, then which metrics earn a place, then how to lay them out. ## The phases 1. **[What BI Actually Is](01-what-bi-actually-is.md)** - business intelligence is helping people make decisions with data. A dashboard is an answer to a recurring question. Start from the decision and work backward to the metric. 2. **[Metrics That Inform vs Vanity Metrics](02-metrics-that-inform.md)** - a useful metric changes a decision; a vanity metric only feels good. The right aggregation, the right denominator, and the context (comparison, target, trend) that makes a number mean something. 3. **[Designing One People Actually Use](03-designing-one-people-use.md)** - layout for the eye, the right chart for the question, and ⚠️ the traps that quietly mislead: bad axes, wrong aggregation, no context, and the dashboard with no owner. > Deeper material - where the numbers *come from* (modeling, joins, the warehouse) and how to write the queries behind each tile - lives in its own guides. See [Warehouses vs Lakes](/guides/warehouses-vs-lakes) and [Querying Basics: SELECT and WHERE](/guides/querying-basics-select-where). This guide is about turning data you already have into decisions. --- # What BI Actually Is Somewhere along the way, "BI" got reduced to "make charts." Someone asks for *"a dashboard for the marketing team,"* and the reflex is to open the tool and start dragging fields onto a canvas. That reflex is exactly why so many dashboards end up unused - it skips the only question that matters. **Business intelligence is not about charts. It's about helping a specific person make a specific decision with data.** Hold that, and you stop building piles of charts and start building answers. ## What "business intelligence" actually is BI is the practice of turning data a business already has into something a human can *act on*. The field exists to close one gap: between "we have the data somewhere" and "I knew what to do, so I did it." The warehouse, the queries, the charts - all of it is plumbing in service of that one moment of someone deciding. The tools make this easy to forget. A blank canvas and a hundred chart types makes the job feel like *visualization*, so people optimize for "looks impressive in a meeting" instead of "helped someone choose." A beautiful chart that changes no decision has failed at the actual job, no matter how good it looks. πŸ’‘ **Key point.** The unit of value in BI is not a chart - it's a *decision that got made better because of data.* Which metric? The one tied to the decision. Which chart? The one that answers the question fastest. Should a tile even exist? Only if someone would act differently because of it. ## A dashboard is an answer to a recurring question A dashboard is the standing answer to a question someone asks over and over: *"Are we on track to hit this quarter's target?"* *"Is the new signup flow leaking users?"* *"Which support queue is on fire today?"* If a question gets asked every week, stop answering it by hand - build a dashboard so the answer is always on the wall. The common wrong picture is "a dashboard is where we put all our important numbers." That gives you a junk drawer: thirty tiles, no focus, a viewer who doesn't know where to look - because it tries to answer every question at once, it answers none. A good dashboard has a *job* you can say in one sentence: "This tells the head of support, every morning, whether any queue is backing up." Everything on it serves that sentence; a tile that doesn't help answer the question is clutter. ⚠️ **The "one dashboard to rule them all" trap.** When someone asks for "a dashboard for the whole team," they're usually describing several different questions belonging to several different people. Resist cramming them together - two focused dashboards beat one that tries to do everything and serves no one. ## Start from the decision, work backward to the metric This is the move that separates useful dashboards from wall art. Don't start with the data you have - start with a decision someone makes, and walk *backward*. ```text DECISION what will someone actually do differently? β”‚ e.g. "pause the ad campaign if cost-per-signup β”‚ climbs above our target" β–Ό QUESTION what do they need to know to decide? β”‚ e.g. "what is cost-per-signup this week, β”‚ and is it above target?" β–Ό METRIC which number answers that question? β”‚ e.g. ad spend Γ· new signups, this week, β”‚ with the target line drawn on β–Ό DATA where does that number come from? e.g. the ads spend table + the signups table ``` *What just happened:* We started at the thing that matters - a decision someone will actually make - and let it dictate everything downstream. The decision chose the question, the question chose the metric, the metric told us which data to pull. Notice the data comes last. That's the opposite of the usual order, and it's why the result stays focused: every tile traces back to an action someone takes. The natural order is to start from the data ("we have a signups table, let's chart signups over time") and hope a decision falls out. It rarely does - you end up with charts of whatever was easy to query, not charts of what anyone needed. Working backward feels slower for the first five minutes and saves you from building the wrong thing for the next five weeks. πŸͺ– **War story.** A team I worked with spent two weeks building a gorgeous "executive overview" - twenty tiles, every department represented. The CEO opened it once. When we finally asked what decision she made each Monday, the answer was tiny: *"whether to greenlight more hiring."* That needed three numbers: revenue trend, runway, and headcount plan vs actual. We deleted seventeen tiles. She opened the new one every week. Ask what they *decide* before you build anything. **The test for any tile.** Before a chart earns a spot, finish this sentence: *"If this number changed, someone would ___."* If you can't finish it with a real action, the tile is decoration - that one test cuts a bloated dashboard in half. ## When you don't know the decision yet Sometimes you're handed "build a dashboard" with no decision attached. That's not a reason to start dragging charts - it's a reason to go ask. Interview the person who'll use it: - *"What do you check first thing in the morning, and why?"* - *"Last time you changed your plans because of a number, what was the number?"* - *"If this dashboard could answer one question, what would save you the most time?"* Their answers hand you the decision, the question, and usually the metric. The interview isn't overhead - it *is* the design work. Skipping it is how you end up building wall art. ## Recap 1. **BI is about decisions, not charts.** The unit of value is a decision made better because of data. 2. **A dashboard is the standing answer to a recurring question.** Give it one job you can say in a sentence; everything else is clutter. 3. **Work backward: decision β†’ question β†’ metric β†’ data.** Touch the data last. If a tile's change wouldn't make anyone act, it's decoration. 4. **No decision in hand? Go interview the user.** That conversation is the design, not a detour around it. Next: which numbers earn a place on the dashboard, and why "total signups ever" feels great and tells you nothing. --- # Metrics That Inform vs Vanity Metrics Picture two numbers on a dashboard. One says **Total signups: 1,284,000** - big, green, always climbing, great in a board deck. The other says **Active users this week: 8,200, down 4% from last week.** Only one will ever make anyone do anything: the first can literally never go down (it's a cumulative count), so it can't tell you whether you're winning or losing. The second just told you something's slipping. That difference is the whole game of this phase. A **vanity metric** feels good and informs nothing; a metric that informs *changes a decision*. Here's how to tell them apart, and how to build numbers that carry meaning. ## The dividing line: does it change a decision? A vanity metric mostly goes up and to the right, looks good, and wouldn't change anyone's plans no matter what it did. A useful metric is one where a different value leads to a different action. πŸ“ **Terminology.** *Vanity metric* - a measurement chosen because it flatters (big, always rising, easy to grow) rather than because it informs a decision. The classic tell: you can't imagine an action you'd take if it dropped. Run any metric through the question from Phase 1: *"If this changed, what would someone do?"* | Metric | If it changed, you'd... | Verdict | |---|---|---| | Total signups ever | ...nothing. It can't drop, and it doesn't tell you if anyone's still here. | Vanity | | Active users this week | ...investigate a drop, double down on a rise. | Informs | | Conversion rate this week vs last | ...change the funnel if it dropped. | Informs | | Revenue this month vs target | ...push sales / cut spend if you're behind. | Informs | Vanity metrics tend to be **cumulative all-time totals**; useful ones are **rates, recent windows, and comparisons** - the next three sections show why. ⚠️ **Vanity metrics aren't lies - they're just unactionable.** "Total signups" is a real, correct number. The problem isn't accuracy; it's that it can't lose. Anything that only ever goes up can't tell you when you're in trouble, and a metric that can't deliver bad news can't drive a decision. ## Choosing the right aggregation An aggregation is how you squash many rows into one number - count, sum, average, median, percentile. The one you pick decides what story the number tells, and the wrong one quietly lies. "Average" is the reflex, and it's often the wrong one - averages get dragged around by a few extreme values, medians don't. ```text Page load times (seconds) for 9 sessions: 0.4 0.5 0.5 0.6 0.6 0.7 0.8 0.9 14.0 └── one stuck session Average (mean): 2.1 s ← dragged up by the single 14 s outlier Median: 0.6 s ← the typical experience, unmoved ``` *What just happened:* Eight of nine users had a snappy sub-second load; one session hung at 14 seconds. The **average** says "2.1 seconds - kind of slow," painting almost everyone as having a bad time when they didn't. The **median** says "0.6 seconds - the middle user is fine," true, but it hides that one user had an awful time. Neither is "right" alone - they answer different questions. Typical experience? Median. Anyone having a terrible time? A percentile (like the 95th) that surfaces the tail. πŸ’‘ **Key point.** The aggregation is a decision, not a default. *Typical* β†’ median; *total volume* β†’ sum; *worst-case* β†’ a high percentile. Reaching for "average" out of habit is how dashboards mislead while being technically correct. **The gotcha.** Many BI tools default new tiles to *sum* or *average* with one click. Always ask whether summing or averaging this column actually means anything - summing a column of percentages is nonsense, and the tool will happily do it anyway. ## Choosing the right denominator A raw count rarely means anything until you divide it by something. "47 errors" - out of how many requests? The denominator turns a count into a *rate*, and a rate is what you can compare and act on. Counts grow as your business grows, which makes them sneakily misleading - more users means more errors, more tickets, more everything, even while things get *better* per user. ```text January June Support tickets 300 900 ← "tickets tripled! we're drowning!" Active users 10,000 60,000 ───────────────────────────────────── Tickets per user 0.030 0.015 ← actually HALVED per user ``` *What just happened:* The raw ticket count tripled, which looks alarming and would push you to panic-hire support staff. But you grew 6x over the same period - per active user, tickets *halved*. Support improved, not worsened. The raw count pointed at exactly the wrong decision; the denominator (active users) rescued it. ⚠️ **Pick a denominator that matches the question.** "Errors per request" answers "how reliable is the service?" "Errors per user" answers "how many people got hurt?" Same numerator, different denominators, different decisions. ## Add context: a number alone means nothing "Revenue: $84,000." Good? Bad? No idea - a single number has no meaning without something to compare it against. Context converts a number into a judgment. Three kinds are worth adding, and the best tiles have all three. **1. Comparison - versus what?** Show the number next to a reference point: last week, last month, same period last year. The comparison is where the meaning lives. ```text β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ Revenue (this week) β”‚ β”‚ β”‚ β”‚ $84,000 β”‚ β”‚ β–² 12% vs last week β”‚ ← the comparison turns a number into news β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ ``` *What just happened:* "$84,000" became "$84,000, up 12% from last week" - suddenly a story you can act on. Without the comparison, a viewer has to remember last week's number to know if this is good. The dashboard's job is to carry that memory so they don't have to. **2. Target - versus where we wanted to be.** A goal line tells the viewer whether the number is good *enough*, not just whether it moved. **3. Trend - which way and how fast.** One number is a dot; a small line chart behind it shows direction. "Up 12% this week" is fine, but a sparkline showing four straight weeks of climbing tells a more decision-ready story than one that's bouncing around. πŸ’‘ **Key point.** A bare number is a trivia question. *Number + comparison + target + trend* is a decision. When a tile feels useless, it's almost always missing one of these three. ## Recap 1. **The line between vanity and useful is "would it change a decision?"** Cumulative all-time totals almost always fail this; rates and recent windows pass it. 2. **Aggregation is a choice.** Average gets dragged by outliers - reach for median for "typical," a percentile for "worst case." Don't ship the tool's default blindly. 3. **Counts need denominators.** A rate (per user, per request) survives growth; a raw count gets misleading as you scale. 4. **A number alone means nothing.** Give it a comparison, a target, and a trend. Next: arranging these numbers so the most important answer hits the eye first - and the visual traps that mislead even with the right metrics. --- # Designing One People Actually Use You've got the right metrics with the right context. Now comes the part where good data still goes to waste: the layout. A viewer's eye lands somewhere first and gives up fast if the answer isn't obvious - design is how you make sure the thing they came for is the thing they see. Start with the checklist below if you're here to fix something already live. ## The trap checklist (read this first if a dashboard isn't landing) | Symptom | Likely trap | Calm fix | |---|---|---| | "These numbers feel exaggerated" | Axis doesn't start at zero (bar chart) | Start bar-chart y-axes at zero; see below | | "This contradicts what I know" | Wrong aggregation (avg vs median, double-counted join) | Re-check the aggregation and the data grain | | "Is this good or bad? No idea." | No context - bare number, no comparison/target | Add comparison + target + trend (Phase 2) | | "Nobody opens it" | No owner, no decision behind it | Tie it to one decision + one named owner; see below | | "Too busy, I don't know where to look" | No hierarchy - everything same size | Put the main answer top-left, big; shrink the rest | | "The trend line looks insane" | Cherry-picked time range or mismatched scales | Use a consistent, non-cherry-picked time window | Most "bad dashboards" are good data arranged or scaled in a way that misleads - each row is unpacked below. ## Layout for the eye: most important answer first People read a dashboard the way they read a page - roughly top-left first, then across and down. That corner is the most valuable real estate you have, so the single most important answer goes there, big. The instinct is to treat every tile as equal - a tidy grid of same-sized charts. But "everything is important" reads to the eye as "nothing is important," and a wandering eye closes the tab. Here's a dashboard with a job - *"tell the head of growth, each morning, whether we're on track for the signup target"* - arranged so the headline answer lands first: ```text β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ SIGNUPS THIS MONTH vs TARGET β”‚ Cost per signup β”‚ β”‚ β”‚ $4.20 β”‚ β”‚ 8,200 / 10,000 β”‚ β–² 8% vs target β”‚ β”‚ β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‘β–‘β–‘ 82% β”‚ β”‚ β”‚ on pace: slightly behind β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ β”‚ Active this week β”‚ β”‚ (the one answer, top-left, β”‚ β–Ό 3% vs last wk β”‚ β”‚ biggest tile on the board) β”‚ β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ Signups / day β”‚ Signups by channel β”‚ β”‚ (trend line) β”‚ (bar chart, ranked) β”‚ β”‚ β•±β•² β•±β•²β•± β”‚ organic β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ β”‚ β”‚ β•± β•²β•±β•²β•± β”‚ paid β–ˆβ–ˆβ–ˆβ–ˆβ–ˆ β”‚ β”‚ β”‚ referral β–ˆβ–ˆ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ ``` *What just happened:* The decision-driving answer - *are we on pace?* - owns the biggest tile, top-left, with a target and a plain-English read ("slightly behind"). Supporting numbers sit smaller to the right; the *why* (daily trend, channel breakdown) lives below, for when the headline raises a question. Size *is* hierarchy, and the eye obeys it. πŸ’‘ **Key point.** A dashboard should answer its main question before the viewer consciously reads anything - good metrics in a layout nobody can scan still fail the job. ## The right chart for the question Each chart type answers a particular *shape* of question. Pick by the question, not by which chart looks coolest: | The question is... | Use | Why | |---|---|---| | How has this changed over time? | Line chart | The eye reads slope as change; that's its whole job | | How do a few categories compare? | Bar chart | Length is the easiest visual to compare accurately | | What's the single current value vs a target? | Big number + comparison | Fastest possible read for "are we good?" | | How are two numbers related? | Scatter plot | Shows correlation and outliers at a glance | ⚠️ **The pie chart trap.** For "parts of a whole," reach for a bar chart, not a pie. Pie charts ask the eye to compare angles and areas, which humans are bad at - with more than two or three slices, nobody can tell whether the 18% slice beats the 21% slice. A ranked bar chart answers "which is biggest?" instantly, because comparing lengths is easy and comparing wedges is not. **The gotcha.** Tools make it one click to switch any data into any chart, tempting you to choose by aesthetics. Resist - a line chart of unordered categories is meaningless (slope between "organic" and "paid" implies a change that doesn't exist). Match the chart to the question's shape first; make it pretty second. ## The trap that mistrusts your data: misleading axes A bar chart's whole message is *length* - a bar twice as tall means twice as much. The moment the y-axis doesn't start at zero, that promise breaks, and small differences look enormous. ```text y-axis starts at 0 (accurate) y-axis starts at 95 (misleading) 100 ─ 100 ─ β–ˆβ–ˆ β”‚ β–ˆβ–ˆ β–ˆβ–ˆ β–ˆβ–ˆ β”‚ β–ˆβ–ˆ β–ˆβ–ˆ β”‚ β–ˆβ–ˆ β–ˆβ–ˆ β–ˆβ–ˆ 98 ─ β–ˆβ–ˆ β–ˆβ–ˆ β–ˆβ–ˆ β”‚ β–ˆβ–ˆ β–ˆβ–ˆ β–ˆβ–ˆ β”‚ β–ˆβ–ˆ β–ˆβ–ˆ β–ˆβ–ˆ β”‚ β–ˆβ–ˆ β–ˆβ–ˆ β–ˆβ–ˆ 96 ─ β–ˆβ–ˆ β–ˆβ–ˆ β–ˆβ–ˆ 0 ┴─────────────── 95 ┴─────────────── A B C A B C "A, B, C are about the same" "C is WAY ahead of A!" (97, 98, 99) (same data: 97, 98, 99) ``` *What just happened:* Same three numbers - 97, 98, 99 - drawn two ways. Starting the axis at zero (left) tells the truth: they're nearly identical. Starting it at 95 (right) inflates a 2-point gap into what looks like a landslide. Nobody had to lie about the data; the axis did the lying. ⚠️ **Rule of thumb:** bar charts must start their value axis at zero - bars encode length. Line charts can start elsewhere (they encode slope, not length), but label a zoomed-in trend clearly so it isn't mistaken for a dramatic crash. ## The biggest trap of all: the dashboard nobody opens Every trap so far misleads a viewer. This one skips having a viewer at all - the most common failure by a wide margin. A dashboard with no owner is born dead: built because someone asked for "a dashboard," it drifts out of date because no one needs it to be right. Teams build them anyway because building feels productive - but a dashboard is a living thing: data changes, definitions shift, columns get renamed upstream, and without an owner to notice, it rots. A dashboard everyone half-trusts is worse than no dashboard, because people decide on stale numbers. **Two requirements before you build anything:** 1. **A real question** - one sentence naming the decision it serves (decision β†’ question β†’ metric, from Phase 1). Can't say it? Don't build yet. 2. **A real owner** - one named person who relies on it and will complain when it's wrong. That complaint is the immune system that keeps it alive. πŸͺ– **War story.** A company I saw had a wall-mounted TV cycling through eight "team dashboards." Six showed errors or numbers frozen for months - broken queries nobody noticed because nobody used them; pure dΓ©cor. The two that worked had a named owner who checked them daily and raised hell when something looked off. We turned off the broken six, and trust in the surviving two went *up* - the wall stopped showing things people had learned to ignore. Build fewer dashboards, each with a decision and an owner: one someone relies on every morning beats ten that look impressive and rot in silence. ## Recap 1. **Lay out for the eye.** The main answer goes top-left and biggest; size is hierarchy. 2. **Match the chart to the question's shape.** Line for change over time, bar for comparing categories, big number for "are we good?" Avoid pie charts beyond two or three slices. 3. **Don't let the axis lie.** Bar charts start at zero; label any line chart that doesn't. 4. **The deadliest trap is no owner.** Build only what serves a real decision for a real, named person. One last check, for any dashboard you've built: *if this number changed, what would someone do?* Cut every tile that can't answer it. > Where next. To go upstream - where these numbers come from and how to shape them - see [Warehouses vs Lakes](/guides/warehouses-vs-lakes) and [Querying Basics: SELECT and WHERE](/guides/querying-basics-select-where).