You are the client, not the builder
Leaders rarely build dashboards, but leaders commission almost all of them - and a vague commission produces a pretty, unused artifact every single time. "Give me a dashboard of everything" is how it starts; a wall of charts nobody opens is how it ends. Today you learn the client-side craft: specify sharply, accept rigorously, and launch into a habit. Last session (a3) made your numbers trustworthy; this one makes them looked at.
The brief before the build 13 min live
Stephen Few's rule and Microsoft's newest Power BI design guidance say the same thing from different decades: know the audience, the question, and the action before anything gets built. Microsoft's redesigned "Design effective reports" learning path literally opens with a module called "Scope report design requirements" - requirements first, visuals later. Your version of that discipline is one page with five fields. If a request cannot fill them, it is not ready to build.
LiveAudience changes everything6 min▶
Few's chapter 4 lists the fundamental considerations that should shape any dashboard before design starts: frequency of use, the users themselves, screen size, and the type of data. Change the audience and every one of those answers flips - which is why the same "revenue dashboard" request means two entirely different products:
- The exec glance: read weekly for 30 seconds, on a laptop or a boardroom TV, standing up. Wants 5 numbers with targets and deltas, zero interactivity, everything on one screen. Success = the anomaly is visible from two meters away.
- The analyst drill: open half the day, on two monitors, sitting down. Wants filters, drill-downs, exportable detail, and tolerance for density. Success = any follow-up question is answerable without writing SQL.
Build the drill for the exec and they stop opening it. Build the glance for the analyst and they rebuild it in a spreadsheet. Field 1 of the brief exists so the builder knows which product they are making.
Self-studyThe question behind the request4 min read▶
"I want a dashboard of everything" is the most common commission and the most reliable failure. Nobody reads everything; people read answers. Your job as the commissioning leader is to excavate the Monday-morning question - the specific thing the reader will ask the screen at 9am.
- Ask "what will you do differently?" If no decision changes based on the number, the number is decoration. Field 3 of the brief is the filter that kills vanity metrics before they are built.
- Ask "what did you check last Monday?" People's actual recurring question is usually much narrower than their stated wish. "Everything about sales" collapses into "did any region miss plan?" under one minute of questioning.
- Ask "what would make you stop reading?" Few's chapter 3 frames requirements-gathering as learning what the dashboard must do for the user, not cataloguing available data. Data-driven scoping produces walls; question-driven scoping produces answers.
A useful test: the brief's question should fit in one sentence and contain no "and". "Revenue and churn and pipeline and NPS" is four questions - and probably two dashboards.
The thirteen mistakes as an acceptance checklist 13 min live
Chapter 2 of Few's Information Dashboard Design catalogues thirteen common mistakes dashboard designers make; chapter 13 applies them in brutal real-world critiques. You are not the designer - so flip the list. Every designer mistake becomes a commissioner's check: five questions you can ask of any delivered dashboard, in five minutes, with no design training at all.
LiveFive checks in five minutes6 min▶
Run these on any delivered dashboard, in order, before you say "approved". Each one is a Few mistake inverted:
- 1 · One screen? Few's first mistake is exceeding the boundaries of a single screen. If the Monday answer requires scrolling or tab-hopping, part of it will simply never be seen.
- 2 · Context next to every number? A lone "$1.9M" is trivia. Against target? Versus last month? Numbers without comparison points force the reader to supply memory - most will not.
- 3 · Right precision? Excessive decimals are false accuracy and real clutter. Exec dashboards round; the detail lives a click deeper.
- 4 · Any decoration? Gauges, 3D, backgrounds, logos beyond one corner - Few calls this useless decoration, and every pixel of it competes with the data.
- 5 · Does color mean something? If four bars are four colors for variety, color has been spent on nothing. Color should mark the exception, the target breach, the thing to look at.
The five-minute sendback. A COO we know runs exactly this list on every new dashboard, out loud, with the builder in the room. First pass usually fails on checks 2 and 3. Second pass usually ships. The builders learned the list within a quarter - and started passing on the first try. Acceptance checks train your whole BI supply chain.
Self-studyContext is the cheapest upgrade3 min read▶
If you only enforce one check, enforce check 2. The gap between a number and a decision is context, and context is almost free to add:
- Number alone: "Revenue: $1.9M". The reader must remember the plan, last month, and last year to know if this is good news. Most readers shrug and move on.
- Number + target + delta: "Revenue: $1.9M · plan $2.0M · -5%". Now the dashboard has done the judging. The reader's next thought is "why?", which is exactly the conversation a dashboard exists to start.
This costs the builder one measure and a few characters of layout. It converts a reporting artifact into a decision instrument - the highest return-on-effort edit in all of BI. When you send a dashboard back, "add the target and the delta" should usually be line one.
Rollout and the habit loop 6 min live
Few's final chapter is about moving from imagining to unveiling - and validating that the thing actually works after it ships. Here is the leader's translation: a dashboard succeeds when it enters a ritual. Not when it launches, not when people say it is nice - when the Monday standup opens with it on the screen, or the month-end review walks through it page by page. A proper launch has three moves: train the readers (fifteen minutes, live, on real numbers), pin it into the ritual where its question gets asked, and retire the old report - as long as the legacy spreadsheet survives, the dashboard is optional, and optional dashboards die.
LiveMeasure the dashboard itself4 min▶
Every BI platform counts views - so commission the meta-metric along with the dashboard. Few's chapter 14 insists on validating effectiveness after rollout; this is the lightweight version:
- Watch usage weekly for the first month. Opens per intended reader, not total opens. Ten views that are all the builder refreshing their own work is a failed launch with good-looking numbers.
- Run the 2-week silence test. If a dashboard goes unopened for two weeks, it does not get a redesign - it gets a conversation: what question did we get wrong? Sometimes the answer is "the ritual moved"; often it is "the question was never real".
- Retire without guilt. A dashboard that failed the silence test twice gets archived. Dead dashboards are not harmless: they clutter the portal, dilute trust, and hide the certified content from a3 behind noise.
Write the Daybreak exec brief together ★ 12 min · follow along
Daybreak's founder wants "a monthly dashboard for the leadership meeting". Vague - perfect. We will run it through the five fields live, then check a real chart against the brief we just wrote.
Field 1 - who reads it: the founder plus two leads, in the monthly business review, projected on a meeting-room screen. One audience, one sitting. Already we know: glance product, not drill product.
Field 2 - the question: "everything about the business" collapses under questioning into: is monthly revenue on plan, and if not, where is the miss? One sentence, no "and" joining unrelated topics. That is buildable.
Fields 3 to 5 - decision, cadence, screen: decision = where to focus retention and marketing effort this month; cadence = monthly, five minutes at the top of the review; screen = one projected display, readable from the back of the room. Big text, one screen, no interaction needed mid-meeting.
Now check a candidate chart against the brief. The box below shows monthly revenue as a line - the natural centerpiece for field 2. Does it answer "on plan?" on its own? No: there is no plan line, no target, no delta. Against the brief, this chart is necessary but not sufficient - it locates the dip (look at March) but cannot say whether we are missing plan. That gap is exactly what you would write in the acceptance notes.
Your turn: acceptance-check a chart ★ 8 min · you judge
A builder just delivered the chart below for the same Daybreak review: orders by city. Run the five checks from Part 2 on it, out loud, and decide what you would send back. There is no single right answer - but there are checks it visibly fails.
Run checks 1 to 5. One screen: yes, it is a single chart. Context: is there a target or a prior period next to these bars? Precision: are the numbers rounded sanely? Decoration: anything not carrying data? Color: does the highlight mean something, or is it just pretty?
Interrogate it against a brief. Which Monday-morning question does orders-by-city answer for a monthly exec review? If the review's question is "is revenue on plan?", is city even the right dimension - or is this chart an analyst's curiosity promoted to an exec screen?
Write the sendback. One or two lines, requirement-shaped: "add prior month for context", "swap dimension to plan tier - city is not decision-relevant for this audience", or even "cut it - no decision changes on this chart". Cutting is a legitimate acceptance outcome.
Leaders who check get better dashboards. Builders calibrate to whatever their commissioners actually inspect. If launches only get "looks great!", the left column of the Part 2 board is what you will keep receiving. Five spoken minutes of reads-right checks, twice, permanently raises the quality of everything your team ships you.
Try it yourself - this week ◐ 20-30 min total
- Write a real five-field brief for one dashboard you genuinely want. If a field will not fill, the request is not ready - which is the brief doing its job.
- Acceptance-check one dashboard you already receive: run the five checks and note what fails. Most inherited dashboards fail on context and one-screen.
- For every dashboard you regularly receive, name the ritual it lives in - the standing meeting or review where it is actually opened. Any dashboard with no ritual goes on your 2-week silence watchlist.
- Bring to a5: the dashboard request you most fear from your teams - the "can everyone just build their own?" one. Session a5 is self-service without chaos.
Official sources covered
This session translates the canonical dashboard-design literature into the commissioning leader's view - the designer's craft stays with Few and the vendor labs. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · A VP asks you to sponsor "a dashboard of everything about sales". The first thing to pin down is...
Audience and question are fields 1 and 2 of the brief - they determine everything else, including the charts. Few's requirements chapters and Microsoft's "Scope report design requirements" module both start exactly here: know audience, question, action before building.
2 · A delivered exec dashboard shows "Revenue: $1,943,207.18" as a lone number. Your highest-value sendback is...
Context is the cheapest upgrade: number + target + delta lets the dashboard do the judging, and sane precision removes false accuracy. Gauges are on Few's decoration list, and repetition adds clutter, not meaning.
3 · When is a dashboard actually "done"?
Launch applause and metric-completeness are both "looks right" signals. Few's ch14 ties success to validated use after unveiling: train, pin into the ritual, retire the old report - then watch usage and apply the 2-week silence test.