Engineering Quality Model
Why this chapter matters
Frontend teams often call code "good" when it is readable. Architects need a broader quality model: the system must be usable, measurable, secure, accessible, evolvable, and operable under real-world constraints.
The quality stack
The stack is ordered deliberately. Clean internals do not compensate for a broken user outcome.
Quality dimensions
| Dimension | Architect question | Evidence |
|---|---|---|
| correctness | Does the workflow produce the right result? | tests, acceptance criteria, production validation |
| accessibility | Can users complete the workflow with different input and assistive models? | keyboard pass, screen reader checks, WCAG evidence |
| performance | Does the route feel fast on target devices and networks? | budgets, traces, RUM |
| reliability | What happens when dependencies fail? | failure matrix, retry/degrade behavior, incidents |
| security/privacy | Are trust boundaries and data handling explicit? | threat model, CSP, storage policy, audit trail |
| maintainability | Can teams change this safely? | boundaries, ownership, test pyramid, dependency rules |
| operability | Can production explain itself? | dashboards, logs, traces, alerts, runbooks |
Quality budget model
For critical surfaces, define budgets before implementation:
| Budget | Example |
|---|---|
| interaction | primary action responds within target INP threshold |
| route bytes | initial JS stays under route-specific limit |
| errors | critical flow error rate stays below agreed threshold |
| accessibility | no keyboard trap or unlabeled control on critical journey |
| security | no new third-party script without owner, purpose, and data class |
| maintenance | no cross-domain import without ADR or ownership approval |
Quality review flow
Common quality traps
- Treating test count as quality.
- Treating performance as a launch-week optimization.
- Treating accessibility as a QA-only responsibility.
- Treating security as backend-only.
- Treating observability as logs after failure.
- Treating maintainability as folder structure.
Review checklist
- Are quality dimensions explicit for the surface?
- Are budgets tied to user journeys rather than generic targets only?
- Does risk classification change the strength of gates?
- Can production signals prove the quality model after launch?
- Are exceptions time-bound with owners?
Exercises
- Create a quality model for checkout, onboarding, billing, or dashboard search.
- Define three quality budgets for a route your team owns.
- Find one place where your current quality gates are too weak for the user risk.
Source lens
This chapter connects Part 0 production readiness with Part VI performance, Part VIII reliability/security/accessibility, and Part XII scorecards.