process & strategy
Wireframe
What is a wireframe?
A wireframe is a deliberately plain, low-fidelity blueprint of a screen - boxes, lines and placeholder text showing what goes where and how the structure works, with the visual design stripped out on purpose. By leaving out colour, imagery and polish, it keeps everyone focused on layout, hierarchy and flow before anyone argues about how it should look.
Also known as: wireframe, wireframing, lo-fi layout
Prefer to watch?
Watch the recap 0:57
The demo
The same product screen, twice: as a plain wireframe and as the finished design. Flip between them and notice what you think about in each - the structure, or the styling.
What this demo shows (text version)
The same product screen is shown two ways: as a wireframe - grey boxes, lines and placeholder labels showing only the structure - and as the finished, styled design. They share the identical layout and hierarchy; the wireframe simply leaves out colour, imagery and polish. Flipping between them shows that the wireframe carries all the structural decisions without any of the visual noise.
That's a wireframe: a deliberately low-fidelity blueprint that keeps everyone focused on layout, hierarchy, content and flow before visual design enters the conversation. The plainness is the point - it's fast, cheap to change, and stops people fixating on aesthetics before the structure is right. Move to higher fidelity only once the bones are agreed.
A wireframe answers "what goes where and why" before "what should it look like". By using grey boxes and placeholder text instead of real visuals, it forces conversation onto structure, content priority, hierarchy and flow - the decisions that are cheapest to change early and most expensive to change late. The deliberate plainness is the point: it's fast to make and easy to throw away, and it stops people fixating on colours and fonts before the bones are right. Keep wireframes low-fidelity on purpose - the moment they look "designed", feedback drifts to the surface and away from the structure you're trying to settle.
Stripped back to boxes and labels, you actually discussed what mattered - what goes where, what's most important, how the flow works - instead of the colour of a button. That's the whole point of a wireframe: its plainness keeps attention on structure, when structure is the cheapest thing to change. Add the visual polish too soon and the conversation slides to the surface before the bones are right.
Wireframes sit early on the fidelity spectrum (sketch → wireframe → mock-up → prototype). Their job is to settle structure and content: what elements a screen contains, their relative importance (hierarchy), where they sit (layout), and how screens connect (flow). Deliberately omitting colour, real imagery, final copy and styling keeps the focus there and makes wireframes fast to produce and cheap to change or discard.
The low fidelity is a feature, not a limitation. When a wireframe looks unfinished, reviewers comment on layout and priorities; when it looks polished, they comment on aesthetics and assume the design is "done", which derails structural decisions and makes people reluctant to change course (a sunk-cost trap). Keeping it grey and boxy protects the early conversation and invites honest, structural feedback.
Wireframes also support fast iteration and shared understanding: they're quick to sketch (on paper or in a tool), easy to compare side by side, and a clear artefact for aligning designers, developers and stakeholders on structure before investing in visual design or build. Use placeholder content that's realistic enough to test layout (long names, real-ish labels), and move to higher fidelity only once the structure and flow are agreed.