← Go Back

Wireframing

What is wireframing?

Wireframing is the activity of creating wireframes: simple, low-fidelity layouts that show structure, content placement, and hierarchy without detailed visual design. You wireframe to explore and agree on “what goes where” before committing to visuals or code.

Use it when: you’re defining a new screen or flow and need to iterate quickly on structure and information architecture without getting stuck on colour or copy.

Copy/paste checklist (one screen)

  • [ ] Content areas – where blocks of content and key UI sit.
  • [ ] Navigation – how users move (menus, links, tabs).
  • [ ] Primary actions – the one or two actions that matter for this screen.
  • [ ] Hierarchy – what’s primary vs secondary (size/placement).
  • [ ] Annotations (if needed) – behaviour, constraints, or open questions.

Use boxes, lines, and placeholders; avoid final visuals. See Wireframe for the artefact.

Why wireframing matters

  • Focuses the team on structure and flow instead of aesthetics.
  • Speeds iteration because changes are cheap.
  • Surfaces missing or misplaced elements early.
  • Gives developers a clear structural brief before high-fidelity design.

What good wireframing includes

Checklist

  • [ ] One purpose per round – e.g. “homepage layout” or “checkout steps”; don’t try to show everything.
  • [ ] Clear hierarchy – primary vs secondary content and actions visible.
  • [ ] Reasonable realism – approximate content length so layout is testable.
  • [ ] Consistent with system – if you have patterns or a grid, use them.
  • [ ] No final visuals – keep it clearly a draft so feedback stays on structure.

Common formats

  • Low-fidelity: Sketches or simple boxes. Use for exploration and early alignment.
  • Mid-fidelity: Digital, with spacing and placeholders. Use for internal review and as a base for prototypes.

Examples

Example (the realistic one)

You’re wireframing a settings page. You draw: top bar (back + “Settings”), then grouped sections (Profile, Notifications, Privacy), each with a heading and 2–4 rows (label + control or link), one primary button at the bottom. Placeholder text only. You share with the team, get feedback on order and grouping, then turn the agreed structure into a prototype or high-fidelity design.

Common pitfalls

  • Too much detail too soon: wireframe looks like a final mock. → Do this instead: keep it rough; add visual detail only when structure is agreed.
  • No hierarchy: everything looks equally important. → Do this instead: use size, spacing, and grouping to show what’s primary.
  • Skipping wireframing: going straight to high-fidelity. → Do this instead: use wireframes when the main risk is structure and flow; they save time and focus feedback.
  • Wireframing vs wireframe: wireframing is the process; a wireframe is the output.
  • Wireframing vs prototyping: prototyping adds interaction; wireframing is usually static structure. Wireframes often become the basis of a prototype.
  • Wireframing vs mockup: a mockup is high-fidelity and visual; wireframing produces low-fidelity structure. Wireframe first, then mockup.

Next step

Pick one screen or flow and create a low-fidelity wireframe (paper or digital). Get feedback on structure, then turn it into a prototype if you need to test the flow. Read Wireframe for the full checklist.

Related Terms