Deliver a dashboard and a concise stakeholder walkthrough

Understand the method

The final task brings together analytical definitions, layout, interaction and communication. Build one useful dashboard for the operations lead rather than adding every possible metric. Your report should help the reader understand the selected completed-order population, inspect the channel composition and decide what evidence to gather before recommending expansion. Use the same verified data throughout so the result can be reconciled.

Complete the working report

Start from your wireframe or the downloadable learner scaffold. Use a local spreadsheet or dashboard tool; the HTML worked example is one possible implementation, not a required coding exercise. Create the four headline measures, the two diagnostic views, an explanation, an inspectable data table and definitions. If your chosen tool cannot support live filters, make clearly labelled separate views and explain that limitation instead of drawing controls that do nothing.

Preserve the May/All default and a clear way to return to it. Test April, combined months, Web, Store and an empty selection. Show unavailable comparison reasons and denominator behaviour. Keep the current filter visible near the title and in any exported view. If you share a screenshot or printout, it should retain scope, units, counts and the relevant caveat; a detached large number is not a complete report.

Give a short walkthrough

Prepare a two-minute explanation. Begin with the question and population, then describe the May completed-value change. Show why channel composition and the small April store group qualify the aggregate increase. Mention delivery coverage and the absence of costs or causal evidence. Finish with a next investigation. Avoid spending the full presentation reading every card or explaining software menus that do not affect the decision.

A useful demonstration includes one filter change. Select Web and explain how the value comparison changes to −90% against April/Web. Return to the default and show where the definitions and source table can be inspected. This demonstrates that you understand the analytical contract behind the controls. Do not claim the prototype proves a commercial effect simply because the interface works.

Package the evidence

Keep the editable report, unchanged source CSV, metric dictionary, a short decision note and a test record. Include any calculation worksheet or code needed to reproduce your result. Identify the case as fictional and guided practice, especially if adding it to a portfolio. A polished screenshot can introduce the work, but the evidence pack shows how the result was produced and checked.

Use the rubric to improve the work

Review five categories: metric definitions and reconciliation; layout and visual comparison; interaction and edge states; explanation and limitations; reproducibility and usability review. Score each from zero to two. Two means the requirement is complete and correct, one means present but incomplete, and zero means absent or materially wrong. Aim for eight or more with no zero in metric correctness or interaction states. This is a self-review aid, not an accredited assessment.

Open the worked dashboard only after attempting your own version, compare behaviours and explain differences. There can be several good layouts. A different colour balance or chart arrangement is acceptable if the report remains readable and analytically correct. Unsupported metrics, hidden exclusions and inconsistent filter scopes are substantive problems to fix before presentation.