Website Wireframes
A wireframe exists to settle structure while changing it is still cheap. The moment it acquires colour and real photography it stops doing that job.
A wireframe answers one question: what goes where, and in what order of importance. Everything else — colour, typeface, photography, animation — is deliberately withheld, because those things are how a bad structure gets defended. It is much easier to move a block in a sketch than to argue with a beautiful screen.
Why the fidelity is low on purpose
Low fidelity is not laziness. It is what makes feedback honest.
Show someone a finished-looking screen and you will hear about the shade of blue. Show them a grey box diagram and you will hear that the pricing is impossible to find. The second conversation is the one worth having, and you can only have it before the design looks finished.
There is a second reason. A wireframe that takes twenty minutes gets thrown away when it is wrong. One that took two days gets defended.
What belongs in a wireframe
- Every block of content, in priority order — top of the page to bottom.
- Real headings and real labels. "Get a quote" and "Request a consultation" are different lengths and different promises.
- The primary action, clearly the most prominent thing on the page.
- Navigation, including how many items it actually has.
- The states you would rather forget: empty, loading, error, and the version with far more content than you planned for.
What does not belong
- Colour, beyond grey and one accent to mark the primary action.
- Final photography. A crossed box is honest; a stock photograph makes an unfinished page look finished.
- Typeface decisions. Those belong with choosing fonts, once the structure is settled.
- Pixel-exact spacing. Approximate is the point.
The order that saves the most work
| Stage | Question it answers | Cost of a change |
|---|---|---|
| Sketch | Is this the right set of blocks? | Minutes |
| Wireframe | Is this the right order and emphasis? | An hour |
| Mockup | Does it look right? | A day |
| Build | Does it work? | A week |
Every stage skipped moves the same decision to a stage where it costs ten times more. The most expensive habit in web projects is discovering a structural problem during the build.
Wireframe the pages that carry the load
Not the whole site. Three or four pages settle almost everything:
- The template that repeats most — an article, a product, a service page. This is most of your traffic and most of your content.
- A listing or archive, where the empty and overflowing states live.
- The page the business depends on — checkout, contact, booking.
- The homepage, last. It is a composition of decisions made on the other pages, which is why designing it first tends to produce a homepage that no other page can live up to.
Testing a wireframe
Two tests need no tools and catch most problems.
The squint test. Blur your eyes. Whatever you still notice is what the page is emphasising. If that is not the primary action, the hierarchy is wrong, and no amount of colour will fix it later — colour only makes a wrong hierarchy louder.
The five-second test. Show it to someone for five seconds, take it away, then ask what the page was for and what they could do next. Wrong answers here are structural, and they are cheap to fix at this stage.
Handing a wireframe over
The wireframe is where an ambiguity gets caught or gets built. Annotate the decisions that are not visible: what happens when the list is empty, which items are links, what the maximum length of a title is, which blocks are optional.
If the design continues in a design tool and ends in WordPress, the handoff itself has its own failure modes — Figma to WordPress covers what survives that transition and what has to be rebuilt. If the site is being built with blocks, the structural vocabulary is group, row and stack blocks, and matching your wireframe to it early saves rework.
Common mistakes
- Adding colour to make it presentable. The moment it looks designed, the feedback changes subject.
- Placeholder text of a convenient length. Use the longest realistic title, not the one that fits.
- Wireframing only the wide screen. The narrow layout is where priority is genuinely forced, so sketch it first.
- Treating it as a contract. A wireframe that survives contact with real content unchanged usually means nobody tested it.
- Wireframing every page. Templates repeat; wireframe the template.
Verify
Before moving on, check that each page has exactly one obviously primary action, that every block can be justified by the page's job, and that you have sketched the narrow layout as well as the wide one. Then check the structure against the responsive design checklist — reflow problems are far cheaper to fix in a sketch than in CSS.
Frequently asked
- A wireframe settles structure and priority with no styling. A mockup adds the visual design — colour, type, imagery. A prototype adds behaviour, so links and states can be clicked through. They answer three different questions and are cheapest in that order.
- No. Paper and a pen are faster than any tool for the first few rounds, and being obviously unfinished is an advantage: people critique a sketch honestly and a polished screen politely.
- Real headlines and real labels, yes — they are the content most likely to break a layout. Body text can stay placeholder, but never use placeholder text of a convenient length, because that is exactly the case that will not occur.