7.2Dashboards That Drive Decisions
Anti-Pattern: One dashboard for all audiences. Developers, QA, product managers, and leadership all see the same view — so none of them find what they need, and the dashboard is ignored.
Pattern: Four dashboards for four audiences, each answering a different question.
| Dashboard | Audience | Core Question | Key Metrics |
|---|---|---|---|
| Developer | Individual developers | "What did I break?" | Failed tests per PR, flaky tests in my area, build time |
| QA | QA team | "Is testing effective?" | Flaky rate trend, coverage gaps, escaped defects, test suite health |
| Product | Product managers | "Is this release ready?" | Feature test status, regression results, open blockers, risk areas |
| Leadership | Engineering leadership | "Is quality improving?" | Escaped defect trend, incident rate, MTTR, deployment frequency |
A dashboard that nobody checks is a dashboard that does not exist. Design for the audience's actual workflow — embed results in PRs for developers, send weekly summaries for leadership, integrate with release checklists for product.
The Behavioral Coverage View
A mature program adds a fifth view that reports on users, not tests — and overlays it on coverage so the gap is impossible to ignore. Built from the production-behavior pipeline (sessionized flows, friction signals), it answers "Are we testing what users actually do?":
- Top 20 user flows, each flagged with whether regression tests exist
- Top abandonment flows and highest-friction pages (rage/dead/error clicks)
- Production incidents mapped to the tests that should have caught them
- Features with high code churn and low coverage
The signature insight: heavily used flows with thin coverage sitting next to rarely used features with comprehensive suites.