The Quality Cycle

Frontend quality is not a final QA task. It is shaped by requirements, content, design, technical choices, implementation, testing, release decisions, monitoring, and later change.

The framework uses the repeatable cycle shown above.

The loop matters. A frontend change can be correct when it ships and still become wrong later because a component, content field, design token, dependency, analytics script, browser behaviour, or third-party integration changes.

1. Define

Make the work clear enough to design, build, test, and release.

Agree:

• user need
• scope
• acceptance criteria
• accessibility requirements
• performance expectations
• browser and device support
• content requirements, owners, and sources of truth
• technical constraints
• known risks

Good definition gives Design, Development, QA, Product, and Delivery enough shared context to make useful decisions.

2. Design

Define the intended user experience, including behaviour and states.

Useful design work includes:

• responsive behaviour
• hover states
• focus states
• keyboard behaviour
• loading states
• empty states
• error states
• validation states
• disabled states
• long and short content
• representative copy marked clearly when it is not final production copy
• motion and reduced motion expectations
• component variants

Design files can show content intent, hierarchy, tone, examples, and layout pressure. They should not automatically become the production source of truth for every word.

3. Review

Check the design and requirements before build effort is committed.

Review:

• technical feasibility
• accessibility risk
• performance risk
• component reuse
• design system alignment
• missing states
• unclear interactions
• testing requirements
• content source, approval status, and exceptions
• analytics requirements
• browser constraints

The point is not to slow work down. The point is to find expensive misunderstandings before they become expensive rework.

4. Build

Implement the agreed work with maintainable, accessible, performant frontend code.

Development should:

• use semantic HTML
• follow agreed component conventions
• preserve keyboard access
• implement agreed states
• test responsive behaviour
• minimise unnecessary JavaScript
• follow performance expectations
• add automated tests where useful
• document exceptions
• raise concerns early

Build work should not silently absorb unclear requirements, missing states, or risky design decisions. Those should move back into review.

5. Validate

Confirm that the work meets the agreed criteria and does not introduce avoidable regressions.

Validation is shared:

• Design checks visual fidelity, responsive behaviour, states, interaction intent, and whether production copy still supports the intended hierarchy.
• Development checks semantics, keyboard access, code structure, browser support, performance, error handling, and component behaviour.
• QA checks acceptance criteria, user journeys, edge cases, browsers, devices, regression risk, failure states, accessibility checks, analytics behaviour, and high-risk copy where relevant.

The result should be evidence, defects, accepted exceptions, and a release recommendation.

6. Release

Ship only when the team understands what is being released and what risk remains.

Confirm:

• acceptance criteria passed
• automated checks passed where they exist
• accessibility checks completed
• design review completed
• QA completed
• known issues recorded
• exceptions approved
• performance reviewed
• monitoring or rollback understood

Release readiness is not the same as pretending there is no risk. It means the remaining risk is visible and accepted by the right owner.

7. Monitor

Check whether the release behaves as expected in production.

Watch for:

• production errors
• support tickets
• analytics changes
• accessibility issues
• performance changes
• user behaviour
• visual breakages
• third-party impact
• browser issues

Monitoring should feed back into defects, improvement actions, and updates to standards where needed.

8. Re-validate After Change

Prevent later changes from undoing previous accessibility, performance, design, or functional quality.

Re-validation triggers include:

• component updates
• design system updates
• dependency upgrades
• CSS refactors
• content changes
• browser changes
• analytics changes
• third-party script changes
• responsive layout changes
• accessibility fixes

The scope should be proportionate.

Local component change

• Component tests
• Keyboard check
• Visual review
• Affected journey check

Shared component change

• All consuming pages
• Cross-browser check
• Accessibility review
• Performance review

Design system change

• Wider regression pass
• Visual baseline update
• Documentation update
• Training update

Not every change needs a full regression pass. Every meaningful change does need a deliberate re-validation scope.

Using The Cycle

Start small.

Take one recent piece of frontend work and ask:

• Was the user need clear before design and build?
• Were content sources of truth explicit?
• Were missing states found before implementation?
• Did QA help define risk before final testing?
• Were accessibility and performance checked at the right points?
• Were exceptions recorded?
• Did later changes have a re-validation scope?

The framework is useful when those answers become visible enough for the team to change how work moves next time.