Build the dashboard

Stephen Few's definition is strict for a reason: a dashboard is what fits on a single screen, monitored at a glance. The moment an exec scrolls, they stop scanning and start hunting - and most never scroll at all, so whatever lives below the fold effectively does not exist.

• Exec views: one screen, always. If it does not fit, you have not prioritized. Cut panels, do not shrink them.
• Analyst views may go deeper - via navigation, not scrolling. Detail belongs on drillthrough pages and linked report pages, one honest screen at a time.
• White space is a feature. Squeezing in one more chart costs every existing chart a share of attention. Few calls the overcrowded alternative a data junkyard, and he is right.

Every serious BI tool lets you define a theme: fonts, the color palette, background, spacing defaults - set once, applied everywhere. Power BI uses a JSON theme file; Tableau uses workbook-level formatting plus custom color palettes and shapes. It is the same idea as this site's single CSS file: define the look in one place so every page agrees, and a rebrand is a one-file change.

• Consistency is comprehension: when revenue is always the same color and fonts never jump, the reader spends zero effort re-learning each page.
• Themes are governance for design: publish a company theme file so forty report authors produce one visual language instead of forty.
• Remove before you add: most default themes ship with gridlines, borders, and shadows you should strip. Few's rule from b5 still applies at page level - maximize data ink.

Every interactive element costs twice: cognitive cost (the reader must discover it, learn it, and trust it) and performance cost (every cross-filter click fires queries against every affected visual). Default to fewer.

• Cross-filtering ON is the default in most tools - question it. Clicking a city bar and watching the KPI row change can mislead: the exec thinks total revenue collapsed when they merely filtered it. Turn cross-filtering off wherever a partial number could be mistaken for the whole.
• Cross-highlight is the gentler cousin: it dims the non-selected portion instead of removing it, keeping the total visible for context. Often the better default for exec views.
• Drillthrough beats crowding: the detail an analyst wants does not belong on the exec page - it belongs one right-click away, with the filter context carried along.
• The cut test: list every interaction on the page, then cut half. If nobody misses one in a week, it was cost with no benefit.

Five checks, run on every dashboard before it ships. None takes more than minutes; together they cover most of what PL-300 means by accessible reports.

An ops manager does not open with revenue - they open with flow: how are orders arriving, and are any stuck? Build their headline panels: orders by channel, then switch the dimension to status and look for anything piling up. What would their KPI row be?

Take the exec view from Demo 1 and design its phone layout on paper: one column, thumb-friendly. You get roughly three panels before the reader stops scrolling. Which three survive, in what order - and write down what you removed. (Standard answer: KPIs first, trend second, one breakdown if any. Yours may differ; your reasons matter more.)

An analyst right-clicks the March point on the exec trend. Sketch the detail page they land on: what filters carry over (month = March), what panels it shows (revenue by city for March only? orders by status? new vs returning customers?), and what it deliberately leaves out. This sketch is your head start on b9, where March gets a full investigation.