Where this fits

A dashboard needs two kinds of rules. The style guide decides how the data is shown: chart choice, titles on live data, colour that survives filtering, data states. This page decides everything around it, and how to build it. When the two disagree about a chart, the style guide wins.

Building for a client? Use their brand for the interface and keep the style guide for the charts. The grid and the component list on this page still work; swap the colours and the typeface.

Canvas and grid

One canvas size, one grid. 1920 × 1080, sixteen columns of 102px, a 24px margin and a 16px gutter. Every visual starts on a column and spans whole columns. Type coordinates in; never drag.

Two kinds of page

Eight visuals per page is the maximum. More than eight means there is no main question.

Status colours

Five statuses, each with one colour, one sign and one word. A status is always a square marker with the sign inside and the word beside it, never a colour on its own.

• The sign is drawn in ink on the colour (white on Baltic and Cherry, black on Jasmine, Sky and Steel), so the light colours keep their contrast.
• Cell tints (--status-*-bg) are for table cells and badges. Use the tint or the marker, not both.
• The status colours are also data colours. A chart encodes status or categories, never both. On a page with status, draw category charts in colours that aren't status colours: Teal and its ramp, Coral, Violet or Blush, with Steel for context.
• Completed is Sky rather than a second blue: it stays distinct from On track for every common type of colour blindness (worst case ΔE 29).

Type

IBM Plex Sans on the web, Calibri in Power BI. Power BI only renders fonts installed on the viewer's machine, and Calibri has the lining, tabular figures the style guide asks for. No Newsreader on a dashboard: one typeface, hierarchy by size and weight.

Nothing smaller than 14px, or 10.5pt, including the source line. On the web, metadata (period, refresh time, source, filter heading) is Plex Mono, as everywhere else in the system.

Page header

Says where you are: the dashboard title, the pages, and the period and refresh time. It sits on the canvas, above a hairline. No coloured band.

Filter rail

All filters in one place, on the left of an overview page. At most three filters, Apply and Clear, and the note that says what changed.

One or two filters and no note? Put them in the header instead, as dropdowns beside the period line.

KPI tile

The BigNumber card on a canvas: label, value and one line of context. Four in a row, all from the same variant, so their baselines line up.

Every value carries a comparison: a target, the previous period, the baseline or the rest of the portfolio. Coral stays the interface accent; it is never a status.

Status marker

A square with the sign, then the word. Inline in text and tiles, or as a cell with the tint behind it.

<span class="status status--watch">Watch</span>
<span class="status status--cell status--off-track">Off track</span>

Subject bar

On every detail page, never on an overview: which item this page is about, its status, where it sits in the list, and the picker for another one.

Note

"What changed", an explanation, or a warning. The Callout pattern: a rule above and a mono key with a coloured square. No left border, no box.

Notes that depend on the data come from the data: a table of notes by item and period, picked by the same filters as the page. A typed note is true until the next refresh.

Empty and error states

Three kinds of empty, three messages. The tile keeps its title; the message replaces the chart. Never the tool's default message.

A refresh warning goes in one place: one tile, or one line under the header. The same message twice on a screen reads as two problems.

Table

Ruled, not filled. A bold header over a dark rule, hairlines between rows, a 2px rule over the total. A table is a full visualisation: use one whenever readers need to check, copy or forward the numbers.

• Numbers right-aligned, tabular figures; text left-aligned.
• Sort by value, not alphabet, unless the rows have their own order: periods, levels, statuses.
• Fixed column widths. Automatic widths jump on every filter change.
• A missing value is a dash, not a zero.

Footer

One line at y 1032: source, the date the data refers to, and when it was refreshed. Always there, always from the data, so a screenshot pasted into a memo still says what it shows.

Example page

An overview page built only from the parts above: rail, KPI row, main and support bands, table, footer.

<link rel="stylesheet" href="styles.css">
<link rel="stylesheet" href="dashboards/dashboard.css">

<div class="dash">
  <header class="dash-head">…</header>
  <div class="dash-grid">
    <aside class="tile rail span-4 rows-all">…</aside>
    <section class="tile kpi span-3">…</section>
    <section class="tile span-7">…</section>
  </div>
  <footer class="dash-foot">…</footer>
</div>

Power BI theme

ren-data.theme.json sets the data colours in order, Calibri at every text size, white tiles with a 1px hairline and no shadow, 3px corners, 16px padding, ruled tables, coral buttons, underline page tabs and the canvas colour. Apply it first, before any visual exists: a theme doesn't override formatting a visual already has.

Building the parts

Where Power BI differs

Decided once, for every report. Don't work around these per file.

Before you publish

• Every visual starts on a column and every row ends at 1896.
• Four KPI tiles of one variant, each with a comparison.
• Every status has a colour, a sign and a word.
• Header period line, footer and notes come from the data. Nothing typed that will go out of date.
• Test the opening view, the deepest single selection, a selection with no results, the first and the latest (partial) period, a reader without access, and a screenshot without context.
• Alt text on every visual. Fixed column widths on every table.
• No colour typed in by hand that belongs in the theme. If you need one, the theme is missing a case.