Worked examples: Website design decisions and their limits

Purpose: teach application and judgment, not a house style. Prepared on 13 September 2026. These are original, fictional teaching cases with text exhibits and linked first-party references. They are not screenshots of audited products, shipped components, usability-test observations, or measured improvements. All fixture names, dates, quantities, and copy are invented. The principles remain owned by Principles.

How to use: choose the case matching the task, inspect the proposed decision, and read its counterexample before applying it. Keep evidence labels separate: illustrative means a reasoned teaching example; implementation-tested requires a recorded runtime check; user-observed requires a recorded participant observation. One label does not imply the others. None of these cases has yet received the latter two labels.

E1. Cards for discovery, rows for comparison

Situation: a team member must find resources available before a given date. The fictional data below is identical in both alternatives. The weak starting design is a gallery with large cover art, title at the top, and date and availability scattered at the bottom of each card.

Proposed change: for the comparison task, align the attributes in a table with meaningful headings. Put the relevant date and availability in consistent positions. Offer sorting only when the task needs it. The annotation is not 'cards are bad'; it is 'the deciding attribute should be easy to compare.' GOV.UK recommends tables for row-and-column comparison. Source: Table, read 2026-09-13; practitioner pattern, not a measured uplift for this fixture.

Counterexample: selecting an unfamiliar visual subject for inspiration may benefit from imagery and short descriptions. The card view can be preferable for that task. Do not add a table toggle unless both tasks warrant it.

Check: ask someone to identify which workshops are available before 15 October, then ask a separate discovery question. Record errors and effort separately. On a narrow view, preserve each value's label and necessary comparison rather than simply hide the date. Expected comparison answer for the fixture: Cedar.

E2. A form that remains understandable after typing

Situation: two inputs use only placeholders: 'Contact email' and 'Project name'. After entry, the view shows only 'sam@example.test' and 'Winter collection'. A returning reviewer must reconstruct what each value means.

Proposed exhibit: keep a persistent 'Contact email' label over the email field and 'Project name' over the project field. Place any necessary explanation outside the placeholder. Preserve the labels when values exist, when the fields have errors, and at larger text sizes. GOV.UK explicitly rejects placeholders as substitutes for labels or essential hints. Source: Text input, read 2026-09-13.

Counterexample: some immediately recognizable controls can use a visually hidden label. They still need an accessible name, and the surrounding design must make the purpose clear. This is not permission to remove labels from an ordinary multi-field form. Source: GOV.UK says every text input needs a label, visible in most cases (text input, read 2026-10-29); the hidden-label exception is our reading.

Check: review the populated form after navigating away and back. Ask which address will receive the result. Inspect accessible names and label activation in the implemented version. Do not give an empty-state screenshot credit for passing the populated-state test.

E3. Choose a validation trigger, not a universal slogan

Situation: an email field shows an error as soon as the person types its first character. A separate confirmation field can retain an old mismatch message even after its related value changes.

Two candidate designs: A checks when the person continues or submits and returns preserved values plus locatable errors. B waits until a value is plausibly complete or the person leaves the field, then gives inline feedback; once an error exists, correction updates the message. Both need final validation and a usable error path. These are alternatives to test, not cumulative requirements.

Evidence: GOV.UK says to wait for continue or submit and not to validate when a person leaves a field; it allows checking during entry only when user research shows that helps on balance, with its character count as the example. Baymard's commerce testing recommends checking when the person leaves the field. Candidate B follows Baymard and departs from GOV.UK. This is an existing source tension, not a newly resolved rule. Sources: GOV.UK validation and Baymard inline validation, read 2026-10-29. Use the recorded conflict when choosing.

Counterexample: useful feedback about a character limit can belong during entry. Treating every early message as harmful would be another overgeneralization. Source: GOV.UK names its character count as the exception to validating on submit (validation pattern, read 2026-10-29).

Check: type slowly, paste a valid address, submit an invalid address, correct the related confirmation value, and navigate with a keyboard. Record interruptions and correction success. A green check can establish only the validation performed, not ownership or deliverability of an email address.

E4. The same tabs, two latency conditions

Situation: 'Overview', 'History', and 'Files' look like one stable tab set. In one implementation all panels are ready locally; in another each selection waits for remote content.

Proposed behavior: automatic activation is the recommended default when focus changes reveal panels without noticeable delay. With delayed content, use manual activation so arrow-key exploration does not demand loading every intermediate panel. Focus and active selection remain visually distinguishable. Source: W3C APG tabs, read 2026-10-29; informative interaction guidance.

Counterexample: destinations on different pages may be navigation links rather than tabs. Do not import tab semantics because the visual shape is convenient. Also avoid imposing a universal millisecond number on the source's context-sensitive condition.

