Frontend Quality Scorecard
Purpose
A frontend quality scorecard gives teams a shared view of production health without turning architecture into vague opinion. It should be small enough to review monthly and specific enough to drive ownership.
Scorecard dimensions
| Dimension | Leading indicators | Lagging indicators |
|---|---|---|
| Performance | budget pass rate, JS route cost, third-party cost, trace review completion | Core Web Vitals failure rate, conversion drop, support complaints |
| Accessibility | component contract coverage, keyboard/focus review completion, automated issue trend | user-reported accessibility defects, compliance findings |
| Security/privacy | third-party register completeness, dependency age, CSP violation triage, sensitive event rejects | security incidents, privacy escalations, escaped findings |
| Reliability | error boundary coverage, degradation matrix coverage, rollback drill completion | route error rate, failed workflows, incident count |
| Data correctness | contract test coverage, stale-data monitoring, mutation idempotency coverage | data mismatch incidents, duplicate side effects |
| Delivery | build time, deploy frequency, rollback time, flaky test rate | release delays, escaped regressions |
| Platform adoption | supported framework versions, paved-road usage, exception count | migration stalls, duplicate architecture patterns |
Monthly template
| Area | Status | Trend | Owner | Next action |
|---|---|---|---|---|
| Critical route Web Vitals | ||||
| Accessibility contract coverage | ||||
| Third-party script register | ||||
| Security dependency SLA | ||||
| Route error budget | ||||
| Platform adoption | ||||
| Open architecture exceptions |
Status:
- green: meeting target
- yellow: risk visible, owner and plan exist
- red: user/business risk active or owner missing
- gray: signal missing or unreliable
Gray is not neutral. Missing signals are architecture debt.
Example scorecard row
| Area | Status | Trend | Owner | Next action |
|---|---|---|---|---|
| Third-party script register | yellow | improving | growth platform | add kill switch and consent category for two remaining scripts by June 30 |
Reasoning:
- not red because the scripts are known and owned
- not green because kill switches and consent categories are incomplete
- next action is specific and dated
Rules
- Track fewer metrics than you can explain.
- Every red or yellow row needs an owner.
- Every gray row needs an instrumentation decision.
- Do not compare teams without context.
- Use the scorecard to fund platform work, not to shame product teams.
- Retire metrics that no longer change decisions.
Executive summary format
Use this format for stakeholders:
This month, frontend quality risk is concentrated in:
1. mobile interaction latency on checkout
2. third-party script governance on acquisition pages
3. accessibility contract gaps in modal and combobox components
The business risk is checkout abandonment, privacy review exposure, and support/compliance cost.
The next investments are route-level INP work, script kill switches, and design-system remediation.
Exercise
Build a scorecard for three apps:
- marketing site
- SaaS dashboard
- account/billing portal
Choose five metrics only. Explain what you intentionally excluded and why.