Principles: Evidence-based UX and UI for websites

Status: canonical for this organization. Principles 1 to 15 come from a research pass on 13 September 2026 and carry evidence grades. The sections from Convey qualities through the experience onward are working rules added from September to October 2026, most learned on one recipe site from owner judgement and one-site measurement; treat each as a working rule, not a research finding, unless it names a stronger evidence class. These principles guide website and browser-application design, including mobile web. They do not certify a product or replace observation of its users. Native apps and games require a separately justified transfer.

Use Conflicts and open questions where a decision depends on context or uncovered evidence. Check Myths before adopting a memorable numerical rule. Source coverage and previous checks live in the Research log; AGENTS.md lists which document holds what.

How to use the evidence

A standard states requirements within its conformance scope. A controlled study supports findings under its tested conditions. Practitioner guidance and single-expert heuristics provide inspection tools. Our application recommendations are synthesis or hypotheses, not additional empirical findings. Source notes preserve access depth, dates, limitations, and disagreements. An abstract-only reading is not a full-method review.

Recommended focus, not an experimentally established ranking: define the useful complete journey; make the model, navigation, and next action understandable; design states and recovery; refine visual expression around that work. Accessibility, reliability, and user research apply throughout rather than at the end.

Principles

1. Design for a useful outcome and its complete journey. State who arrives, what they need, and what observable result counts as success. Design entry, action, result, correction, and return together. For an informational page, finding an answer may be the outcome; a transaction needs a confirmed result. Do not equate more engagement with more value. Evidence: our method synthesizes a goal-based measurement framework and transaction guidance, not a universal conversion recipe. Basis: goal-to-metric mapping and transaction review.

2. Make the user's working model accurate. Show the current object, relevant scope, and likely effect of the next action. Use language that explains the real boundary rather than disguising it. Our test: ask a new participant to predict what an action will change before performing it. Familiar terminology is not sufficient when the underlying access or action model differs. Evidence: practitioner guidance; this test is our application. Basis: mental models.

3. Make paths findable and predictable, not arbitrarily short. Use meaningful labels, a recognizable current location, and a usable return path. Test whether people choose a sensible route without coaching. Do not impose a three-click limit or hide important destinations merely to reduce navigation breadth. Both crowded choices and deep structure need scrutiny. Evidence: practitioner synthesis and review of navigation claims, not a fixed numerical law. Basis: navigation evidence and limits.

4. Reveal complexity according to the task. Keep frequent actions available; make secondary capabilities discoverable. Separate task stages when that helps, but keep interdependent choices visible when comparison is needed. Our boundary: do not hide price, recipient, access scope, or irreversible consequences to make a screen look simpler. Evidence: practitioner guidance; consequence visibility is our application. This is not an instruction to put every field on a separate page. Basis: progressive versus staged disclosure and question grouping.

5. Use visual hierarchy to explain importance and relationships. Identify the main object of attention, its necessary context, and the next useful action. Use scale, contrast, alignment, and spacing to express those roles. Test with real content, long labels, narrow screens, and enlarged text. Empty space and equal-sized cards are not objectives in themselves. Evidence: practitioner visual-design guidance; the proposed stress cases are our method. Basis: visual hierarchy.

6. Make controls and copy explain the interaction. Give actions recognizable affordances and specific labels. Keep the same interaction meaning stable across the site. Our review asks whether a control can be found, understood, and activated without exploratory clicking or hover hunting. A visually dominant action can clarify a local decision, but one-button-per-screen is not a universal rule. Evidence: usability heuristics and single-expert guidance; the local review is synthesis. Basis: usability heuristics and discoverability review.

7. Distinguish acknowledgment, progress, and completion. Design truthful pending, successful, failed, and partially completed states where they can occur. A fast response should acknowledge input without claiming an unfinished effect is complete. For ambiguous outcomes, explain what is known before encouraging a repeat action. Evidence: our state-design application of visibility guidance and platform measurement definitions. A responsive next paint does not prove the server-side task finished. Basis: visible system state and INP's measurement boundary.

8. Make correction a usable path. Preserve valid inputs, identify the problem, and guide the person to the affected control. For consequential submissions, provide a suitable review opportunity. Our acceptance test includes a realistic mistake and recovery without starting over. A page-level error summary is useful for some forms, not every background notification. Evidence: maintained government service patterns plus our application. Basis: locatable error recovery and answer review.

9. Match control and interruption to the consequences. Keep escape and correction available. Promise reversal only for effects that can actually be reversed. Our design hypothesis is low interruption for routine reversible work, with explicit scope and review where errors have consequential external effects. Neither constant confirmation nor blanket automation is the default answer. Evidence: expert control principles and Human-AI application guidance; the risk calibration needs task-specific testing. Basis: Shneiderman's rules and HAX guidance; our application: control and reversal and control versus interruption.

10. Treat accessibility as a whole-journey requirement. Apply WCAG 2.2 A and AA across the relevant pages and complete processes. Check text alternatives for images, keyboard use, focus, labels, contrast, reflow, status, and input alternatives against the actual criteria. Target size and contrast alone are not a conformance audit. Evidence: normative standard; Understanding pages are informative explanations. Do not confuse native platform units with CSS pixels or the enhanced AAA target criterion with AA. Basis: normative authority and complete processes and target-size criteria.

11. Measure perceived responsiveness and useful completion separately. Use current field performance metrics, then add task-specific measures such as a useful search result or confirmed save. Inspect slower conditions and unexpected layout movement. A good lab score or a polished loading state does not establish a fast complete workflow. Evidence: platform measurement guidance; task-specific checks are our recommendation. Current thresholds and their percentile basis belong in the source, not a timeless mnemonic. Basis: Core Web Vitals and task completion checks.

12. Test aesthetic impression separately from successful use. Give the site coherent expression without requiring novelty in every interaction. Our hypothesis is familiar operation with distinctive typography, tone, material, and selected details. First-impression ratings are not evidence of conversion, retention, or task success. Evidence: controlled screenshot-rating studies, accessed at abstract level; the design recommendation is an inference, not their tested product prescription. Basis: first-impression study and transfer limits.

