Wireframing
Sketch the structure before you design the surface. Wireframes separate structural decisions from visual decisions — resolving layout, hierarchy, and flow in low fidelity before anyone invests time in aesthetics that might all need to change.
01 — TL;DR
Two sentences.
Wireframing is the practice of representing the structure, layout, and content hierarchy of a screen or flow using simplified, low-fidelity representations — grey boxes, placeholder text, and schematic components — without visual styling, colour, or final copy, so that structural decisions can be made and iterated on cheaply before any investment in visual design. The core value is not the wireframe artefact itself but the structural thinking it forces.
Wireframing became a standard UX discipline in the late 1990s as digital interface complexity outpaced written specifications. What makes it valuable today is its function as a thinking tool — the act of sketching forces structural decisions that are easy to avoid when working at higher fidelity, because high-fidelity tools make it too easy to fill space with polish rather than resolve it with decisions.
02 — When to Use
Apply this when…
When NOT to apply it
Skip it when the structure is already validated, when the work is purely visual refinement, when you are iterating rapidly on a live product where changing the final design directly is cheaper, or when the team is small and aligned enough that shared understanding already exists.
03 — How It Works
The mechanism
Wireframing works by creating a deliberate constraint: the absence of visual polish forces the team to evaluate structure on its own merits. When a screen looks unfinished, reviewers engage with hierarchy, flow, and content priority rather than font choices and colours.
Wireframes are a means, not an end
A team that produces wireframes because "that is the process" without using them to resolve structural questions has added a phase without adding value. The test: is the visual design phase that follows faster and less rework-prone than it would have been without the wireframe? If not, the wireframing step was unnecessary.
04 — Real Example
Airbnb's paper prototyping and the mobile app that shipped from sketches
Airbnb's mobile app was structured through paper wireframes before any digital design work began. The team produced rapid paper sketches of core flows — search, listing, booking, host management — and tested them with real users by physically swapping paper screens to simulate navigation.
When they discovered that users expected to see pricing before selecting dates — a structural decision affecting the entire booking flow — the cost of changing a paper sketch was thirty seconds. The cost of changing a high-fidelity prototype would have been weeks. The wireframing phase paid for itself on the first structural insight it surfaced.
05 — In the Wild
Test yourself & see real examples
No examples yet — be the first.
Spotted a product whose structure clearly was not thought through — or one where the layout feels so considered it must have been wireframed? Submit what you observed.
Seen Wireframing skipped in a real product? Help grow the evidence base.
06 — Common Mistakes
Where teams go wrong
07 — Variations & Related Principles
Connected ideas
Wireframing sits within a family of prototyping practices that vary in fidelity and purpose. Understanding which to use when prevents over-investing in fidelity before structural decisions are resolved.
The most important pairing is Wireframing with Cognitive Load Theory. A wireframe critique that only evaluates structural logic without evaluating cognitive load produces screens that make sense on a whiteboard but overwhelm users. CLT gives a specific question for each screen: how many discrete things must a user process simultaneously? If the answer exceeds four, restructure before visual design begins.
08 — 10-Min Exercise
Run it right now
⏱ 10 minutes · Solo · No prep
1. Pick one screen in your product that could be improved. On a blank piece of paper, draw a phone or browser frame. Without looking at the current design, sketch the ideal structure using only boxes, lines, and labels.
2. Force yourself to answer: what is the single primary action? What content must appear above the fold? What can wait below it or be hidden entirely?
3. Now open the actual screen and compare. Note every structural difference — things placed differently, things omitted, things present that your sketch excluded.
4. For each difference, ask: was this structural decision made deliberately, or did it happen by default because the previous design had it? Decisions made by default are your highest-priority wireframing opportunities.