Design review playbook: Evergreen decisions, visual craft, and learning

Purpose: help a consuming agent turn research into a concrete design improvement. Prepared on 13 September 2026. This is a working method and a set of conditional recommendations, not a validated scoring instrument or a new product policy. Principles owns the underlying synthesis; Worked examples demonstrates its application.

Start with the question, not the whole library

State the task, intended audience, current artifact/version, and observable success condition. Read the relevant principles, then one useful example and its source or conflict if the choice is uncertain. Reading every source is not a prerequisite for fixing one clear defect. A broad redesign needs a broader review. Product authority, brand, access, and technical constraints come from the actual product owner, not this general organization.

For a marketing page, examine understanding of the offer, credible proof, material conditions, and the next step. For an informational site, examine finding and understanding the answer. For a repeatedly used web application, examine efficient work, correction, and return. This task split is our review recommendation, not a rule that engagement or conversion always has the same meaning.

For a whole site rather than one screen, run the Site coherence pass: lens panels before and after building, a measuring consistency audit, and owner calls in batches.

Before a new page or a redesign, use How to do UX and UI: it owns the thinking before a screen and the persona panel rounds around it. This playbook reviews the finished screen.

Six evergreen decision prompts

1. Design the filled state, the failed state, and the return visit. Review populated and interrupted work alongside first use. Do not invent persistence that the product lacks; establish what survives and what the person can recover. Use E2, populated forms, and E6, asynchronous work. This prompt operationalizes the existing complete-journey and state principles; it is not an instruction to show every possible state at once.

2. Simplify the decision, not merely the screen. Before hiding content, name the decision it supports. Keep necessary comparisons possible; place less frequent controls behind a discoverable entry when appropriate. A sparse screen is not the goal. Use E1, comparison versus discovery, and the disclosure principle.

3. Put information where it changes a decision. Our default is to keep relevant scope, consequences, and needed explanation close to the action or claim. Do not repeat every caveat beside every control. Establish what the person needs at this point in the journey. Basis: accurate working models and proportionate control. This is a placement heuristic, not a universal disclosure checklist.

4. A component includes behavior over time. Specify entry, focus, waiting, error, completion, and exit as applicable. Match that specification to the actual component implementation. A static artifact can establish appearance but not keyboard or network behavior. Use E4, tabs, and E5, modal entry and return.

5. Preserve meaning when layout changes. Review relationships, reading order, visible labels, and access to actions across narrow views and text changes. Do not reduce responsive design to stacking columns or shrinking type. A necessary two-dimensional comparison has different constraints from a reading page. Use E7, resilient content, and the WCAG resilience checks.

6. Every 'always' needs a boundary. Identify whether the instruction is a normative requirement, platform convention, observed finding, expert heuristic, or hypothesis. Preserve actual standards; test conditional choices. Do not turn this reminder into an excuse to ignore accessibility requirements. Use Myths and E3, conflicting validation advice.

Visual-craft review

The checks below are our practical synthesis. They use hierarchy, contrast, and grouping as tools, not as a formula for taste. Source: NN/g visual design principles, read 2026-09-13. The source supports the conceptual tools; the review questions and actions below are our proposed method. No numeric spacing system, font choice, or card radius is made universal here.

Hold content and task constant when comparing compositions. Use the three-composition exercise. Judge visual appeal separately from task success. Avoid claiming that a screenshot establishes interaction quality or conversion.

Choosing and keeping an illustration style

