Build and test the project dashboard

Understand the method

Your dashboard should help the reader understand the analysis, not conceal it behind a decorative interface. Start with the decision and scope, then show completed value, count, AOV and delivery measurement coverage. Follow with monthly comparison and channel context, a concise explanation, an inspectable source table and definitions. Use the visual and reading-order principles developed in Module 5.

Build your own report

Use a local spreadsheet or dashboard tool and the verified source. The included dashboard_reference.html is an unchanged copy of Module 5’s worked example. It can help you compare behaviour after attempting the task, but it is not your independent implementation. State which parts you recreated and what you changed. If your chosen tool supports only static views, label them clearly instead of drawing nonfunctional controls.

Define initial and comparison states

Use May/All as the initial view: €3,420, 20 completed orders, AOV €171 and 95% measured-delivery coverage. Its prior baseline is April/All. For May/Web, compare against April/Web, not April/All; the selected value is €180 from two orders and the change is −90%. For May/Store, selected value is €3,240 from 18 orders, compared with €1,100 in April/Store.

April lacks a supplied March baseline, and the combined April–May view lacks a prior two-month window. Show these comparisons as unavailable with reasons. A known zero denominator is a separate unavailable-rate case. An empty selected population can have zero additive value and count, while AOV and coverage are unavailable. Do not leave an old success headline or chart visible after an empty filter.

Test the report as a reader

Check May/All, April/All, combined/All, May/Web, May/Store, an empty selection and reset. Compare cards, chart labels, table rows and filter-dependent text. Show delivery coverage as measured/eligible, not a percentage detached from its count. In the reference dashboard, May’s chart explicitly includes the selected month and supplied prior baseline; cards and table still represent the selected period.

Check readable labels and numerical alternatives, keyboard access to controls and a sensible narrow-screen reading order. Keep wide evidence tables in their own scrollable area. These are specific review steps, not a claim of complete accessibility certification. Record what you actually tested and any remaining limitation of the tool or export.

Keep freshness and source changes honest

The reference embeds a static fictional source and works offline. Changing a CSV beside it does not refresh the embedded data. Its edition is a material identifier, not evidence of a recent live ingestion. Your own report should similarly describe the source and refresh process that exist. For a changed-input test, use a disposable copy and confirm that affected values update or a validation failure is reported.

Include a dashboard view in the case study, but link it to the metric contract and test evidence. A screenshot can introduce the result; it cannot prove the filter logic or data lineage. The project is stronger when the reviewer can inspect both the presentation and the checks behind it.