Frontend Quality Framework by Crayons & Code

Re-validation Prompt Sheet

Use this prompt sheet when a frontend change could affect work that was already designed, built, checked, released, or signed off.

It is a lightweight starter resource. It helps a team ask better questions before choosing validation scope. It is not the full regression scope matrix or a replacement for team-specific quality gates.

The Short Version

Ask:

What changed?
Where is it used?
What could break?
Which checks are enough?
Who owns the decision?
What should trigger another review?

If the team cannot answer these questions confidently, the change probably needs broader review before release or close.

When To Use It

Use this prompt sheet after changes to:

  • components
  • design system rules
  • CSS
  • content
  • forms
  • dependencies
  • third-party scripts
  • analytics
  • APIs or data
  • accessibility behaviour
  • performance-sensitive journeys
  • feature flags or release bundles

You can also use it when a successful experiment is being turned into permanent product work.

1. Describe The Change

Start with the facts.

Ask:

  • what changed?
  • why did it change?
  • where is it used?
  • which components, pages, journeys, or users could be affected?
  • is it local, shared, or part of a critical journey?
  • is the change easy to verify?
  • is the change easy to reverse?

Do not start by asking whether the team needs full regression. Start by understanding what actually changed.

2. Check Risk Triggers

Go broader when the change affects, or might affect:

  • payment, checkout, account access, authentication, or personal data
  • legal, financial, privacy, consent, pricing, or regulated content
  • revenue-critical journeys
  • shared components or design system foundations
  • forms, validation, errors, or submission handling
  • third-party scripts, analytics, tracking, or consent behaviour
  • dependencies, build output, routing, data, or session behaviour
  • accessibility semantics, labels, headings, focus, keyboard access, motion, or contrast
  • performance-sensitive pages or critical journeys
  • hard-to-rollback releases

If the answer is "not sure", treat that uncertainty as part of the risk.

3. Choose A Proportionate Scope

Re-validation does not mean full regression for every change.

Use this as a starting point:

  • Low

    Typical situation: Isolated, easy to verify, easy to reverse, not shared, not behavioural, and not part of a critical journey.

    Useful checks: Check the changed area, run relevant automated checks, and record why wider validation is not needed.

  • Medium

    Typical situation: Affects normal UI behaviour, state, layout, content structure, forms, or a limited set of related journeys.

    Useful checks: Check the changed area, related areas, agreed browsers/devices/breakpoints, accessibility impact, performance impact, and relevant automated checks.

  • High

    Typical situation: Could cause serious user, business, legal, operational, accessibility, performance, privacy, or reputational impact.

    Useful checks: Check the changed area, critical affected journeys, related journeys, accessibility, performance, release constraints, rollback notes, and accepted risk.

The team can raise or lower the scope when it can explain why.

4. Accessibility Prompts

Ask:

  • could this affect keyboard access?
  • could this affect focus order or focus visibility?
  • could this affect names, labels, headings, errors, or instructions?
  • could this affect colour contrast, motion, zoom, or text resizing?
  • could this affect screen reader output or state announcements?

If the answer is yes or uncertain, include proportionate accessibility validation.

5. Performance Prompts

Ask:

  • could this affect page weight?
  • could this increase resource count?
  • could this increase DOM size or layout complexity?
  • could this add scripts, media, animation, data fetching, or third-party cost?
  • could this affect Core Web Vitals or a critical journey?

If the answer is yes or uncertain, include proportionate performance validation.

6. Name Ownership

Shared ownership needs a named decision owner.

Use these defaults:

  • Product owns business risk and affected journeys.
  • Development owns technical impact, dependencies, and implementation uncertainty.
  • QA owns validation scope and test evidence.
  • Design owns visual, hierarchy, and interaction impact.
  • Content owns wording, meaning, source, approval, and localisation impact where that role exists.
  • Release or Delivery owns sequencing, environment constraints, and coordination.

Adapt the roles to the team. The important thing is that somebody can approve, block, or follow up.

7. Record The Decision

Keep the record short and findable.

Change:

Where it is used:

Risk level:

Risk reason:

Checks completed:

Checks skipped:

Reason wider validation was or was not needed:

Decision owner:

Follow-up owner:

Next review trigger:

The record protects the team from two bad defaults: running too much regression because nobody wants to decide, or skipping related checks because nobody wrote the risk down.

Example Scopes

Content change

  • Source of truth
  • Approval status
  • Layout impact
  • Meaning and compliance risk
  • Affected journeys

Shared component change

  • Changed component
  • Common consuming pages
  • Key variants
  • Keyboard and focus behaviour
  • Responsive behaviour
  • Main affected journeys

Analytics or third-party script change

  • Consent behaviour
  • Loading impact
  • Interaction impact
  • Failure behaviour
  • Critical journeys
  • Error monitoring

What This Does Not Replace

This prompt sheet helps a team start the conversation.

It does not replace:

  • a client-specific regression scope matrix
  • detailed Definition of Done
  • formal accessibility audit
  • formal performance audit
  • privacy, legal, financial, or security review
  • release approval for high-risk work

Use Re-validation After Change for the public explanation of the habit. Use Work With Crayons & Code when a team needs help adapting this into its real delivery process.