Generate Distinct Web Design Directions Without Losing the Business Brief

AI can generate an attractive homepage before it understands what the company sells. That is not a design process. It is a fast way to attach polish to assumptions.

The intended reader is a founder, designer, or developer who already has a verified offer, audience, evidence boundary, and website handoff brief. The outcome is three genuinely different webpage directions, tested with the same real content and judged against the same criteria. It does not replace user research, brand strategy, accessibility testing, or professional design review. Source review: 24 August 2026.

Begin with one controlled brief

Use the website handoff from the evidence-first company launch workflow. If the offer, audience, or permitted claims are still vague, pause. More concepts will multiply the ambiguity.

Prepare one source packet for every design direction:

• primary visitor and the situation that brought them to the page,
• one primary action and any necessary secondary action,
• verified offer, exclusions, price information, and availability,
• publishable proof and claims you must not make,
• required pages, content owners, and legal information,
• real draft copy, including difficult long headings and error messages,
• accessibility, language, device, performance, and technology constraints,
• existing brand assets and explicit rules for using them.

Do not give one concept richer copy or stronger evidence than another. You are comparing design decisions, not allowing the model to make one option win by inventing a better business.

Define difference before generating anything

“Make three versions” often returns the same hero, three feature cards, testimonial strip, and call to action with different colors. Avoid this by defining directions through structural variables.

Each direction should make a different, defensible choice about:

1. Information hierarchy: what the visitor learns first and what can wait.
2. Content density: concise scanning, editorial explanation, or guided sequence.
3. Navigation: a short linear path, a service index, or progressive disclosure.
4. Typography: hierarchy, line length, scale, and reading rhythm, not just a font name.
5. Imagery: documentary evidence, product interface, diagrams, or no decorative imagery.
6. Interaction: mostly static reading, comparison controls, or task-focused steps.
7. Trust model: process transparency, demonstrable artifacts, founder credentials, or verifiable customer evidence.

A useful set for a new service company might be:

• Direct offer: a compact page that states the customer, result, boundaries, and next step immediately.
• Evidence-led editorial: a calmer, text-led page that explains the problem, method, artifacts, and limits before asking for contact.
• Guided diagnostic: a task-oriented page that helps a visitor identify fit and reach the correct next action.

These are not style labels such as “minimal,” “premium,” or “futuristic.” They describe how the page helps a person understand and decide.

Build a content model first

Before drawing layouts, list the reusable content objects. A simple service website may need an offer, audience, problem, deliverable, exclusion, process step, proof item, frequently asked question, contact method, and policy link. Give every object a source and owner.

Then place those objects into a content outline for each direction. For example, the direct-offer direction may lead with offer and fit; the editorial direction may lead with the observed problem and method; the diagnostic direction may lead with a short decision path. All three still use the same verified facts.

Use real draft copy early. Lorem ipsum conceals whether a layout survives an honest explanation, a long company name, a multilingual label, or a qualified claim. Real copy also reveals when the concept depends on unsupported social proof.

AI can help normalize the source packet into structured content, but require traceability:

Convert the supplied website brief into a content inventory.
For each item return: stable ID, content type, exact source text,
page purpose, owner, evidence reference, and status.
Do not create testimonials, customers, metrics, certifications, prices,
team members, policies, or claims. Mark missing material as MISSING.

Generate design specifications, not mood-board prose

Ask for a written specification before code or images. This makes differences inspectable and reduces random visual drift.

Create three webpage directions from the attached brief and content inventory.
They must differ in information hierarchy, density, navigation, typography,
imagery strategy, interaction, and trust model, not only color or decoration.

For each direction provide:
1. design premise and visitor decision,
2. ordered page sections with content IDs,
3. responsive layout behavior,
4. type scale and spacing logic,
5. component inventory and states,
6. image purpose and accessibility treatment,
7. interaction and motion rules,
8. expected implementation risks,
9. claims or assets still missing,
10. reasons to reject the direction.

Use only supplied facts and assets. Do not imitate a named living designer,
agency, product, or brand. Do not hide missing proof with generic copy.