13. Standardize repeated behavior, not only appearance. Maintain a small set of reusable components and patterns around actual recurring tasks. Our component review includes keyboard, focus, pending, disabled, error, and responsive behavior where applicable. Avoid a large hypothetical library before useful journeys establish the need. Evidence: practitioner design-system guidance; scope selection is our recommendation for a small team. Consistency should not preserve a demonstrated interaction defect. Basis: design-system scope and maintenance.

14. Use observation to revise design and evidence to interpret metrics. Test concrete tasks with representative people, fix important obstacles, and test again. Cover distinct audiences and tasks. Small qualitative rounds find and explain problems; quantitative estimates need an appropriate measurement and uncertainty plan. Our rule is to label AI simulations, persona panels and internal reviews as critique (the house method calls these findings "modelled minds"), never as observed user behavior. Evidence: practitioner research guidance and goal-based measurement; the AI-evidence boundary is our methodological choice. Basis: qualitative coverage, quantitative scope, goal-based measurement, and outcome-based measures.

15. For AI-enabled web work, distinguish suggestions from effects. Make capabilities, limitations, correction, and meaningful control usable in context. Our proposed interface separates a suggestion, authorization, running work, and completed effect, with evidence and changes inspectable where they matter. A generated explanation is not a truth guarantee. Evidence: research-derived Human-AI guidance with practitioner evaluation; this state model is an explicit transfer hypothesis. Ordinary static pages need no AI control surface. Basis: HAX guidance and website application.

Applying the principles in a review

Use How to do UX and UI for the thinking before a design and the panel rounds around it. Use the Design review playbook for a finished screen: the task brief, complete-journey review, state checks, concrete findings, priorities, and what to record afterwards. Use the Site coherence pass to make a whole site read as one. The Worked examples supply conditional applications, not new universal rules. The Evaluation pack describes how to test whether this organization improves an agent's design work; that test has not run yet. This document owns the principles, not a copy of any of these procedures.

Do not import a product's brand, access policy, pricing, or business goal into these general principles. Such decisions remain with that product and its accountable owner.

Convey qualities through the experience

Adopted 17 September 2026. Let people experience the quality you want them to believe in. Express capability, collaboration, and progress through work they can inspect and actions they can take. Copy should clarify that experience.

For a work product, a clear next action, visible authorship, inspectable changes, responsive navigation, and preserved context can make the product feel useful and alive. Decorative motion, aspirational imagery, or claims about being powerful cannot substitute for those behaviors. Quiet visual design and substantial capability can coexist.

Use action-oriented labels only when the interaction fulfills their promise. Describe the actual searchable objects and supported actions. Do not invent opportunities, activity, credentials, or progress to create a sense of momentum.

Review question: without promotional claims, can a person understand what is happening, who is involved, and what they can do next? Test this in a complete working journey, separately from aesthetic impression. Evidence status: owner judgement from a design discussion on 17 September 2026; an agreed design principle and testable product hypothesis, not a new empirical research finding.

One focal path per screen

A screen's first view gives the eye one path: the headline first, then the one main action, then the strongest image, and only then the rest. A layout that splits the first view into competing halves (copy on the left, a large video on the right) leaves the reader not knowing where to look, even when both halves are good. Check a design by tracing where the eye lands first, second and third; if the answer is "it depends", the screen has two focal points.

Source: a site owner, 13 October 2026, comparing two landing heroes of a recipe site live: in the centred hero the eye went from the title down to the button and then to the biggest image, while the split video hero left the eye unsure where to look. The centred "food first" hero (headline, button, then a row of dishes rising to the largest in the middle) was chosen over a split "video first" hero. Evidence class: one owner's judgement on a live comparison, not user-observed. A modelled attention heatmap can compare the two heroes as a critique aid, never as evidence of where visitors look (see heatmaps in the Site coherence pass).

Count the voices above the fold. List every element in the first screen that asks for attention (links, buttons, chips, play marks, coloured spots, pictures), count them, and cut controls that repeat an affordance the element already has, such as an arrow inside every chip that is already a link. Why: each extra voice takes a share of the first glance away from the one path. Evidence: a recipe site's landing had 19 small controls above the fold at 1440 pixels wide; the quieter version dropped the arrows from its name chips and drew its play marks in the text colour.

Accent budget. Count the accent colour's uses above the fold, and count the pictures too: brush strokes, props and backgrounds in the accent hue spend the same budget as buttons. Keep the strongest accent for the one main action. Why: an accent used everywhere stops pointing at anything. Quick test: list the accent spots, then count strong accent pixels in a screenshot and note which element each comes from. Evidence: the same landing had about 12 accent spots above the fold, and 84% of its strong accent pixels came from brush strokes in the pictures, not from the interface, so quieting the buttons alone could not have calmed it.

Source for the two rules above: a fit pass on a recipe site's landing, 14 October 2026, by three reviewers who each measured the page; the owner accepted the changes. Evidence class: computed-style and pixel measurements of one site plus owner judgement; the effect on visitors is not measured.

One action row per screen. Gather the actions for the thing a screen shows (save, share, print, cook) into one row, and show that row once. Why: the same actions offered twice read as two offers and double the voices on the focal path. Evidence: a recipe page on that site now keeps one action row. Learned 16 October 2026 in a site coherence pass over every screen, from a reviewer who read all 116 screenshots for calm and hierarchy; one site, not user-tested.

Quiet chrome before content

Chrome before content. Measure how much of the first screen the header and other chrome take before the first real content, and keep it small: on a content site, the first content starts within about 15 to 20% of the screen height on desktop. Report two numbers at 1440 by 900 and 390 by 844: where the first content starts, and where the first thing the site offers (a dish, an article, a product) starts. Why: chrome is the site talking about itself; every pixel of it above the content delays what the visitor came for. Evidence: on a recipe site's landing the first dish started at 538 pixels on desktop, against about 150 (about 17%) on NYT Cooking and Ottolenghi, and on a phone 59% down the screen; a 121 pixel two-row header was the largest single cause.

A pale band drawn by hairlines reads as a toolbar. A header band only slightly lighter than the page still reads as a toolbar when hairlines draw its edges. To make a header calm, put it on the page's own ground with one hairline below. A transparent header over a full-bleed photo is a different case and can stay. Why: the lines close the band into a box, and a box of controls reads as an application's toolbar, not as part of the page. Evidence: the same landing's header sat on #fffdf8 over a #faf7f0 page, a barely visible difference, with a hairline above and below its second row; all three reviewers read it as a toolbar. On the page's colour with one hairline, and in one row from 1100 pixels wide, it shrank from 121 to 73 pixels and read as part of the page.

