← Go Back

Wireframe

What is a wireframe?

A wireframe is a simple, low-fidelity sketch of a screen or flow that shows where content and UI elements go and how they’re structured. It has little or no visual design (colour, typography, imagery); it’s about layout, hierarchy, and behaviour.

Use it when: you’re defining structure and flow before committing to visual design or code. Wireframes help you iterate quickly and get alignment on “what goes where” without distraction.

Copy/paste checklist (one screen)

  • [ ] Content areas – where blocks of text, media, or data sit.
  • [ ] Navigation – how users move (menus, links, tabs).
  • [ ] Key actions – buttons, links, or controls that matter for the flow.
  • [ ] Hierarchy – what’s primary vs secondary (size/placement, not final styling).
  • [ ] Annotations (if needed) – behaviour, constraints, or open questions.

Use boxes, lines, and placeholders; avoid detailed visuals.

Why wireframes matter

  • Focus the team on structure and flow instead of aesthetics.
  • Allow fast iteration because changes are cheap.
  • Make it easier to spot missing or misplaced elements early.
  • Give developers a clear view of what to build before high-fidelity design.

What a good wireframe includes

Checklist

  • [ ] One purpose – e.g. “homepage layout” or “checkout flow”; don’t try to show everything.
  • [ ] Readable hierarchy – clear primary vs secondary content and actions.
  • [ ] Reasonable realism – approximate content length and key elements so the layout is testable.
  • [ ] Consistent with the system – if you have patterns or a grid, use them.
  • [ ] No final visuals – no brand colours or final copy; keep it clearly a draft.

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.
  • High-fidelity wireframe: still no final visuals but more detail and sometimes basic interactivity. Use when you’re about to hand to visual design or dev.

Examples

Example (the realistic one)

You’re designing a settings page. The wireframe shows: top (back + “Settings” title), then grouped sections (Profile, Notifications, Privacy), each with a heading and 2–4 rows (label + control or link). One primary button at the bottom. No colours or real copy; placeholders like “Label” and “Value”. You use it to agree structure with the team and then build 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; move to high-fidelity only when structure is agreed.
  • No hierarchy: everything looks equally important. → Do this instead: use size, spacing, and grouping to show what’s primary.
  • Missing key elements: you discover critical UI late. → Do this instead: list must-have elements (e.g. nav, main CTA, error states) and check they’re in the wireframe.
  • Skipping wireframes: going straight to high-fidelity. → Do this instead: use wireframes when the main risk is structure and flow; they save time.
  • Wireframe vs prototype: a wireframe is usually static (or lightly linked); a prototype is interactive. Wireframes often become the basis of a prototype.
  • Wireframe vs mockup: a mockup is high-fidelity and visual; a wireframe is low-fidelity and structural. Wireframe first, then mockup when you’re ready for look and feel.
  • Wireframe vs wireframing: wireframing is the activity; a wireframe is the artefact. See Wireframing for the process.

Next step

Pick one screen or flow, sketch a low-fidelity wireframe (paper or digital), and get feedback on structure before adding visual design. Then turn it into a prototype if you need to test the flow.

Related Terms