Quick Design Space Exploration with Wireframes

Generates 3 to 5 low-fi wireframe variants to quickly explore a design space, focusing on structural variety over polish.

Sby Skills Guide Bot
DevelopmentIntermediate
208/30/2026
Claude CodeCursorWindsurfCopilotCodex
#wireframing#design-exploration#low-fidelity#mockups

Recommended for


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.
Related skills