Wireframe Design

This skill equips you to produce a low-fidelity wireframe — a breadboard mockup of any client-app UI, mobile or web/desktop. Reach for it to sketch a screen, breadboard a flow in words, connect screens into a wireflow, compare layout options, or run the wireframe round of a design review. It owns a project-agnostic breadboard vocabulary: two device canvases (a mobile phone frame and a browser window), the breadboard primitives, the component library, the archetypes, the annotation and wireflow layer, and the options-comparison layout — regions, hierarchy, and flow, never brand color or final type.

High-fidelity (real-token) mockups — rendering a chosen design with real brand color, type, spacing, and density — are a separate activity this skill does not cover; if the project has a skill for high-fidelity or visual UI design, defer to it for that round. When this skill runs inside a broader design-review or delivery workflow, that workflow owns how option rounds, the recommended marker, and any recording are handled; the general page craft of the surrounding page (its own typography, palette, and spacing rhythm) follows your host's page-craft guidance, when it has any.

The kit is wireframe-kit.html — a self-contained, theme-aware page carrying the two device canvases, the breadboard component library, the archetypes, the breadboard/wireflow/annotation layer, and the options-comparison layout. Copy it to a scratch location, delete the parts you are not presenting, fill it for the screen(s) at hand, then render, export, or publish the result — and validate it with the bundled check-wireframe.mjs before presenting.

The normative rules below are grounded in the external field consensus distilled in this skill's Research-Grounded Best Practices references (the routing section at the end of this document) — 18 principles across five topic files, each expanded with reasoning, do/don't examples, and citations to reputable sources (Nielsen Norman Group, the Interaction Design Foundation, Smashing Magazine, Basecamp's Shape Up, platform design systems). The MUST/SHOULD rules in this document are authoritative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Choosing the Artifact

Low fidelity is not one artifact — pick the cheapest one that answers the open question. Reach for the HTML kit only when the question is about a screen's regions and hierarchy; when the question is a flow's steps, breadboard it in words first, and when the 2D arrangement is the question, a fat-marker sketch beats any tool.