Semantic consistency requires human judgment

What it is

Semantic consistency asks whether the same cue still points at the same action. The judgment is three things held together: what someone expects on seeing the cue, what actually happens on activation, and what it costs to be wrong. A machine can see two buttons sharing a color; it cannot know both still promise “submit”, or that one now deletes. This layer is done by people.

It is not “does it look even”. Evenness is numeric. The semantic layer allows different looks (platform controls differ) and forbids different promises (both labelled “Done”, one saves, one discards).

Why it happens

People predict the next step from cues: a primary fill, a text button at the top right, a trash icon — each has accrued a contract in the product about what happens next. Consistency is whether this screen honors the contract. Testing the contract requires entering the prediction: ask someone who did not author the page “what will this do”, let them do it, then see whether a miss can be undone, loses data, or spends money.

Cost pulls the judgment out of taste. Two “Done”s, one of which discards a draft, is friction in a reversible draft and an incident at payment. Without cost, reviewers argue “I like this wording”; with cost, the argument lands on “who pays the bill for one miss”. That is why a human has to judge: expectation is a reading of the contract, cost is a pricing of harm, and neither side is a pixel.

Where it stops holding

Internal tools whose operators are examined and always read field labels replace the cue contract with programmatic reading; the semantic check can shrink to “does the label name the action”. A brand-new product has no accrued contract, and judgment decays into “does it resemble other products”; declare which external contract is being borrowed (the host platform, the industry’s software) instead of pretending an in-house convention exists. An experimental feature that deliberately breaks a cue to teach a new model is a designed inconsistency; the list should mark it “known break”, not a defect — and must still say what is being taught and whether one miss remains acceptable.

Applying it

• Write every semantic item in three columns: expected action, actual action, cost of a miss (undoable / recoverable through a process / irreversible).
• Ask someone who did not build the page to name the expected action from cues alone, then let them act; mismatch plus a cost that is not “undoable” becomes a finding.
• Sample two other occurrences of the same cue in the product; expectations should match. When they do not, write down whether this instance or the convention moves.
• How to check: sample five closed semantic items and read the closure for the three columns. “Looks fine” with no cost column reopens. Then point at a danger-colored button on a live page: if everyone says “submit” and it deletes irreversibly, the list missed this page.

Related

• Same group: R2.03.1 Checklists must cover states and edge cases · R2.03.2 Automation can only police the numeric layer · R2.03.4 Every checklist item must be answerable yes or no · R2.03.5 Order items by how cheap they are to find · R2.03.6 Grow the list from defect reviews, not from taste
• Adjacent: R1.03 Component state completeness · R1.18 Adoption and compliance metrics
• Search terms: semantic consistency · expected action · cost of error · affordance contract