Walkthroughs compare the build to design intent

What it is

A design walkthrough compares the build to design intent (intent-referenced design QA), not the mock to the screen by pixel delta. Intent is the decision the mock was arguing: which action is primary, what empty is saying, which level of information must outrank which. Implementation can match a frame’s grid and still turn a secondary action into the only visible button — raster passed, intent gone.

This is not a cognitive walkthrough asking whether a first-time user will think of the next step, and it is not treating the mock as a gold raster. The mock illustrates a decision; the illustration carries composition accidents, placeholder data, and a compromise at one width. The walkthrough asks whether the shipped product still executes that decision.

Why it happens

A mock carries two kinds of information. Decisions: the primary button submits, an empty list should prompt creation, an error belongs beside the field. Painting results of that one frame: 2 extra pixels to sit on the grid, a cropped placeholder avatar, demo copy that happens to fit one line. Pixel diff cannot tell the kinds apart — it rewards photocopying the illustration, accidents included.

Intent comparison requires writing the decision as a testable sentence, then asking the running product whether the sentence still holds. Sentence holds, pixels drift: implementation took another equally legal path (font fallback, platform control). Sentence fails, pixels are close: the more dangerous miss — it looks like the mock and does a different job. Walkthrough output is “intent sentence + holds or not”, not a screenshot covered in redlines. Redlines may attach; they must not judge.

Where it stops holding

Campaign pages and ads that must register to print have “match this composition” as the intent; pixel delta is intent delta. Contrast floors and minimum touch sizes are already numeric intent; they need no translation into a sentence. When exploration has not converged and two decisions coexist in the file, there is no single intent to check — stop at “which decision is in force” before scoring the build. A polish pass both sides have declared as pixel-only will collapse into redlines; that is a different activity and must not land in the intent-walkthrough log.

Applying it

• Before the session, list intent sentences for the feature, each mapping to an observable product behavior, not to a measurement.
• Score each sentence holds / does not hold against the running product; when it fails, record the actual behavior, not the pixel gap.
• Promote a pixel gap to a finding only if it rewrites an intent sentence (secondary weight overtaking primary); gaps that cannot rewrite a sentence go to optional polish.
• How to check: sample ten walkthrough records. Each must yield an intent sentence. Records that only say “off by 2px” with no sentence are removed from the walkthrough log and moved to a polish list.

Related

• Same group: R2.02.2 Run the walkthrough after feature-complete, before ship · R2.02.3 Grade findings by severity instead of demanding every fix
• Adjacent: R1.03 Component state completeness · R2.12 Design–engineering cadence
• Search terms: design QA · design intent · pixel-perfect · implementation walkthrough