Acceptance Criteria and Revision Requests

Why this matters

The most expensive sentence beginners write is "looks good, just make it pop." The tool then regenerates everything: colors, layout, text, and quietly the form behavior that used to work. Three rounds later the page is prettier and broken, and nobody can name the round that broke it. Measurable criteria prevent this twice: before building, they define done so precisely that disputes vanish; during revision, they fence the change so working parts survive. Professionals call this acceptance criteria, and it is the cheapest quality tool in existence: a few sentences that turn opinions into tests.

Concepts

An acceptance criterion is a sentence you can check with yes or no in under a minute. "Looks professional" fails; "all text readable at phone width without horizontal scrolling" passes. Write criteria in three groups:

• Visual. What it looks like, measurably: "headings larger than body

text", "photos never wider than the screen", "button reachable without scrolling on a phone".

• Functional. What it does, step by step: "entering name, items and time

shows a confirmation with the same three values", "reloading keeps the saved orders", "empty form shows which field is missing".

• Preserved. What must not change in this revision, named explicitly:

"keep the three sections, the wording and the colors; change only the hours text." The preserved list is the fence. Most revision damage happens to things nobody named, because unnamed things are unprotected.

A revision request then has a fixed shape: keep (what stays) + change (one thing, with its criterion) + check (how you will verify). Example: "Keep the layout, colors and all text. Change only the hours section to: open 08:00-19:00, closed Mondays. I will check by narrowing the browser to phone width and reading the section." One change per request. Two changes means two requests, because two simultaneous changes that break cannot be told apart.

Visual and functional checks differ. Visual checks use eyes at two sizes (phone width and desktop). Functional checks use hands (fill, submit, reload, break it on purpose with empty input). Never accept "it opens" as a functional test; opening proves rendering, not behavior. Lesson M07L27 will extend this into a full test routine; for now, the habit is: every change gets one look-check and one hands-check.

Worked example

Vague revision: "The form looks boring, improve it." Likely outcome: new colors, new layout, labels replaced by placeholder text that vanishes when typing (an accessibility failure), and the confirmation now shows the wrong time format. Four regressions for one vague wish.

Criteria-first revision: keep-list ("keep all fields, labels, order and colors"), change ("make the submit button full-width on phones; criterion: button spans the form width at 360px and stays clickable"), check ("I will narrow to 360px and tap it"). The tool changes one rule, you verify in thirty seconds, everything else stands untouched.

Expected result: three revision wishes from your own project rewritten as keep plus change plus check, each verifiable in under a minute.

The common wrong move

Batching: sending five changes in one message to "save time". It spends time: when the result breaks, each change is a suspect and the messages to untangle them outnumber the messages saved. One request, one change, one check. Speed comes from fewer repairs, not fewer messages.

Lab and next step

Lab A06 writes three change requests with acceptance criteria, separating visual checks from functional ones. Next, module M03 opens the hood: what websites, browsers and files actually are, so your briefs and criteria rest on real understanding instead of borrowed words.