Frontend Quality Framework by Crayons & Code

Common Failure Points

Frontend quality usually breaks where ownership, evidence, or re-validation is unclear.

These failure points are not signs that a team does not care. They are signs that the delivery system is asking people to make decisions without enough shared context.

Use this page to recognise common patterns before running a full review.

QA Sees Work Too Late

QA often becomes the first role to discover that acceptance criteria are unclear, states are missing, or the implementation does not match the real journey.

That makes final testing feel like discovery rather than validation.

Look for:

  • QA joining only when build is nearly finished
  • test cases being written from incomplete tickets
  • bugs that are really unanswered product, design, or content questions
  • repeated defects around states, edge cases, devices, or journeys

Try:

  • involving QA before build starts
  • making acceptance criteria testable
  • asking QA to review risk and scenario coverage during definition
  • recording what is deliberately out of scope

Designs Show Ideal States Only

Designs often show the happy path clearly but leave production behaviour unclear.

This creates avoidable rework when development or QA asks what should happen with loading, empty, error, long-content, keyboard, focus, permission, or responsive states.

Look for:

  • missing loading, empty, error, disabled, and success states
  • unclear responsive behaviour
  • components that only work with short content
  • focus states, keyboard behaviour, or accessible names left to interpretation
  • unclear behaviour for signed-out, restricted, or partially completed journeys

Try:

  • treating key states as part of the design, not an implementation detail
  • documenting behaviour that cannot be shown visually
  • agreeing which states are required before build
  • using a spike when behaviour is too uncertain to estimate responsibly

Design Files Become The Default Source Of Truth For Words

Design files are excellent for layout, hierarchy, interaction, and design intent. They are not automatically the safest source of truth for every word that appears in production.

This matters most for legal, financial, privacy, consent, authentication, validation, pricing, error, and code-owned content.

Look for:

  • placeholder text moving into production
  • designers being asked to approve regulated or operational wording
  • content changing in design without content, legal, finance, or product ownership
  • validation and error messages differing between design and the real system
  • teams arguing about whether Figma, the ticket, CMS, code, or legal copy is the source

Try:

  • naming the content owner and approval route
  • separating design intent from approved production wording
  • recording where dynamic, code-owned, or CMS-owned content comes from
  • re-validating layout and meaning when content changes

Development Starts Before The Work Is Ready

Starting early can be useful when the team is intentionally exploring. It becomes risky when uncertainty is hidden inside a normal delivery ticket.

Look for:

  • tickets entering build with open product questions
  • unclear scope or acceptance criteria
  • unresolved content, data, API, dependency, or permission questions
  • estimates that assume missing design or technical decisions will appear later
  • developers making product or content decisions because nobody else owns them

Try:

  • using a Definition of Ready gate
  • splitting discovery or technical uncertainty into a spike
  • recording blockers instead of treating them as assumptions
  • making the source of truth clear before implementation starts

Accessibility And Performance Arrive Too Late

Accessibility and performance become expensive when they appear only as final checks.

Late review often finds structural issues that would have been easier to shape during product, design, or build.

Look for:

  • accessibility considered only after QA
  • performance checked only with a single final score
  • interaction patterns chosen before keyboard and focus behaviour are understood
  • third-party scripts added without loading or consent impact review
  • fixes that improve one page while breaking a shared pattern somewhere else

Try:

  • making accessibility and performance baseline requirements
  • reviewing interaction patterns before build
  • checking critical journeys, not only isolated components
  • re-validating after CSS, component, dependency, analytics, and third-party changes

Shared Components Change Without Consumer Review

A component can be improved in one place and still break another page, journey, or state.

This usually happens when teams review the component in isolation but do not decide which consumers need checking.

Look for:

  • component changes released without a consumer list
  • visual updates that break long content or responsive layouts
  • accessibility fixes that change labels, semantics, or keyboard behaviour downstream
  • token, spacing, or CSS changes treated as low risk by default
  • teams relying on broad regression because nobody knows what is affected

Try:

  • naming affected pages, journeys, and consumers
  • agreeing proportionate re-validation scope
  • checking representative real content
  • recording which consumers were checked and which were deliberately skipped

Exceptions Are Agreed In Conversation And Lost

Some exceptions are sensible. The problem is not the exception; it is the missing record.

When exceptions disappear into chat, nobody knows who accepted the risk, when it should be revisited, or whether it still applies.

Look for:

  • "we agreed this was fine" without a ticket note
  • accepted risks without owner, impact, or follow-up
  • temporary workarounds that become permanent
  • release decisions that cannot be explained later
  • repeated debates about decisions that were supposedly settled

Try:

  • recording the exception, owner, reason, impact, and review trigger
  • distinguishing "accepted for this release" from "approved as the new standard"
  • linking exceptions to re-validation or follow-up work
  • making temporary decisions visible during release review

Release Means Done Forever

Frontend work keeps changing after release.

Content changes, analytics changes, component updates, CSS refactors, dependency upgrades, and third-party scripts can all undo previous quality.

Look for:

  • no owner for post-release monitoring
  • no review trigger after later change
  • content updates made without layout or meaning checks
  • shared updates shipped without journey validation
  • bugs appearing long after the original feature was signed off

Try:

  • treating release as one stage in the quality cycle
  • recording what should be monitored
  • deciding which future changes need re-validation
  • making follow-up ownership explicit

Regression Is Either Too Broad Or Too Shallow

Many teams swing between full regression for small changes and almost no regression for risky changes.

Both are symptoms of unclear scope.

Look for:

  • full regression because nobody wants to decide what matters
  • small checks on payment, authentication, consent, or shared components
  • release delays caused by avoidable uncertainty
  • QA carrying the risk decision alone
  • repeated arguments about what needs checking

Try:

  • basing regression scope on impact, reversibility, and affected journeys
  • naming risk owners before validation starts
  • recording checks that were completed, skipped, and deferred
  • reusing scope decisions when similar work appears later

Ownership Is Shared But Not Accountable

Cross-functional work needs shared contribution. It also needs clear accountability.

When everyone owns a decision, nobody may be able to approve, block, or follow it up.

Look for:

  • unclear sign-off between Product, Design, Content, Development, and QA
  • "the team" owning risks without a named person or role
  • decisions waiting because nobody knows who can say yes
  • QA or Development absorbing decisions that belong elsewhere
  • follow-up actions with no accountable owner

Try:

  • naming contributors, reviewers, decision makers, and follow-up owners
  • making role ownership visible in the ticket or review record
  • separating advice from approval
  • giving blockers a named owner and next action

Using This Page

Pick one recent piece of frontend work and ask:

  • Which failure point appeared?
  • Who found it?
  • When was it found?
  • What evidence was missing?
  • Which role needed to be involved earlier?
  • What should be recorded next time?
  • Which later change could recreate the same problem?

Start with the pattern that causes the most rework. Fixing one repeated failure point is usually more valuable than trying to redesign the whole delivery process at once.