Wireframes

Wireframes test the organization of an interface before visual finish makes changes feel expensive.

Single-artifact evidence

Can the structure be judged before the surface is finished?

Open complete artifact

Hierarchy

The release decision and blockers dominate the page.

Boundary

Primary and supporting actions remain visibly separate.

Reflow

The same content order survives at a narrow viewport.

Use them for

• content hierarchy and information density;
• navigation and page structure;
• responsive reflow;
• alternative layouts;
• the order and grouping of controls;
• the boundary between primary and supporting actions.

Keep them intentionally unfinished

A useful wireframe looks deliberate without looking final. Use a restrained palette, clear type hierarchy, visible boundaries, and realistic content. Avoid branded polish that causes reviewers to debate the surface instead of the structure.

Make alternatives genuinely different

Changing only padding or card order does not produce a meaningful alternative. Explore different organizing ideas: an index versus a guided path, a split view versus a focused canvas, or a persistent control rail versus contextual actions.

Review questions

• Can a person tell what the page is for within seconds?
• Is the primary action obvious without being isolated from its context?
• Does the hierarchy survive at narrow widths?
• What can be removed before more detail is added?
• Are the alternatives testing different structural hypotheses?

Test behavior nextBuild a prototype when static structure cannot answer the question.