A website wireframe is a simple, mostly grayscale layout sketch that shows where content and interface elements sit on a page, so structure can be agreed before colors, fonts and photography are chosen.
Wireframes are one step in preparing a build, and the overview of web design templates shows where they fit against ready-made layouts.
What a wireframe shows and leaves out
Nielsen Norman Group describes wireframes as a common deliverable in the UX field for showing page-level layout ideas. The purpose is narrow on purpose. A wireframe answers questions such as which blocks appear on a page, in what order, how large each one is relative to the others, and what a visitor can click.
It leaves a lot out. In NN/g’s comparison of prototype fidelity, a wireframe is the textbook case of a design that captures only some or none of the visual attributes of the final live system, such as a black-and-white sketch with schematic boxes standing in for images and graphics. Spacing and element prioritization may or may not be preserved. Real photographs, brand colors and finished typefaces are deliberately absent.
That restraint is the point. When a reviewer sees a pale green button next to an unfinished headline, the conversation drifts toward taste. When the same screen is gray boxes with labels, the conversation stays on what belongs on the page and where.
Why plan layout before visual design
The economic argument is old and simple. NN/g puts it plainly in its advice on testable prototypes: ripping up code is very expensive, while ripping up a prototype is not, especially if it is just a piece of paper. A wireframe is the cheapest version of that prototype. Moving a sidebar in a sketch takes seconds; moving it after templates, styles and content have been built around it takes real work.
NN/g also lists the benefit of low-fidelity work in terms of time: less time to prepare a static prototype leaves more time to work on design before testing. Without having to make a prototype work, a team can spend more time designing pages, menus and content.
A second benefit is shared vocabulary. A client, a developer and a designer can all point at the same labeled box. Disagreements surface at the cheapest moment, before anyone has attached a color or a code branch to the decision.
Fidelity levels: from paper to clickable
NN/g notes that prototypes range between pairs of extremes: single page versus multipage, realistic and detailed versus hand-sketched on paper, and interactive (clickable) versus static. Wireframes sit at several points on those scales, and the level should match the question being asked.
| Level | What it looks like | Best for |
|---|---|---|
| Sketch | Hand-drawn boxes on paper or a whiteboard | Exploring several layout ideas quickly |
| Static wireframe | Gray boxes, real headings and labels, no styling | Agreeing on content order and page structure |
| Clickable wireframe | Wireframe screens linked together in a prototyping tool | Testing navigation and task flow with users |
| High-fidelity mockup | Final colors, type and imagery | Visual sign-off and developer handoff |
Fidelity ranges and the interactive-versus-static distinction are described in the Nielsen Norman Group article on low- and high-fidelity prototypes.
The cheaper levels deserve more respect than they get. With static prototypes, NN/g explains, the responses to a user’s actions are given in real time during the test by a person who knows the design. Paper screens can be tested with someone playing the role of the computer, which means a layout can be tried on a real visitor before a single screen is built in software.
Building a page wireframe step by step
- Start from content. List what the page must contain: the main message, supporting sections, calls to action, navigation, footer. Use real headings and real button labels where they exist, rather than lorem ipsum.
- Rank the content. Decide what a visitor must see first. The most important block gets the most space and the earliest position.
- Block out the layout. Draw rectangles for each element. Use a cross or a label for images, and lines for text. No colors beyond shades of gray.
- Mark interactions. Label what is clickable, what opens a menu, and what each button leads to.
- Draw the small-screen version. Sketch the narrow layout as a separate view, with the same priorities in a single column. Content that ranks lowest is the first to move down or fold away.
- Review against the task. Ask someone to complete a typical task using only the wireframe and note where they hesitate.
Annotations make the sketch self-explanatory. A short note beside a block, such as which action a button triggers, what appears when a list is empty, or which items collapse into a menu on a narrow screen, saves a round of questions during review. Keep notes factual and brief so the layout stays the main thing on the page.
A set of wireframes also works as a content inventory. Counting the distinct page types, such as home, category, detail, search results and checkout, shows how many templates the build needs and which elements repeat across them, like the header, footer and promotional strip. Repeated elements only need to be drawn properly once and then referenced.
Real content matters here. A wireframe full of filler text hides the problems that long headings, empty states and error messages create later.
From single pages to flows
A single wireframe cannot show how a visitor gets from one screen to the next. NN/g covers this with wireflows, which it defines as a combination of wireframes and flowcharts. In a wireflow, each step of a task shows a simple wireframe or high-fidelity screen mock-up, and an arrow marks the specific interface component where the user takes action, pointing to another wireframe showing what happens as a result.
The result does not have to be a separate page for every step. NN/g notes that the second node of an interaction can show the same page with the result of that interaction. For a sign-up form, that might mean one frame for the empty form, one for a validation error and one for the confirmation message.
Wireflows are most useful for tasks such as checking out, registering or searching, where the order of screens matters as much as the layout of any one of them.
Checking a wireframe before color is added
A wireframe is a good moment to apply a review checklist, because fixes still cost almost nothing. The set of ten usability rules of thumb in usability heuristics can be applied to a wireframe screen: is the current state visible, are labels in the visitor’s language, is there a clear way to back out of an action?
Color decisions come next, and they carry their own requirements for readable contrast and for not relying on color alone. Those are covered in the guide to choosing a website color scheme, which is easier to follow when a wireframe has already settled which elements need distinct states.
Common wireframe mistakes are easy to list: decorating the wireframe so reviewers critique styling, leaving out navigation and footers, using placeholder text that is shorter than the real copy will be, and skipping the narrow-screen view.
Frequently asked questions
What is the difference between a wireframe and a mockup?
A wireframe is a layout sketch that fixes structure and priority. A mockup adds the final colors, type and imagery, so it shows how the page will look.
Do wireframes need special software?
No. Paper and a pen work, and NN/g notes that a design drawn on paper can be tested with a person acting as the computer. Prototyping tools add links between screens.
Should a wireframe use real text?
Where possible, yes. Real headings and button labels expose layout problems that filler text hides.
What is a wireflow?
It combines wireframes and flowcharts: screens are shown step by step with arrows marking the interface element that triggers each change.
