wireframe
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.
- Category
- Prototyping
- Status
- Experimental · Recommended
- Use when
- explore the design space
- rough wireframes
- low-fi wireframe options
- sketch some layout ideas
- give me a few structurally different layouts
- Works on
- a feature or screen description
- an existing product/problem context to riff on
- Produces
- a set of 3-5 structurally distinct low-fidelity HTML wireframes laid out for side-by-side comparison, with plain-language section labels and interaction annotations
- Works with
- Claude Code, Codex, Cursor, OpenCode, Amp, Gemini CLI, GitHub Copilot, VS Code, Claude.ai
- Tags
- wireframing, low-fidelity, ui-design, interaction-design, prototyping
- Source
- manalkaff/opendesign by manalkaff · MIT · adapted for this repository
- Related skills
- wireframe-jsonprototypeinteractive-prototype
Instructions from SKILL.md
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.
Supporting files
One more file in this skill's folder. Markdown opens as a page, other text files open as source, and anything else downloads as it is.