Assets
Inspect repository assets before generating or downloading replacements. Use real product, place, object, person, gameplay, or state imagery when users need to inspect the subject. Avoid dark, blurred, heavily cropped, or atmospheric media in those contexts.
Reserve image dimensions and use explicit aspect ratios. Set meaningful alternative text for informative images and empty alternative text for decoration. Do not repeat adjacent caption text as alt text.
Use generated assets only when the user requests them or no suitable authentic asset exists. Label synthetic examples when they could be mistaken for evidence.
For commerce, catalog, real-estate, portfolio, food, venue, and object-focused pages, the primary media must let users inspect what they are choosing. Prefer authentic photography, supplied renders, or honestly generated product imagery with useful silhouette, material, and detail views. Generic gradients, colored blobs, abstract geometry, icon-scale SVGs, or exploded decorative pieces are not substitutes for a primary product image. If a real or generated subject asset is unavailable, use a clearly labeled placeholder and avoid claims that depend on unseen detail.
Treat primary-media scale as part of art direction. In a hero or major product region, the subject should dominate or create deliberate crop tension. Do not place a small object in a large empty card, then add another frame around it. Replace or regenerate a weak primary asset before spending effort on surrounding decoration.
Image art-direction loop
Before image search or generation, define:
role | concrete subject | environment | camera/angle | light | material/color |
negative space | focal safe area | forbidden details | desktop ratio | mobile treatment
Generate or select the smallest useful asset set. Usually this is one strong primary image plus a mobile-safe alternate only when the first crop cannot preserve the subject. Inspect every result for anatomy, labels, packaging, impossible reflections, accidental text, false product details, and crop safety before writing the surrounding layout. Extract composition decisions from the selected image's real focal point, light direction, palette, texture, and negative space.
Do not ask image generation to fabricate evidence such as real customers, awards, venues, sponsor walls, product screenshots, or documented results. When the generated object represents fictional inventory, keep claims and specifications clearly fictional or supplied by the user.
Build an asset set, not unrelated pictures
Define a compact identity record for each depicted product or subject: source asset, silhouette, proportions, material, color, markings, and details that must remain unchanged. Then define the role of each needed view: hero, catalog, detail, selected variant, or mobile. Generate only views needed for the actual workflow.
When deriving another view, use the approved source as a reference when the tool supports it. Inspect the whole set together for changed packaging, invented labels, inconsistent scale, new features, and mismatched colors. Do not present two different generated objects as the same SKU. A layout comp, an illustrative campaign image, and factual product photography have different evidentiary roles.
Keep human-authored labels, names, prices, and controls in HTML. Do not rely on a generated package label or screenshot to supply correct interface text. For a real product, missing authentic detail is a limitation to disclose, not permission to invent it. Reuse one approved asset with different valid crops when that preserves identity; separate generations are not automatically better.
Deliver the assets
- Store approved assets inside the project, not only in a temporary tool directory. Record origin, rights or synthetic status, and intended use where maintainers can find them.
- Supply appropriate image dimensions and compressed formats supported by the project. Use
srcsetandsizesfor resolution selection; usepicturewith media-specific sources when the composition itself changes. - Make the primary visible image discoverable in the initial HTML. Do not lazy-load the likely Largest Contentful Paint image. Consider
fetchpriority="high"for that image, not the whole gallery. A CSS-background LCP image may need a matching preload; avoid downloading unused alternate crops. - Lazy-load noncritical below-fold images where appropriate. Reserve image dimensions before download so content does not jump.
- Check the loaded asset, failed-image behavior, and narrow crop. Loading success is not evidence of correct subject framing.
See responsive image art direction and LCP image delivery for platform details. Budget assets to the actual page and connection goals; do not add heavyweight media solely to satisfy an aesthetic rule.
Concrete subject evidence
Use the strongest truthful subject signal for the surface. For skills, developer tools, design systems, and creative products, show what the system changes. For events, editorial, venues, and commerce, real program, place, subject, inventory, offer, or availability detail may be the better evidence.
For tools and generators, prefer this proof order:
- a live control or real primary workflow;
- an inspectable output produced by the system;
- a worked before/after or annotated example;
- a truthful code, token, or process artifact;
- decorative brand media only as support.
Do not make visitors infer product quality from prose alone. Generated atmosphere cannot substitute for an actual interface, output, workflow, program, subject, or offer. Do not invent a terminal, dashboard, or interactive artifact when the page's real job is orientation or conversion.
Copy
Use specific action verbs and product language. Avoid vague claims, generic startup language, repeated calls to action, decorative eyebrows on every section, and visible instructions explaining obvious controls.
Replace interchangeable AI language such as reimagine, unlock, elevate, future of, next generation, seamless, or built for everyone unless the surrounding sentence makes a concrete, supportable claim. Prefer nouns the audience uses, actions the interface performs, constraints the product handles, and details that distinguish this offer. Headlines should identify the product, offer, subject, or point of view; supporting copy should explain value rather than repeat the headline in longer form.
Check naming as part of visual QA. Keep brand, product, plan, event, and place names consistent; do not generate near-synonyms between navigation, headings, labels, and actions. Use one primary action phrase for one outcome instead of rotating generic CTA synonyms across the page.
Keep final copy inside the product world. Never expose prompt language, design rationale, or commentary about the landing page, hero, layout, feature grid, generated output, or why a compositional decision was made. Internal reasoning should become brand-facing meaning, not public explanation.
Never fabricate testimonials, customer names, avatars, metrics, awards, integrations, reviews, or usage statistics. Clearly label sample data and placeholders in development surfaces.
When the entire greenfield brief is fictional, disclose that status once in a quiet footer note, page metadata region, development README, or local label beside content that could reasonably be mistaken for evidence. Do not place concept, prototype, demo, fictional, sample, or design-process language in the hero eyebrow, headline, main action, or section narrative merely to satisfy disclosure. Treat product names and prices as sample inventory, and do not present shipping origin, delivery time, return window, stock level, ratings, material specifications, or service promises as real unless supplied. A polished fictional surface still needs an honest content status, but honesty copy should not dominate or break immersion.
Forms
Use visible labels, suitable input types, autocomplete tokens, inline validation, and error summaries for long forms. Preserve entered values after validation errors. Confirm destructive or irreversible actions at the right moment without adding confirmation to routine reversible actions.
Tables and dense data
Use tables when row and column comparison matters. Keep headers associated, numeric alignment consistent, units visible, and controls reachable by keyboard. On small screens, preserve comparison through horizontal scrolling with clear affordance or an alternate view; do not turn every table into disconnected cards.
Charts
Select charts by the question: trend, comparison, distribution, relationship, part-to-whole, or flow. Include text equivalents, labels, units, and non-color distinctions. Avoid 3D effects and decorative complexity that distort values.
States
Differentiate first-use empty, filtered-empty, permission-empty, loading, partial-data, stale-data, error, and offline states when the product can encounter them. Each state should explain the situation and offer the next useful action.