Evidence status: practice from one implementation (a recipe site's full picture set, 118 generated pictures, 14 October 2026), checked in the real page at the sizes it shows. Not tested with users; no outside source yet. Treat it as a working method and revise it when a second site uses it.

One style per role

Every generated picture on a site plays a role: product cutout, icon, teaching comparison, cover, empty state or decoration. Give each role one style, choose it before generating any picture, and write it down. A role shown in two styles reads unfinished even when each picture is good.

A site may keep a few styles when each one owns a role and no role mixes two. On one recipe site, after a site coherence pass over every screen on 16 October 2026: photographed objects for decoration and states (empty, error), paintings for learning and rewards, line drawing for icons and the map. Two styles in one role break coherence; separate styles for separate roles do not. Write the role table down with the style templates. The rule and its example are in Principles under One picture style per role, where it stays a candidate rule until a second site tests it.

Choose in place, not in a gallery

Compare candidate styles inside the real layout. Render the same four slots in each candidate (a card, a teaching comparison, a cover and an empty state), set them into a mock of the actual page with its fonts, colours and crops, and let the owner switch between them. A loose gallery of pictures hides the problems that matter: crops, the smallest size, and how pictures sit next to real photographs and video.

Write the style as a template

A style is a written prompt template with an owner document, not a reference image someone remembers. Split it into:

Keep the template in a machine-readable file next to a script that builds every prompt from it. Keep each picture's exact prompt with the picture.

Test at the smallest size first

Before generating a full set, generate one batch of the smallest slot (a product cutout shown at icon size, such as an ingredient) and look at it at every size the page shows it (48, 40 and 32 px on the site this came from), on the light and the dark theme. Decorative touches that carry a large picture (a paint stroke, a texture, a surface) usually swamp a small one. When they do, define a small-size variant of the same style: the same light, colour and angle, without the touch, on a transparent ground so the page's own background is the ground. Write the variant into the template; do not leave it to each run. When icons are a role of their own with their own style, as line drawings were on that site after 16 October 2026, test that style at its smallest size instead.

No words in pictures

Pictures carry no text: no labels, captions, numbers, arrows with words, or brand names on bottles and packs. Labels belong in HTML next to or under the picture, where they stay translatable, readable by screen readers, legible at every crop and editable without regenerating. A teaching comparison ("tender / crisp") is a wordless picture plus two HTML labels. No people or hands unless the product is about them; generated hands often come out wrong (seen on one site, not counted).

Keep it consistent over time

End-to-end review procedure

Step 1: Establish the job. Write a one-paragraph task brief. Identify the person, trigger, desired outcome, context, and real constraints. Mark assumptions. Do not expand a small correction into an unrelated redesign.

Step 2: Walk the journey. Follow the actual entry path, primary action, result, correction, and return. Record what the interface shows and what its implementation actually does. When only a mockup is available, mark interaction checks as untested rather than infer behavior.

Step 3: Challenge the fragile states. Choose relevant populated, empty, delayed, failed, partially completed, and permission-restricted states. Include narrow views, keyboard use, text changes, and representative long content. Explain why each chosen case is relevant; do not create an indiscriminate catalog of imaginary edge cases.

Step 4: Propose a bounded change. Lead with the most consequential obstacle. Separate verified defects from predicted friction and taste. Explain the trade-off and the smallest coherent intervention, including states or copy that must change together.

Step 5: Check the result and preserve the learning. Repeat the task and affected states against the changed artifact. Record test conditions and evidence. A source-informed recommendation is not a measured improvement. Return verified reusable lessons to the appropriate owner here; retain product-specific decisions with the product.

Finding template

Original fictional example: the task is identifying renewals due soon. The fixture stipulates that the date is small and below several promotional badges; this is an invented starting condition, not an inspected live screen. Slower renewal finding is a hypothesis. Proposed change: put date and renewal status in an aligned row and reduce badge emphasis. Acceptance check: ask representative users to find items due before a specified date with unchanged data. Record errors and effort. This example contains no participant results.

Prioritization and evidence discipline

Use these proposed categories rather than one blended quality score. A blocker prevents a required task, causes loss of work, or violates an applicable requirement. A major issue creates substantial confusion or avoidable recovery work. A minor issue adds local friction without blocking completion. A preference concerns product taste not supported as a usability defect. Record severity and confidence separately: a plausible severe risk can be untested. Do not average a blocker away with strong visual appeal, and do not label taste as a standards violation.

Automated checks, browser trials, expert reviews, and observed users answer different questions. Keep a check marked untested when the available tools cannot establish it. 'Looks accessible' and 'a model approved it' are not test records.

Learning from actual corrections

Capture the smallest reusable lesson, not an entire private conversation. A useful record contains: the original task and artifact version; the correction with its actual source; the old assumption; the changed design; why it might work; a counterexample; verification and residual uncertainty; and the owner that should change. Record a real user statement as a user statement, not an experimental result. Obtain permission before moving private product examples into an audience that should not see them.

Update Worked examples for a new teaching case, Principles for a changed general rule, the matching Source document (see the Source directory) for newly verified external evidence, and Conflicts for unresolved contradictory guidance. Append the dated learning to Research log. Keep specific brand, access, commercial, and implementation decisions with their product owners. An example becomes implementation-tested or user-observed only when the corresponding evidence is attached. Do not create a new standing loop, scheduler, or document for every review finding.

To evaluate whether the organization improves an agent rather than simply enlarging its instructions, use the paired evaluation pack. Ordinary reviews can use this playbook directly; they do not require running a benchmark first.