References are useful when you describe the relevant property. “Use this example’s narrow reading measure and visible hierarchy” is actionable. “Make it look like this brand” invites imitation without understanding. The workflow in visual references without style theft helps separate a useful design property from copied identity.

Prototype in isolation

Give every direction its own route, folder, branch, or disposable prototype. Share only the content inventory and deliberate foundation tokens. If all variants reuse the first generated component tree, later concepts tend to become skins of the first.

Start with low-cost artifacts:

• content outline,
• grayscale wireframe,
• type and spacing specimen,
• desktop and narrow-screen composition,
• one difficult component in all necessary states.

Generate polished code only after those artifacts show a meaningful difference. Preserve each version when iterating. Keep the chosen direction stable while testing variants, or feedback such as “make it clearer” will slowly merge all concepts into an untraceable average.

For code prototypes, define the expected semantics and states in the prompt. A navigation menu is not just a row of links. It has keyboard behavior, focus visibility, a mobile state, an active state, and a meaningful accessible name. A contact form needs labels, instructions, validation, success, failure, and privacy context.

Make accessibility part of the direction

Accessibility is not a cleanup task after choosing the most dramatic concept. It affects hierarchy, interaction, typography, motion, color, media, and content from the first sketch. The W3C accessibility planning guidance recommends integrating accessibility throughout a project, and the W3C accessibility principles explain the relationship between perceivable, operable, understandable, and robust experiences.

Require each direction to show:

• a logical heading and landmark structure,
• keyboard access and visible focus,
• labels and instructions that do not depend on position or color alone,
• text alternatives based on an image’s purpose,
• sufficient contrast for text and meaningful controls,
• readable line length and zoom behavior,
• reduced-motion behavior,
• error identification and recovery,
• a sensible reading order when layout changes.

Semantic HTML provides useful behavior before custom scripting. MDN’s guide to HTML accessibility explains why using the correct element is usually a better starting point than recreating its semantics. Use the WCAG 2.2 quick reference to inspect relevant success criteria, but do not treat automated checks or a generated checklist as proof of conformance.

Test with a keyboard, browser zoom, a screen reader where possible, and real people. A model cannot certify accessibility from a screenshot.

Make responsive behavior explicit

Do not request standard desktop, tablet, and mobile versions and assume the gaps work. Responsive design is a set of flexible layout practices, not three frozen canvases.

Resize prototypes continuously. Add a breakpoint when content or interaction stops working, not because a popular device width appeared in a template. Check long headings, navigation wrapping, form controls, tables, diagrams, tap targets, image crops, and content order. Specify what collapses, wraps, scrolls, moves, or disappears and why.

If the website will be translated, test representative longer strings now. Truncating a label or reducing all text to fit is not a localization strategy.

Evaluate with one scorecard

Review each direction against the same evidence. A practical scorecard can use a short written rating with supporting observations for these dimensions:

Performance belongs in design review. The current Core Web Vitals focus on loading, interaction responsiveness, and visual stability, but a good design direction should also work before you have field data. Record asset budgets, font choices, likely script cost, layout-shift risks, and what can use plain HTML and CSS. Do not promise a score before measuring the built page.

Use AI to summarize observations only after humans have recorded them. Do not ask it to choose the winner from screenshots. It does not know which compromises the business and its users can accept.

Record the decision and the rejected alternatives

Select a direction, then write a short decision record:

• chosen direction and date,
• people involved,
• evidence reviewed,
• strengths worth preserving,
• known risks and unresolved questions,
• elements explicitly rejected,
• next prototype or user test,
• conditions that would reopen the decision.

You may combine a specific element from another direction, but name the reason and re-evaluate the result. Combining every preferred fragment usually destroys the original hierarchy.

The deliverable is not three beautiful screenshots. It is one selected system with a traceable content model, responsive rules, accessible behavior, implementation constraints, and an honest record of why it fits the company brief. That is enough direction to build the static website without asking a coding agent to rediscover the business through visual guesswork.