# Interface Finding Priority Matrix

Use this matrix to rank observed defects. Severity follows user impact and
evidence, not the visual prominence of a finding.

| Area | Block release when | High-priority examples | Lower-priority examples |
|---|---|---|---|
| Accessibility | A required task is unavailable to keyboard, screen-reader, zoom, contrast, or motion-sensitive users | Missing accessible name; focus lost; status not announced | Inconsistent focus styling that remains visible |
| Task completion | The primary flow cannot complete or corrupts user intent | Secondary flow dead end; ambiguous destructive action | Extra step with a clear escape |
| Safety and trust | Privacy, security, consent, money, or irreversible data is at risk | Misleading confirmation; hidden material consequence | Reassurance copy that could be clearer |
| Input and feedback | Input is accepted incorrectly or outcome is unknowable | Error detached from field; no async progress | Feedback timing or placement polish |
| Navigation | Users become trapped, routed incorrectly, or lose work | Back behavior violates expectation; current location unclear | Minor label consistency issue |
| Responsive layout | Content or controls are inaccessible at a supported viewport | Overlap, clipping, horizontal overflow | Nonessential spacing imbalance |
| Content | Essential meaning is absent, wrong, or dependent on color/imagery alone | Unclear action label; missing units; stale claim | Voice or brevity improvement |
| Performance | Loading or interaction misses an agreed budget and blocks work | Layout instability; unbounded media; main-thread stall | Optimization without measured impact |
| Visual hierarchy | Users cannot identify order, grouping, or primary action | Competing primaries; relationships implied incorrectly | Rhythm or alignment refinement |
| Consistency | Divergence causes different behavior or meaning for the same pattern | Same control produces different outcomes | Cosmetic token drift |

## Severity levels

- **P0 — block release:** a reproducible critical barrier, legal/safety exposure,
  data-loss risk, or broken primary task.
- **P1 — fix before the next release candidate:** significant failure with no
  reasonable workaround, or a high-impact defect in a secondary task.
- **P2 — schedule:** real friction with a workable path and bounded impact.
- **P3 — consider:** measurable polish or maintainability improvement with low
  user impact.

## Assignment procedure

1. Record the evidence: state, viewport, input method, expected result, and
   observed result.
2. Identify affected users and whether a safe workaround exists.
3. Choose the highest applicable area in the matrix.
4. Raise severity for broad reach, repeated exposure, irreversible outcomes,
   or regulatory requirements.
5. Lower severity only when a tested workaround is discoverable and safe.
6. Link each P0 or P1 to an owner, verification step, and release decision.

Do not combine unrelated defects to manufacture severity. Conversely, do not
split one systemic defect into small findings to hide its cumulative impact.