Checklist

Dashboard Design Review Checklist

An actionable, role-aware pre-publish checklist that captures decisions, owners, and remediation notes. Converts the review into a saved record so teams can track fixes, assignments, and publish readiness.

Interactive Tool

Dashboard Design Review Checklist

Use this guided review before publishing a dashboard. For each section answer the quick Yes/No question, add concrete notes when issues are found, and assign an owner for follow-up. A 'Yes' indicates the check meets the acceptance criteria described below. Save the review to record the state and next steps.

Acceptance highlights: audience views align with roles and cadence; every card maps to a clear action and owner; data sources, definitions and calculations are verified; aggregation and latency match the decision rhythm; visuals are readable and annotated; alert thresholds and distribution are defined; a short QA runbook exists and was executed.

Does the dashboard match the intended audience(s), their decision rhythms, and data literacy? (Yes = meets acceptance criteria).
List roles, pages, cards, and recommended adjustments (filters, simplified views, alternate cadence).
Can a viewer identify the immediate action each card is intended to prompt?
For each card, state the action, the owner/role responsible, and the expected cadence (e.g., daily check, weekly review).
Sources, transformations, and calculations have been checked and documented; no known errors remain.
List sources checked, ETL jobs reviewed, sample rows validated, and any unresolved discrepancies with planned fixes.
Is the chosen aggregation level and refresh cadence suitable for the decisions the dashboard supports?
Explain any trade-offs (e.g., daily aggregates for hourly questions) and mitigation steps.
Charts are readable, use appropriate encodings, avoid misleading scales, and highlight key comparisons.
Note color/scale issues, overloaded cards, unnecessary 3D or pie charts, or insufficient contrast for colorblind users.
Tooltips, definitions, and short annotations exist for non-obvious metrics and calculations.
Which cards need annotations, definitions to include, or links to deeper analysis?
Are thresholds, responsible owners, and notification channels defined for metric exceptions?
List each alert, trigger condition, owner, and intended response.
Permissions, viewer roles, schedule (email/digest), and embedded locations are decided and tested.
Identify recipients, groups, delivery cadence, and any sensitive data restrictions.
A short runbook executed (visual smoke test, spot-check numbers, filter/permission checks, mobile/responsive check).
Record any issues found during QA and the owner and ETA for fixes.
Select the current state after this review.
Person performing this review.
Use ISO date or human readable date.
Any broader risks, stakeholder concerns, or follow-up items.
Provide concise action items so the team can assign and track fixes.
You can explore this tool now. Sign in or create an account to save your responses and return to them later.
Sign In to Save Create an Account
Make this tool part of your work

Save a personal copy, bring it to your team, or tailor the questions and workflow to fit what you are hungry to improve.

Member customization and team collaboration are coming soon.
Discuss Ask the Librarian

Discussion

Comments and conversation will live here.