Definition
A wireframe is a low-fidelity visual representation of a digital screen — showing layout, content hierarchy, structure and key interaction points — deliberately stripped of visual design (colour, imagery, typography) so the conversation focuses on structure and content.
Wireframes serve a specific job: aligning stakeholders on what goes on a screen and where, before time is spent on visual polish. They're a thinking tool, not a deliverable. The wireframes that 'look good' usually solved the wrong problem — the wireframes that look ugly and unfinished but ask the right questions are the ones that produce great final designs.
Modern UX practice has three fidelity tiers: low-fi (paper-and-marker, or quick boxes-and-lines in Figma), mid-fi (clean structure but no visual polish), and high-fi (close to final UI). Most product teams skip straight to high-fi too early — and pay for it later when stakeholders renegotiate basics that should have been resolved at low-fi.
Origin
Wireframing as a UX practice emerged from architectural drafting and industrial design conventions, adapted for software in the 1980s. The current digital wireframing vocabulary was formalised through the 1990s as web design became a discipline.
How it works
- Define the user's task for this screen — what are they trying to accomplish?
- List the content elements the screen needs.
- Rank those elements by priority — what does the user need to see first?
- Sketch the layout in low fidelity (boxes, lines, placeholder text).
- Mark interaction points (CTAs, navigation, form fields).
- Review with stakeholders, iterate, then promote to mid- or high-fi.
When to use it
Use when
- At the start of any new screen design.
- When stakeholders disagree about screen structure.
- When the team is debating content priority.
Skip when
- For tiny changes to existing screens.
- When the screen pattern is well-established from a design system.
Key metrics
- Stakeholder alignment achieved (qualitative)
- Iteration count to lock structure
- How many high-fi reworks were avoided
Examples
- Three rounds of wireframes saved us six rounds of high-fi rework.
- The wireframe surfaced that we had three competing primary CTAs on one screen — easy fix in wireframe, painful fix in code.
- We wireframed in marker on paper for the first week. Best decisions we made all quarter.
In practice at Makreate
Makreate UX engagements treat wireframes as the cheapest place to resolve disagreement. We deliberately keep the first wireframes ugly — grey boxes, no fonts, no colour — so the conversation stays on structure and content priority instead of visual taste. Stakeholders who want to argue about button colour at this stage are told (politely) that we'll get to it; structure first. The discipline saves weeks downstream.
UX Design →Common mistakes
- Skipping wireframes and going straight to high-fi.
- Making wireframes look too finished — stakeholders react to the visuals instead of the structure.
- Not validating the wireframe against the user's actual task.
- Adding visual design before the structure is locked.
- Treating wireframes as deliverables instead of thinking tools.
Frequently asked
Do I need wireframes if I have a design system?
Often yes — to figure out which design system components to use and in what arrangement. The design system is the LEGO bricks; the wireframe is the instruction sheet.
Are paper wireframes still used?
Yes, especially in early concept exploration. The speed and disposability of paper makes it ideal for divergent thinking.
Should wireframes show real content or placeholders?
Real or realistic content. Lorem ipsum hides content-driven layout problems that real content reveals.