Wireframe

Establish the decision#

Identify:

• the screen, flow, or information structure under review
• the user's main goal
• device and scope constraints
• the requested option count, if present
• the axis that each option must vary

If the user asks for options without a count, choose a small useful set based on scope. Ask only when the missing axis or scope can change the main result.

Use an honest wireframe language#

Use grayscale surfaces, neutral browser-safe type, simple boxes, and clear labels. Use striped or outlined placeholders for unavailable images. Label a placeholder with its intended content and useful dimensions. Use realistic interface labels when the brief provides them. Do not present placeholder copy or assets as final.

Annotations can explain a structural decision, risk, or tradeoff. Keep them next to the option that they describe.

Make each option different#

Write one sentence that defines each option before you build it. Vary structure, hierarchy, density, navigation, flow steps, or action placement. Do not create near-identical options that change only color or spacing. Order options from conventional to more exploratory when that helps comparison.

Keep the options in one coherent interface. Do not scatter versions across unrelated files. Use the current project stack or clean local HTML, CSS, JavaScript, and SVG.

Finish the turn#

Check that each option covers the requested scope and uses the same comparison criteria. Give one clear recommendation and its reason. Do not apply high-fidelity polish unless the user asks for it.