The wordmark and the headline do not compete. Keep the wordmark well below the first headline in size, so the headline is the first stop on the focal path. Why: two large display lines at the top of the screen give the eye two places to start. Evidence: the same landing drew a 30 pixel wordmark above a 63 pixel headline, 2.1 to 1; at 25 pixels, 2.5 to 1, the headline led. One site, so the ratio is a starting point, not a threshold.

Source: the fit pass on a recipe site's landing, 14 October 2026: three lenses (hierarchy and weight, a first visitor on a phone, editorial references from five strong cooking sites) measured the live page with computed styles and pixel counts and tried each change as injected CSS; the owner accepted all five changes. Evidence class: measurement of one site against five references plus owner judgement; the effect on visitors is not measured. Relates to Principle 5.

Recognise, don't recall

Name every choice by what it is, never by a number or code alone, and never put meaning only in a tooltip. People recognise a visible label far more reliably than they recall what a number or an icon stood for, and a tooltip does not exist on a touch screen or for anyone who does not hover. Quick test: cover the numbers and icons and ask whether a newcomer can still say where each choice leads; then open the screen on a phone and check that no meaning disappears.

Example: a cooking app's finish screen asked "Where did it go wrong?" with chips labelled "Step 1" to "Step 6". Nobody remembers which step was step 4. Rows that read "4 · Fold in the potatoes" let the cook point at the moment itself.

Source: a site coherence pass on a recipe and cooking-lessons website, 13 and 14 October 2026; the owner caught this on a screen the first review panel had itself proposed. Adopted 14 October 2026. Evidence class: an established usability heuristic (usability heuristics, recognition rather than recall) applied by the owner; not user-observed. It sharpens Principle 6.

One presentation per kind of thing

Each kind of thing the site shows (a recipe, a lesson, an article) has one grid card and one compact row, and every page uses those two. The same thing drawn two ways reads as two different things and makes the site look assembled from parts, so treat it as a bug, not a variation. Quick test: list each kind the site shows and count its distinct anatomies (picture ratio, title face and size, teaser, meta line); any kind with more than one card and one row is a finding.

Example: a recipe site drew recipes square everywhere except search, where they were 4:3; one card component had three teaser lengths; and related items appeared in five different compact row layouts. The proposed fix was one card anatomy (picture, optional kind label, title, two-line teaser, meta last) with a small table of what changes per kind, and one related-item row for every compact list.

Source: the same site coherence pass; a measuring audit of computed styles found the variants. Adopted 14 October 2026. Evidence class: practitioner design-system guidance (Principle 13) plus a measured inventory of one site; the effect on users is not measured.

The layout owns rhythm

A section pads only its top, with one shared section space; the page layout owns the space before the footer, and nothing else adds a bottom margin; gaps are measured, not eyeballed. When each section adds its own margins, gaps stack and drift from page to page, and the eye reads uneven space as a mistake. Quick test: on every page, at a phone and a desktop width, measure from the last visible content of each section to the next heading, and from the last content to the footer; every value should be one of two or three tokens.

Example: on a recipe site, the gaps between sections of one page ranged from 48 to 148 pixels, and the space before the footer from 104 to 272 pixels, against one section token of 72 to 112 pixels. The owner saw "a lot of empty space at the end"; the measurement showed where each extra margin came from.

Source: the same site coherence pass, from a reviewer reading as a designer and an audit that measured the pages. Adopted 14 October 2026. Evidence class: practitioner visual-design guidance on grouping and rhythm (Principle 5) turned into a measurable rule; not user-tested.

Pictures: never twice, never through a face, video frames in their own ratio

Never show the same picture twice on one page, never crop through a face, and show a video frame only in its native ratio. A repeated picture makes different things look like one thing, a cut face reads as careless, and a video service may pad an upright video's landscape thumbnail with side bars, which any other crop exposes or cuts through the person. YouTube, for example, usually serves a Short's landscape thumbnail as the upright frame with bars at both sides in a 1280 by 720 image, as users of the yt-dlp download tool report (yt-dlp issue 9837, read 2026-10-29). A picture that carries meaning also gets a text alternative that serves the same purpose, and a decorative one is marked so assistive technology skips it (WCAG 2.2 SC 1.1.1, Level A, Understanding Non-text Content, read 2026-10-29; part of the accessibility requirement). Quick test: list every picture source on the page and look for duplicates; look at every crop that holds a person; compare each video frame's natural size with its slot; check that each picture has a text alternative or is marked decorative.

