Wireframe

Produce low-fidelity wireframes or storyboards to explore a flow, layout, or
information hierarchy before committing to hi-fi design. Wireframes are
disposable — their value is the breadth of options and the decision they
produce, not the fidelity of any one artifact.

When to use

• The user wants to "explore options", "sketch something out", "see a few
  directions" for a screen, flow, navigation pattern, or hierarchy.
• The design problem is open enough that hi-fi work would be wasted — the
  structure question is not yet settled.

When NOT to use: styled, production-viable alternatives on a settled
structure → `design-variations` (hi-fi,
branded, recommendation-bearing). A single refined implementation →
`fe-design` + stack executor.

Procedure

1. Confirm the goal. What is explored (screen / multi-screen flow /
   navigation / hierarchy / interaction model), the imagined user's goal,
   constraints (mobile/desktop, non-negotiable elements), the count
   (3 minimum, 5–6 ceiling), and the axis of variation. If the axis is
   open, propose 2–3 (e.g. single-page form vs multi-step wizard vs
   progressive disclosure) and ask which to explore.
2. Hold the lo-fi conventions so the output reads as wireframe, not as
   broken hi-fi:
   • greyscale only — black, white, 2–3 grays; no brand color;
   • system sans-serif — no type personality yet;
   • labeled boxes for content areas ("headline", "image", "feature card");
   • striped placeholders with monospace size labels for imagery (the
     honest-placeholder pattern in
     `fe-design § Craft details`);
   • short label-style skeleton copy ("Headline goes here / one sentence on
     the value prop") — never Lorem ipsum (per output-discipline), never
     final copy.
3. Sketch ≥3 variations on the named axis — layout (centered / split /
   grid), information density, flow structure (single page / multi-step /
   progressive disclosure), CTA placement, navigation pattern. Write each
   variation's distinguishing structure down BEFORE sketching it — left
   unspecified, variations converge on near-identical layouts. Order
   by-the-book → off-distribution; at least one genuinely novel bet.
4. Annotate — 2–4 numbered callouts per variation naming what is
   interesting and its trade-off ("fastest path, but heavy first
   impression"), placed next to the variation, not in a separate doc.
5. Capture the decision after the user picks: chosen variation (or
   hybrid), what attracted them, what they explicitly rejected, new
   constraints surfaced. This capture is the brief for the hi-fi follow-up.
6. Hand off — `design-variations` for
   styled options on the chosen structure, or
   `design-intelligence` +
   `fe-design` for a single hi-fi direction. In an
   existing codebase the hi-fi step still passes existing-ui-audit per the
   ui-audit-gate rule.

Output format

1. One file (HTML or annotated markdown/SVG canvas) with ≥3 greyscale
   variations side-by-side — flows as small storyboards (3–5 screens each);
   no brand color, no styled typography, no real imagery.
2. Per-variation annotations — 2–4 callouts naming the structural bet and
   its trade-off, inline next to the variation.
3. Decision-capture block (after user pick) — chosen direction,
   attractions, explicit rejections, new constraints; framed as the hi-fi
   brief.
4. No recommendation ranking — wireframes surface trade-offs; the pick
   belongs to the user (contrast: design-variations closes with a
   recommendation).

Do NOT

• Do NOT apply brand color, brand type, or real imagery — that pulls focus to
  aesthetics before structure is settled.
• Do NOT polish — wireframes are disposable thinking artifacts.
• Do NOT write final copy or Lorem ipsum — label-style skeleton copy only.
• Do NOT let variations converge — write each variation's structure down
  before sketching.
• Do NOT skip decision capture — an exploration round without a recorded
  decision has to be re-litigated in the hi-fi round.
• Do NOT embed system internals (paths, skill/tool names) in the artifact —
  Q13 in `design-antipatterns.md`.

Gotcha

• This is the one context where rough, hand-drawn-feeling shapes (rectangles,
  lines, simple icons) are acceptable — everything sits at the same low
  fidelity, so nothing reads as a failed asset (the V4/imagery antipatterns
  apply to hi-fi, not here).
• The wireframe file tends to get promoted into hi-fi by incremental edits —
  don't. Start the hi-fi artifact fresh from the decision capture; the
  wireframe's greyscale skeleton hard-codes non-decisions.

See also

• `design-variations` — hi-fi options on the chosen structure.
• `design-intelligence` — grounded direction selection for the hi-fi follow-up.
• `fe-design` — production heuristics + honest-placeholder pattern.
• `existing-ui-audit` — mandatory pre-step once hi-fi work lands in a codebase.