Check: from the active tab, use arrows, then Enter or Space for manual activation. Record focus, selected panel, and waiting state. Test with delayed responses as well as cached content. This document has not executed that test. The manual-tabs example, read 2026-10-29, says its code is not intended for production; treat it as illustrative source code.

E5. A dialog includes its return path

Situation: 'Edit project name' opens a visually polished modal. Its name field and Save and Cancel controls look correct, but a screenshot cannot show where keyboard focus starts or ends.

Proposed contract: choose initial focus for this short editing task, contain Tab navigation within the modal while open, provide dismissal, and return focus to the invoking control or an appropriate successor. In this fictional design, Cancel leaves the stored name unchanged; successful Save updates the visible name and announces the result appropriately. The save semantics are fixture assumptions, not APG guarantees. Source: W3C APG modal dialog, read 2026-09-13.

Counterexample: a long explanatory dialog may need initial focus on readable introductory content, not its first action. An inline edit may be more suitable than a modal for a small, frequent change. Source for the focus point: APG advises focusing a static element at the top when a dialog's content is long (modal dialog pattern, read 2026-10-29). The inline edit point is our judgement.

Check: open by keyboard, inspect initial focus, cycle forward and backward, dismiss, and reopen. Test successful save and validation failure. Record the actual focused element and preserved values, not only whether an overlay appeared.

E6. Receipt is not completion

Situation: uploading a file immediately triggers 'All done', even though processing continues. The later list can show no result or a failed import.

Proposed state copy for the fictional workflow: 'File received. Processing has not finished.' Then either 'Import complete: 12 records available' or 'Processing failed. Your original file is still available.' The number and file retention are explicit fixture assumptions. An implementation may use that copy only when its receipts prove those facts. Show a stable result location and a useful next step.

Why: the distinction follows the existing state principle. Fast input feedback is not complete remote work; web.dev explicitly separates INP's next-paint interval from eventual asynchronous work. Sources: truthful state principle and INP, read 2026-09-13.

Counterexample: a truly local, completed edit may need only a brief confirmation. Do not make every action a multi-stage dashboard.

Check: cover receipt, pending processing, failure, completion, and return to the page. If the final outcome is unknown, show that uncertainty rather than confidently claim failure or success. Verify that the proposed retry does not duplicate already completed work before exposing it.

E7. Responsive design preserves relationships

Situation: a content card has a fixed height that fits a short English title. A longer title wraps over its date and action. At larger text sizes the action disappears.

Proposed change: let text determine the required block height, keep supporting details with their title, and move secondary information only when its relationship remains clear. Test a short title and the fictional longer title 'Planning the next community workshop with several independent contributors'. No specific height, line limit, or breakpoint is prescribed by this example.

Source boundary: WCAG's reflow and text-spacing criteria require retained information and functionality in their specified conditions. Necessary two-dimensional content has defined exceptions. Text-spacing test values are user overrides, not mandatory default typography. Sources: Reflow and Text spacing, read 2026-09-13.

Counterexample: a data comparison may legitimately need horizontal movement inside a bounded region. That does not justify horizontal scrolling for the entire reading page.

Check: inspect at a narrow equivalent width, zoom, text overrides, long labels, and both empty and populated descriptions. Note lost information and obscured controls. A 'mobile' screenshot at one favorable width is not enough.

E8. Three compositions for the same content

Fixed fictional content: three items titled Aster, Birch, and Cedar, each with a description, date, status, and 'Open' action. The product voice and palette are held constant. Only composition changes. These are textual layout specifications, not rendered mockups or preference-test results.

Reasoning: hierarchy, contrast, and grouping can express different priorities. This is our application of visual-design guidance, not a finding that one composition is universally superior. Source: NN/g visual design principles, read 2026-09-13. Choose the composition per surface and task. Across a site, the items inside it keep their kind's single card and row anatomy (One presentation per kind of thing).

Counterexample and check: do not pick Discovery for a known comparison task merely because it looks more expressive. Give the same content and concrete tasks to reviewers. Record which information they notice, whether they understand the item, and whether they can perform the task. Assess aesthetic impression separately. When actual mockups or recordings are created, attach them with their date, version, annotations, and evidence status rather than silently upgrading these text exhibits.

Extending this library from real work

Add a case only when it teaches a distinct decision or changes an existing one. Record the task and context, original artifact and version, observed problem or explicit hypothesis, proposed change, counterexample, source, and verification. Obtain authority before sharing private product examples beyond their current audience. Keep product-specific brand decisions with the product. Update the existing case when evidence changes its recommendation; append the historical finding to Research log. Do not count more examples as proof that an agent improved.