Web Design Prompts
What prompt turns a page request into an evidence-led production contract?
A useful production prompt fixes the reader contract and the evidence boundary, not a fashionable aesthetic. Use this specification to turn an uncertain page request into a rendered, measured interface.
Establish the contract
Do not start with colours or animation. Collect the smallest evidence that determines the page:
Buyer:
Situation that brought them here:
Valuable action the page should make easier:
Proof available publicly:
Claims that must not be made:
Existing design memory, tokens, components, routes, and analytics:
Constraints: framework, accessibility, performance, privacy, deadline:
If the buyer, action, or proof is unknown, produce a diagnostic or content brief—not a polished landing page.
Changes my mind: A fixed aesthetic produces clearer buyer recognition and stronger evidence than the contract-and-review loop across comparable page briefs.
Copyable production specification
# Evidence-led web page
## Outcome
Build or revise [route] for [buyer in situation].
The primary action is [one observable action].
The page succeeds when [reader evidence and technical evidence].
## Truth boundary
Demonstrated proof: [public sources].
Supported inference: [bounded inference].
Unknown: [open evidence].
Remove unsupported outcomes, invented customers, fake metrics, and placeholder proof.
## Design-memory intake
Read before changing code:
- [design.md / design system / tokens]
- [existing components and nearest comparable pages]
- [content or product brief]
- [analytics contract]
Preserve the established logo, type, tokens, and primitives unless evidence
shows that one blocks the reader action.
## First-impression contract
Within the first viewport, make clear:
1. who the page serves;
2. what valuable change is offered;
3. what the visitor should do next;
4. why that action is credible and bounded.
Do not let polish compensate for an unclear buyer, value, or next action.
## Composition
Work mobile first. Define the content sequence before styling.
At 320, 375, 768, and 1440px specify:
- reading order and grouping;
- primary and secondary actions;
- navigation behaviour;
- text measure and type sizes;
- how diagrams, labels, tables, and cards reflow.
Use semantic HTML for text, controls, steps, and comparisons. Use SVG only
when geometry carries meaning. Use raster imagery only for an editorial need
that does not depend on embedded text.
## Anti-slop constraints
- No invented testimonials, numbers, outcomes, urgency, or decorative dashboards.
- No generated image may carry critical copy, controls, diagrams, or proof.
- No visual earns space only because it looks impressive.
- No hover-only meaning, hidden mobile action, empty outlined button, clipped
label, overlapping SVG, or animation without reduced-motion behaviour.
- Reuse primitives and semantic tokens before creating page-local variants.
## Build
Implement the smallest complete page. Keep content in logical DOM order.
Give every action an accessible name and visible focus state. Add responsive
image dimensions and budgets when imagery is justified. Preserve existing
analytics and add only named events tied to the reader action.
## Render, measure, critique
Render the whole page and first viewport at 320, 375, 768, and 1440px.
Check:
- no horizontal overflow, clipping, overlap, blank control, or unreadable text;
- body >=16px, captions >=14px, eyebrow/metadata >=12px;
- contrast, keyboard order, touch targets, accessible names, reduced motion;
- the primary choice works without hover;
- diagrams have an equivalent explanation;
- page weight and Core Web Vitals do not regress.
Critique against the contract, not aesthetic adjectives. Record expected versus
observed behaviour, change one bounded cause, and render again.
## Stop conditions
Stop when the buyer, value, proof boundary, and next action are clear; all
viewport and accessibility gates pass; no remaining visual has an unnamed job;
and another iteration would not change comprehension, trust, action, safety,
or navigation.
Do not claim conversion or performance improvement without comparable evidence.
Review sequence
contract → content sequence → visual-medium choice → assemble
→ landing-page audit → legibility audit → measured correction → browser dogfood
The prompt is not permission to bypass judgment. A human remains responsible for the buyer promise, evidence boundary, and irreversible publishing choices.
Continue the review
- Visual Prompting — choose HTML/SVG, raster, or video and apply its rejection gates.
- Product Design — use the design authority and measurable thresholds.
- Audit a Page — render and inspect the interface in four passes.
- Review a Landing Page — test the first-impression and action contract.
Failure Modes
- Aesthetic-first output — the page looks resolved while buyer, value, or action remains unclear.
- Proof stretching — polish gives an unsupported claim more confidence than its evidence permits.
- One-viewport approval — desktop polish hides mobile clipping, labels, or actions.
- Iteration without a stop — taste feedback expands scope without changing comprehension.
Context
- Prompting — structure intentions as usable inputs
- Visual Prompting — choose the least complex adequate medium
- Product Design — measurable production thresholds
- Performance — compare observed output with the frozen expectation
Questions
What evidence would make the next production iteration unnecessary?
Next question: Which observed reader or rendering failure now owns the smallest correction?