wireframe

name	wireframe
description	Use when the user wants to explore the design space quickly — many rough ideas, not one polished direction. Low-fi, handwritten-font sketches; 3–5 structurally distinct options per idea, not recolors.

Loaded when the user wants to explore the design space quickly — many rough ideas, not one polished direction.

Output location

Write all output files to ./opendesign/mockups/<task-slug>/. Derive the slug from the task name (e.g. dashboard-redesign, onboarding-flow).

Role framing

The goal is breadth, not polish. The output is a map of the design space, not a finished artifact. Use this skill early in a project, before the user has committed to a direction.

Interview the user first to understand the problem, then generate multiple rough takes in one pass.

Quantity and spread

• Produce 3 to 5 distinctly different approaches per idea. "Distinct" means different structural logic, not different colors of the same layout. If two wireframes could be swapped by changing a class, they are the same wireframe.
• Lay options out side by side so the user can compare them in one glance. For small sets, use a single canvas. For larger sets, use tabbed or paginated groupings so the comparison stays readable.

Visual style

• Low-fidelity, sketchy vibe. Handwritten-but-readable fonts (e.g. Caveat, Patrick Hand, Shadows Into Light, Kalam).
• Mostly black and white. Sparing color accents only to call out active or emphasized elements.
• Simple shapes: rectangles, lines, circles. No real imagery, no real icons. Placeholder text is fine and expected.
• No polished typography. No real brand colors. No hover states. These are thinking aids, not mockups.

Structure of each wireframe

• Focus on layout and flow. Where things sit, what reads as primary, what sequence the user moves through.
• Label sections clearly in plain language ("search bar", "filters", "results list", "primary action") so the user can discuss them without pointing.
• When a wireframe implies an interaction, annotate it with a short note. Do not implement it.

Tweaks and iteration

• Expose a small set of simple tweaks: toggle between variants, change density, swap an optional section in or out. Keep the tweak surface minimal. Wireframes should not compete with prototypes for fidelity.

What to avoid

• Do not polish a wireframe. If the user likes one, the next step is a separate higher-fidelity pass — not sanding down the sketch.
• Do not let wireframes converge visually. If five options all look the same, you have one option, not five.