Example: at the end of a recipe page, two collection cards showed the same dish photo, two more showed the same video frame cropped through the presenter, and the dish photo repeated the page's own hero. The fix assigns pictures once per page: it keeps a set of pictures already used, and when an item's picture is taken it picks a different item that still has an unused picture, rather than showing the same item with a lesser picture. A name tile (the item's name on a plain ground) is only for an item that has no picture at all; never an empty plate.

Source: the same site coherence pass, from an owner screenshot and the measuring audit. Adopted 14 October 2026. Refined 16 October 2026: prevent a repeat by choosing a different item, not a lesser picture, because a weaker picture of the same dish still reads as a repeat. After the 16 October 2026 pass, that site's home page and regional rows picked other dishes, and a recipe stopped repeating its pictures under its video. Evidence class: a craft rule from the owner's judgement, a measured audit and a cross-page coherence lens; not user-tested.

Sections earn their place

A section with nothing in it leaves the navigation; its address keeps working and shows one shared empty state that says what is coming and offers one action. A navigation item that leads to an empty page breaks a promise, and promises the site cannot keep yet cost trust. Quick test: as a signed-out visitor, open every navigation item and every promise of a benefit; anything empty, or "coming soon" said in several different ways, is a finding.

Example: a cooking site promised letters as an account benefit and offered a letters sign-up before any letter existed, showed a courses area with no course in it, and drew a course page heading over an empty section. The fix: hide the navigation item until the first item exists, keep the address with one empty state such as "The first collections are on their way. Until then, find a dish to cook." and one button, and hide empty sections.

Source: the same site coherence pass, from reviewers reading as an editor and as a learner. Adopted 14 October 2026. Evidence class: synthesis from practitioner guidance on findable, predictable paths (Principle 3); not user-tested.

One name per thing, and one voice rule

Give each thing one name, keep the names in a short glossary, and write one rule for who speaks: "I", "we", or the site about its author. Names that drift make people wonder whether two words mean two things, and mixed voices make a site sound assembled. Quick test: search the site's text for every synonym in the glossary; read three pages aloud and mark each place where the speaker changes.

Example: on a recipe site, saving a dish was called "favourites", "saved recipes" and "collection" on different pages, and the site spoke in three voices. The glossary settled it: Save always lands in "Saved recipes", and "I cooked this" lands in "Cooking history". The voice rule: the site speaks about its author in the third person; the author says "I" only in what they sign; "we" is kept for where the company must speak (codes, errors, legal).

Source: the same site coherence pass, from a reviewer reading as an editor. Adopted 14 October 2026. Evidence class: content-design practice; the sibling organization's Copy and Messaging Principles own the words, and this principle owns only the rule that names and voice stay single across screens.

One label per destination. Every link to the same place carries the same words, so the reader learns one way there. An arrow marks a link that goes to another page, never a submit button that acts where it is. A heading over a tab uses the tab's own word. Example: on a recipe site, the way to the recipes is "Find a recipe" everywhere, with one arrow. Learned 16 October 2026 from a reviewer comparing the pages with each other in a site coherence pass over every screen; synthesis from Principle 3 and Principle 6, not user-tested.

One home per action

Rule: each thing a person can do (save, mark cooked, invite, subscribe, sign out) and each piece of state they can see (a list, a count, a progress mark) has exactly one home: one surface that performs the action or shows the full list, under one set of rules. Elsewhere, a summary may lead into that home, such as a "Cooked" strip of the last few dishes that links to the full cooking history, as long as it reads the same source and its only action is to go there. A second surface that performs the same action, or shows the same list under its own rules, competes with the first.

Why: two homes for one thing make people ask which one is real, and they drift: built and changed apart, they soon count, word or behave differently, and each difference reads as a bug. One clear way to do a thing is easier to learn and to trust than two partial ones.

Grounded in: Nielsen's usability heuristic 8, aesthetic and minimalist design (every extra unit competes with the relevant ones and lowers their visibility), and heuristic 4, consistency and standards (people should not have to wonder whether different places or words mean the same thing). Mental models: people hold one belief about how a product works, and a mismatch calls for changing the structure or explaining the difference better (see mental models); two homes for one job create that mismatch and blur which control does what. In the code the same rule is a single source of truth: one read and one rule per list or count, so the surfaces cannot drift.

The exception, a shortcut to the same control: on 19 October 2026 the owner kept the letters switch in three places (Settings, the Letters page, and the account's front page while the letters are off), because there it is a shortcut to the same control. The same control may appear in more than one place when it is literally the same component, reading and writing the same state under the same rule, and it sits where the reader already is when the choice matters. That is one home with shortcuts, not two homes. What the rule forbids is a second implementation: its own read, its own count or its own wording for the same job, which is how surfaces drift.

Example: on a recipe site's account page, a row of portraits of the people who share the account and a People tab both showed and managed the same people, and had drifted apart: they counted people differently. The owner removed the tab. The row is now the one home: its "Invite someone" tile opens the invite as a dialog, the account owner taps a portrait to remove that person in a dialog, and leaving a shared account stays in Settings with the reader's other account choices.

How to apply it in design: before adding a control or a list, name the home of that action or state. If one exists, link to it or make the new surface a summary of it, never a second copy. A summary gets one visible way into the home and no actions of its own. Where two surfaces already exist, keep the one people reach in context, move the other's unique parts into it, and remove the rest.

How to apply it in review: list every action and every list or count the site offers, with each surface that offers it. Any item with two surfaces is a finding unless one is a summary that reads the same source and leads to the other. Compare the same count across surfaces, and the label of every entry point to the same action (One label per destination). Two buttons on one screen that do the same thing are the single-screen case, covered by One action row per screen.

Source: owner ruling, 19 October 2026, in review of a recipe site's new account page. Evidence class: owner judgement, in line with the consistency heuristic in usability heuristics and Principle 13; not user-tested. It widens One action row per screen from one screen to the whole site, and sits beside One name per thing and One presentation per kind of thing. Learned 19 October 2026.

One visible action per element

Rule: outside running prose there are no underlined text links. In cards, lists, headers, footers and meta rows the element itself (the card or its title) is the link, or the action is an icon button with an accessible name, and each element shows one visible action. Two differently styled text links stacked on one card are the failure this rule names.

Why: stacked, differently coloured text links read like a form, not a product, and each one competes for the same glance; one clear action per element tells the reader what the element does.

Grounded in: Nielsen's usability heuristics 8, aesthetic and minimalist design, and 4, consistency and standards (usability heuristics). Our reading of heuristic 4: by convention an underline marks a link inside running text. Synthesis, not user-tested.

Calls to action point forward

Rule: in a card, a section or a dialog, an action that moves the reader on (start, continue, open, explore, subscribe) sits at the right of its group or centred under what it acts on, never alone at the left edge. An action that goes back or cancels takes the left. A form is the exception: its submit or Continue button lines up with the form's left edge, under the fields.

Why: in a left-to-right layout a block is read to its end on the right, and progress (next, forward arrows, the next page) is drawn to the right; a main action at the left reads as going back, and does not feel good to press. Desktop conventions for dialog buttons differ in order. Apple places the default button "on the trailing side of a row" and Cancel "typically on the leading side of a row" (Human Interface Guidelines, Alerts, read 2026-10-29), which matches this rule. Microsoft right-aligns a dialog's commit buttons and puts OK before Cancel, so Cancel sits to the right of OK (Windows dialog box guidelines, read 2026-10-29), which goes against it. A website dialog follows this rule, the Apple order. Neither convention cites a study, and this rule rests on none either. Evidence class: one owner's judgement on a live design. For forms the GOV.UK Design System advises the opposite: "Align the primary action button to the left edge of your form" (Button, read 2026-10-29). Forms follow GOV.UK.

Source: owner judgement, 23 October 2026, reviewing a course shelf on a recipe site: a main action should feel like moving forward, so it sits at the right or centred, never alone at the left.

How to apply it: in a card or a section, put the main action at the bottom right, or centred under the content; in a pair, the forward action on the right. On a phone a full-width button is centred by its width. A text link inside a sentence stays where the sentence puts it. In a right-to-left language, mirror the rule. In a form, align the main button with the form's left edge, as GOV.UK advises. In review, flag a main action that sits alone at the left edge of a card or section; a form's main button at the form's left edge is correct.

Sell at the few moments that grow the product

Rule: most of a product stays calm and quiet: it shows what is there and lets people get on with it. A few chosen moments are allowed to make the case, because a person acting there grows the product or gets real value they would otherwise miss: inviting someone (it brings a new person in), starting a subscription, signing up. At those moments, show the concrete benefits plainly (an image, two or three benefit lines with check marks, one clear action) so people act. Everywhere else, no selling. Which moments these are is the product owner's call; what may be said there follows the persuasion rule in Copy and Messaging Principles.

Why: when everything sells, nothing does. People overlook what looks like an ad, real content included (banner blindness: Kara Pernice, NN/g, Banner Blindness Revisited, read 2026-10-29), and stop trusting the calm parts too. Concentrating persuasion where motivation is the missing piece helps where it is needed without cheapening the rest; whether it raises conversion is not measured here. It follows BJ Fogg's behavior model (an action happens when motivation, ability and a prompt come together, so benefits supply motivation at the moment the prompt is there; Fogg Behavior Model, read 2026-10-29) and Nielsen's heuristic 8 (every extra unit competes with the relevant ones, so persuasion belongs only where it is the relevant unit).

Source: owner judgement, 20 October 2026, on a recipe site's invite dialog: show what inviting gives with a few check-marked benefit lines, a little more persuasive than the rest of the product but still restrained, and keep every other surface free of selling. Evidence class: one owner's judgement; not user-tested.

How to apply it: before adding persuasion, name the moment and why it is one of the few: it grows the product or unlocks value the person would otherwise miss. List only benefits that are true for the person reading (only what the person can use today), concrete and short; no urgency tricks, no exaggeration. Keep one primary action. In review, flag persuasion on a surface that is not one of the named moments, and flag a named moment that only states mechanics without its benefit.

Make it look like what it is

Rule: when a block is named after a familiar thing (a note, a letter, a postcard, a receipt, a recipe card), give it that thing's recognisable form, so a reader knows what it is before reading a word. A note from a person looks like a note from that person: a card that reads as paper, their portrait and name as the signature, their voice. Hint at the object, do not imitate it: keep body text in the readable site typeface and the contrast and structure accessible; the form signals what it is, the text stays easy to read.

Why: recognition is cheap and reading is expensive. A form people already know tells them at a glance who is speaking and how to treat it, and what is easy to process tends to be liked more (processing fluency: Reber, Schwarz and Winkielman, 2004, https://doi.org/10.1207/s15327957pspr0804_3, abstract read 2026-10-29). It follows Nielsen's heuristic 2, match between the system and the real world, and heuristic 6, recognition rather than recall. Plain text under a heading makes people read before they know why they should.

Source: owner judgement, 20 October 2026, on a recipe site where a block titled as one named person's notes was plain text under a heading. The owner's point: people recognise a familiar form at once, so a block that already says it holds notes should look like a paper note from that person, with their picture. Evidence class: one owner's judgement on a live page; not user-tested.

How to apply it: for each named block, ask what real object its name promises and whose it is, and give it that object's one or two telling features (paper surface, portrait and signature, a stamp or postmark) without costume. Use a real photo of that person that the site owns and may publish. In review, flag a block whose name promises an object or an author while its form is generic text, and flag decoration that hurts reading (script fonts for body text, low contrast, textures behind text).

Empty states show what will be there, and the first step

Rule: an empty list, page or panel shows a faint preview of what will fill it and one action that starts it (for example an empty cooking history shows a ghosted dish card and "Cook your first dish"). Never a bare "Nothing here yet".

Why: the empty state is the moment a person decides whether to begin; a preview tells them what the place is for, and one action removes the question of how to start. Nielsen Norman Group advises that an empty state shows system status, teaches what the area is for, and gives a direct way into the task (Kate Kaplan, 2021, Designing Empty States in Complex Applications, read 2026-10-29). That guidance rests on examples and reasoning and reports no measured effect on first use, so treat that effect as our hypothesis.

How to apply it: for every list or panel, design its empty state with the same care as its full state: what it will hold, why that is good for the reader, one action. In review, flag empty states that only say nothing is there, and empty states with more than one action.

Source: proposed during design work on one recipe site and approved by its owner, 20 October 2026. Evidence class: owner judgement, grounded in the research named under Why; not user-tested.

Every action answers

Rule: every action a person takes gets a visible reply within a moment: a changed state on the control itself (saved, cooked, copied), a short toast for actions whose result is elsewhere, an inline message when it failed and what to do. Silence is never an answer. Principle 7 adds that a quick reply must not claim an unfinished effect is done.

Why: without a reply, people repeat the action or doubt it happened. Nielsen's heuristic 1, visibility of system status: keep people informed about what is going on, through appropriate feedback within reasonable time.

How to apply it: name each action's answer when designing it: the control's new state first, a toast only when the result is out of view, a failure line that says what happened and what to do. Pair it with Motion only to confirm: the answer may move, once. In review, flag actions that change nothing visible, and toasts that repeat what the control already shows.

Source: proposed during design work on one recipe site and approved by its owner, 20 October 2026. Evidence class: owner judgement, grounded in the research named under Why; not user-tested.

Undo over "are you sure?"

Rule: an action that can be reversed happens at once and offers an undo (a toast with Undo, or the control flipping back); a confirmation dialog is only for an action that cannot be taken back, such as removing someone from a shared space or deleting for good.

Why: confirmation dialogs interrupt every time, and when they are overused people answer them without reading, so they protect little (Jakob Nielsen, NN/g, Confirmation Dialogs Can Prevent User Errors (If Not Overused), read 2026-10-29); an undo costs nothing when the action was meant and saves the mistake when it was not. Nielsen's heuristics 3, user control and freedom, and 5, error prevention. This section applies Principle 9; how much to interrupt for which consequence is still open (human control versus repeated interruption). Offer undo only when the effect is truly reversed (Myths).

How to apply it: for each destructive-looking action, ask whether it can be reversed. If yes, act and offer undo for long enough to notice (a few seconds, kept on screen while it has focus; the length is a craft choice, not measured). If no, confirm once, naming exactly what happens. In review, flag confirmations on reversible actions and irreversible actions without one.

Source: proposed during design work on one recipe site and approved by its owner, 20 October 2026. Evidence class: owner judgement, grounded in the research named under Why; not user-tested.

Show progress toward the next step, not totals

Rule: where people work toward something, show the distance to the next step ("2 of 5 dishes to the next badge", a ring filling toward the next badge), not only a running total ("Cooked 12 times").

Why: people put in more effort as a reward comes near; in one field study, café customers bought coffee more often the closer they were to a free one (the goal-gradient effect: Kivetz, Urminsky and Zheng, 2006, https://doi.org/10.1509/jmkr.43.1.39, abstract read 2026-10-29). A visible next step turns a count into a reason to continue; a bare total says what was done but not what is next.

How to apply it: for every count shown to a person, ask what the next step is and show the distance to it; keep the total for history views. In review, flag progress shown only as totals where a next step exists, and progress bars without a named goal.

Source: proposed during design work on one recipe site and approved by its owner, 20 October 2026. Evidence class: owner judgement, grounded in the research named under Why; not user-tested.

Make milestones a moment

Rule: when a person reaches a real milestone (earning the next badge, finishing a course, their first dish), give it a short, warm moment: the milestone's own picture, one line in the author's voice, and the next step. It is brief, and it is one of the two recorded exceptions to Motion only to confirm.

Why: people judge a past experience mostly by its most intense moment and its end, not its average (Kahneman's peak-end rule: Kahneman, Fredrickson, Schreiber and Redelmeier, 1993, https://doi.org/10.1111/j.1467-9280.1993.tb00589.x, abstract read 2026-10-29). That study measured painful episodes; applying it to milestones is a transfer, not a tested result. A marked milestone can become the memory of the product, while an unmarked one passes as a number changing.

How to apply it: list the product's real milestones (few, earned, not daily); design each one's moment once, reusing the milestone's picture; keep it dismissible and quiet for reduced motion. In review, flag milestones that pass silently and celebrations of non-events.

Source: proposed during design work on one recipe site and approved by its owner, 20 October 2026. Evidence class: owner judgement, grounded in the research named under Why; not user-tested.

Sensible defaults from what the product already knows

Rule: start every setting at the answer that is right for most people in this person's situation, from what the product already knows (country for units, currency and language; their last choice for the next time). The person acts only when the default is wrong, and can always change it. A question the person must answer in a form is not a setting. GOV.UK says not to pre-select its answer, because people then miss the question or submit the wrong answer (Radios, read 2026-10-29); Nielsen Norman Group advises a default in every radio list (Checkboxes vs. Radio Buttons, read 2026-10-29). Until testing settles it, leave a consequential answer empty.

Why: many people keep whatever is preselected, so the default decides the outcome for them. Defaults for becoming an organ donor had large effects on donation rates (Johnson and Goldstein, "Do Defaults Save Lives?", Science, 2003, https://doi.org/10.1126/science.1091721, abstract read 2026-10-29). A well-chosen default makes that choice correctly for them; a careless one makes it wrongly.

How to apply it: for every setting, name its default and the signal it comes from; remember a changed choice. Never default to something that costs money or shares data. In review, flag settings that start empty or at a default that suits the builder rather than the reader, and consequential form questions whose answer is pre-selected.

Source: proposed during design work on one recipe site and approved by its owner, 20 October 2026. Evidence class: owner judgement, grounded in the research named under Why; not user-tested.

Speed is part of the design

Rule: answer a person's action at once, and show what is still pending. Show the result of an action locally where you can, preload what the next tap will need, prefer a skeleton of the coming content to a spinner, and keep the first screen light.

Why: a quick reply keeps attention on the task; a slow one makes people notice the wait and lose the thread. Perceived speed shapes how good a product feels as much as its looks. NN/g puts the limit for a reply that feels instant at about 0.1 second and for unbroken flow at about 1 second (Response Times: The 3 Important Limits, read 2026-10-29). Core Web Vitals rate responsiveness as good at an INP of 200 ms or less at the 75th percentile, and INP measures the wait for the next frame, not the finished result (Core Web Vitals, responsiveness versus completion). The often quoted 400 ms rule is not a verified standard here (Myths).

How to apply it: for every action and page, name the response the person sees first and how fast it comes; treat preloading and instant local feedback as design decisions, not only engineering. In review, flag spinners where a skeleton or an instant local result would serve, and first screens weighed down by things not yet needed.

Source: proposed during design work on one recipe site and approved by its owner, 20 October 2026. Evidence class: owner judgement, grounded in the research named under Why; not user-tested.

Every page has one job, and its first screen does it

Rule: name each page's job in one line before designing it, and make the first screen do that job. An entry page convinces and routes; a finding page finds (search first, then browse); a page for one thing does that one thing. Sections that serve another page's job move to that page, or shrink to a small strip that leads there.

Why: people arrive with one intent per page. A finding page that opens with editorial sections makes them hunt for the search; an entry page that only lists things never makes its case. When two pages do each other's job, both get weaker. It is the page-level form of One focal path per screen and of Nielsen's heuristic 8 (every extra unit competes with the relevant ones).

Source: owner ruling, 21 October 2026, comparing a search-first recipes page on another site with a recipe site's own: the owner asked that each page's purpose be clear and that editorial sections on a finding page be smaller. Evidence class: owner judgement, in line with Nielsen's heuristic 8; not user-tested.

How to apply it: write the job line for every page (for example, on a recipe site: landing, convince and route; recipes, find a recipe; collection, a moment's dishes; recipe, cook one dish; learn, start a course; account, manage your account and who shares it). Order each page's sections by how directly they serve that job. In review, flag a first screen that does another page's job, and an entry page too short to make its case or route people on.

A browse link promises a shelf

Rule: every category tile, tag chip or filter a page offers leads to enough items to choose from (as a rule of thumb, at least three), or it is not shown. Tags and categories are content and get reviewed like copy.

Why: a tile that opens onto a single item feels broken and teaches people that browsing is not worth it. Sections earn their place covers empty sections; this covers a way in that leads almost nowhere.

How to apply it: count the items behind every browse link at render time and hide the link below the threshold. When a category looks thin, check the tagging before the design: on the site this rule comes from, a missing tag was the cause.

Source: a site-wide UX check of one recipe site, 21 October 2026, approved by its owner; the pattern showed up on several pages at once. Evidence class: a craft rule from review; not user-tested.

A failed read is not an empty state

Rule: when data does not load, say so and offer a retry. Never show the "nothing here yet" message for a failure.

Why: an empty state tells people there is nothing to find, so they leave; a failure shown as empty hides the fault from both the reader and the team.

How to apply it: keep three distinct states for every list or feed: loading, failed (with a retry), and truly empty. In review, force the read to fail and check which one appears.

Source: a site-wide UX check of one recipe site, 21 October 2026, approved by its owner; the pattern showed up on several pages at once. Evidence class: a craft rule from review; not user-tested.

One picture per thing, across the site

Rule: an item's chosen picture is the same on every page. Avoiding a repeat on one page may change which item is shown, never the item's picture, and never swaps it for a placeholder.

Why: people recognise things by their picture; when the same dish or course looks different on each page, it reads as a different thing, and the site feels assembled rather than designed. Pictures: never twice works within one page; this works across pages.

How to apply it: give each item one canonical cover and have every surface read it. When two slots on a page would show the same item, pick a different item for one slot.

Source: a site-wide UX check of one recipe site, 21 October 2026, approved by its owner; the pattern showed up on several pages at once. Evidence class: a craft rule from review; not user-tested.

Numbers in sentences come from the same source as the counters

Rule: any limit or count written into copy ("up to five people") reads the same value as the counter beside it ("0 of 5 places taken"), so the two cannot disagree.

Why: two sources for one number drift apart, and a reader who sees both no longer trusts either. This is One home per action applied to numbers in text.

How to apply it: never type a limit into a sentence; interpolate it from the value the counter uses. In review, change the limit once and check every sentence that mentions it.

Source: a site-wide UX check of one recipe site, 21 October 2026, approved by its owner; the pattern showed up on several pages at once. Evidence class: a craft rule from review; not user-tested.

Loading keeps the final layout

Rule: a placeholder has the same controls in the same places as the loaded screen. No control appears and then vanishes, and no count shows before the items it counts.

Why: a layout that shifts or a control that disappears while loading makes people tap the wrong thing and doubt what they see. Principle 11 asks reviewers to inspect unexpected layout movement.

How to apply it: build the skeleton from the loaded layout, not separately. Show counts only once the items are there. In review, throttle the connection and watch the screen settle.

Source: a site-wide UX check of one recipe site, 21 October 2026, approved by its owner; the pattern showed up on several pages at once. Evidence class: a craft rule from review; not user-tested.

Review first screens as a visitor sees them

Rule: judge what fits on the first screen in the visitor's view, not in an editor's or admin's view.

Why: editor bars, draft banners and admin tools push content down, so a first-screen check done while signed in as an editor misjudges what a visitor sees.

How to apply it: take first-screen measurements in a visitor preview, or subtract the editor bar's height, at phone and desktop width.

Source: a site-wide UX check of one recipe site, 21 October 2026, approved by its owner; the pattern showed up on several pages at once. Evidence class: a craft rule from review; not user-tested.

Don't stack text on pictures that already carry text

Don't lay a label over a picture that already carries text, such as a video poster or a thumbnail with a burned-in title; put the label beside or under it, or show only a play control. Two layers of lettering compete, and neither reads. Quick test: for every picture with an overlay, look at the picture without it; if it already has words, move the overlay off it.

Example: a lesson's video poster stacked the page title over the video's own lettering, repeating the heading just above it, and a cook mode label sat on a short video's burned-in title. The fix: no title on the poster, only the play button and a small chip at its edge, such as "Watch · about 2 min".

Source: a site coherence pass on one recipe site, 13 and 14 October 2026, seen by a reviewer reading as a learner and by an audit that measured the pages. Adopted 14 October 2026. Evidence class: a craft rule from review; not user-tested.

Give third-party embeds a stage

When you cannot control an outside player's own interface, open it in a space of its own, such as a modal at the video's native ratio, instead of fitting it into a small slot. A provider's logo, controls, share prompts and language appear inside its frame whatever the host page does, and in a small slot they collide with the page's own controls. Quick test: play every embed at phone width; count the controls on screen and check that each control has one meaning and the page has one language.

Example: an autoplaying row of short videos on a recipe site showed the provider's logo, its own pause and next overlay beside the site's pause control, and a share label in a different language from the page. A modal stage opened by a tap gives the provider's interface room and leaves one set of controls in view.

Source: a site coherence pass on one recipe site, 13 and 14 October 2026, seen by a reviewer reading as a first visitor. Adopted 14 October 2026. Evidence class: a craft rule from review; not user-tested. Modal focus and return follow the ARIA dialog pattern.

Print is a surface for how-to content

Any page people follow while doing something (a recipe, an instruction, a checklist) gets print styles: the content only, no site chrome, steps and quantities kept together. Some people print a recipe or an instruction to follow away from the screen (how many is not measured here), and a browser's default print of a web page wastes paper and buries the steps. Quick test: open print preview on each how-to page; count the pages, check that navigation, video slots and footers are gone, and check that no step breaks across a page.

Example: one recipe printed as 11 A4 pages, including the header, footer and video slots. A print stylesheet that keeps the title, the facts, the ingredients and the steps aims at one or two pages.

Source: a site coherence pass on one recipe site, 13 and 14 October 2026, seen by a reviewer reading as a first visitor. Adopted 14 October 2026. Evidence class: a craft rule from review; not user-tested.

Motion only to confirm

Use motion only to confirm that something happened (saved, next step, timer done); keep it short, and turn it off under reduced motion. Confirming motion tells people their action worked; decorative motion competes for attention, and motion can bring dizziness, nausea and headaches to people with vestibular disorders (W3C, Understanding SC 2.3.3 Animation from Interactions, read 2026-10-29). That criterion is level AAA, so turning motion off under reduced motion goes beyond the AA requirement. Two recorded exceptions: a real milestone may get a short celebration (Make milestones a moment), and a page that needs moving pictures before any tap may play your own short silent loops (Nothing from a third party loads before the visitor asks); both still follow the reduced motion setting. Quick test: list every animation and name what it confirms, and remove any without an answer; then switch on the operating system's reduced motion setting and check that each one stops or becomes a plain change of state.

Example: in a cooking app, saving a dish gave no sign that it worked, and steps jumped with no transition. The proposed motion: a short pop and a "Saved" notice that screen readers also announce, and a step change of about 180 milliseconds (a crossfade with a 12 pixel slide), all off under reduced motion.

Source: a site coherence pass on one recipe site, 13 and 14 October 2026, seen by a reviewer reading as a first visitor. Adopted 14 October 2026. Evidence class: a craft rule; announcing the result to assistive technology is part of the accessibility requirement, and confirmation versus completion follows Principle 7.

Nothing from a third party loads before the visitor asks

Rule: an embedded player, its preview picture or its script loads only after the visitor acts (a tap on Play), never on page load or on scroll.

Why: each such request sends the third party the visitor's IP address, and can send its cookies, before the visitor has chosen anything, and the visitor cannot see it. A German court held that a site which passed a visitor's IP address to Google through embedded web fonts, without consent, broke the GDPR (LG München I, 20 January 2022, 3 O 17493/20, judgment, read 2026-10-29). Treat any third-party request on load as the same legal risk in the EU; this is not legal advice.

Quick test: load the page in a fresh browser with the network panel open and no clicks; no request may go to the player's domains.

Example: a cooking site's video row showed the video service's preview pictures and preloaded its players; since 14 October 2026 it shows its own stills and loads the player only on Play.

Exception it creates for motion: where a page needs moving pictures before any tap, use your own short silent loops (a few seconds, small files, your own footage), never the third party's player. This is one of the two recorded exceptions to Motion only to confirm (14 October 2026); the other is a milestone moment. On a first screen these loops also keep to A motion budget for the first screen.

A motion budget for the first screen

Rule: a moving picture on a first screen plays once, for at most five seconds, then rests on its still. Once something moves, the screen drops its decoration and every extra line. Why: motion takes the first glance before anything else, so it spends the screen's whole attention budget. A clip that stops within five seconds also needs no pause control: WCAG 2.2 success criterion 2.2.2 (Pause, Stop, Hide) asks for one only when motion that starts automatically and runs beside other content lasts longer than five seconds (SC 2.2.2). Quick test: count what moves at once and for how long, then count everything else in the first screen that asks for attention.

Smaller tiles move more. Shrinking tiles without changing how they move adds motion, because more clips cross the in-view threshold and play at once. Change the size and the motion together, and count the playing clips after every size change.

Cut loops from originals. A clip cut from a finished short video carries its burned-in captions, and its resting still shows them. Cut loops from the original footage, so each clip rests on a clean picture (see Don't stack text on pictures that already carry text).

Example: the owner of a recipe site loved the moving dish clips in the landing hero but found it "so much happening". A fit pass on the live page compared tile sizes, motion modes and pause controls, then the top of the screen. The pick: smaller tiles, each clip plays once for at most five seconds and rests on its still, no pause button, no floating decorations, no reasons line and no caption. The whole dish row and every dish name then fit the first screen at 1440 by 900, where the row had run to 118% of the screen height.

Source: the fit pass of 16 October 2026; the owner delegated the pick. Evidence class: measurement of one site plus owner judgement; the five second threshold is the WCAG criterion's own, not a finding about visitors. It refines "Motion only to confirm" and its exception for own loops above. Learned 16 October 2026.

Session controls stay where the reader looks

Rule: a control the reader needs through a whole session (their part, settings, a timer) lives in the persistent bar they keep in view, not on its own row above the content. Why: a step change scrolls the content under a sticky bar, and a control above the content scrolls away with it, just when the reader needs it. The bar must never fully hide the control that has keyboard focus, so give the scrolling content a top scroll padding as tall as the bar (WCAG 2.2 SC 2.4.11, Level AA; see focus not obscured and Understanding Focus Not Obscured, read 2026-10-29). Quick test: walk every step of the flow at phone and desktop widths and check that each session control stays on screen; then tab through every step and check that each focused control stays at least partly in view.

Example: in a recipe site's cook mode, "Your part" (which part of a shared recipe this cook makes) sat centred on its own row above the steps and disappeared under the top bar on step changes. It now sits in the top bar beside Settings. Learned 15 October 2026 in a fit pass; one site, not user-tested. Relates to Principle 2.

The word first, the mark after it

Rule: an icon that marks an item inside running text goes after the word, slightly smaller and raised like a footnote marker. Why: the reader reads the word first, the mark adds to it without leading, and the line count does not grow. Example: in a recipe site's steps, each item's icon now follows its word. Learned 15 October 2026 in a fit pass; one site, owner judgement, not user-tested.

One picture style per role

Rule: give each role a picture plays one style, and keep that style wherever the role appears. On one recipe site: photographed objects for decoration and states (empty, error), paintings for learning and rewards, line drawing for icons and the map. Why: the reader learns what each style means; a picture in another role's style reads as a different kind of thing. Quick test: list every picture on the site with its role and its style; any role with two styles is a finding.

Decoration follows the layout. Around a centred column, scattered decoration reads lopsided. Give a centred screen one object, placed with the column. Example: that site's error pages now carry one photographed paprika bowl and one handwritten line.

Source: a reviewer comparing the pages with each other in a site coherence pass over every screen, 16 October 2026; the owner delegated the pick. Evidence class: a craft rule from one site, not user-tested. Not yet tested on a second site, which the Research log asks for before any part of the illustration method moves into Principles; treat it as a candidate rule until then. How to choose and keep each style is in the Design review playbook under one style per role. Learned 16 October 2026.

Copy rules learned on one recipe site

Set on 16 October 2026 for one recipe site after a panel of two simulated reviewers (an audience lens and a trust lens). Evidence class: simulated reviewers and owner judgement on one site; not user-tested. Examples come from that site. Product copy belongs to the sibling organization Copy and Messaging Principles (its Principles); these rules are due to move there.