012 min
Why teams start with wireframing
Picture a team building the checkout screen of a food delivery app. The product manager wants the tip field near the top. The designer wants the delivery address first, because a wrong address means the food never arrives. A developer asks where the error will show if the card fails. Nobody has drawn anything yet, so each person is arguing about a different screen in their head.
Wireframing ends that argument with a drawing. The designer draws the checkout as grey boxes: one for the address, one for the order list, one for the tip, one for the pay button. Within an hour, the whole team is pointing at the same picture. Moving the tip box below the order list takes ten seconds. Moving the same block after it is built means changing code, layout rules and tests, and often another round of review.
That cost difference is the reason wireframing comes early. It happens after the team knows the goal and before anyone picks colours or writes code. A stakeholder who first sees the checkout as a finished, coded screen may ask for the same changes, but now each one takes days instead of minutes. In agile teams that ship every week or two, the wireframe is usually drawn just ahead of the sprint that builds it.
A wireframe also gives each role something concrete to check. The product manager checks that every needed feature has a place. A developer can ask early what is hard to build: can the app show a delivery time before the address is confirmed? A copywriter sees how much room each label has. Designers, business analysts, information architects and developers all make wireframes, so the skill does not belong to one job title.
022 min
What a wireframe shows and leaves out
Back at the checkout, the grey boxes record four kinds of decision. All four are about structure, not style.
- Layout: where each block sits and how much space it gets. The address block spans the full width. The tip block is half as tall.
- Content hierarchy: what the eye should reach first. Designers show it with size, position and shades of grey, never with brand colour. A larger, darker box reads as more important.
- Navigation: how people get into the screen and out of it, such as the back link, the step counter and the button that leads to payment.
- Controls: the fields, switches and buttons people use, drawn as plain shapes with their labels.
Most wireframes also carry annotations. These are short notes beside a box that say how it behaves: "Tip options: none, 10%, 15%, custom. Default is none." Developers often read the notes more closely than the drawing.
What a wireframe leaves out matters as much as what it shows. There is no brand colour, no photo of the food and no final typeface. Headings are marked by size and weight only. This is deliberate. When a picture looks finished, people comment on how it looks. When it is grey boxes, they comment on what is where and in what order.
A wireframe also depends on the information architecture behind it. The site map decides which screens exist and how content is grouped. The wireframe shows how one screen presents that grouping to the person using it.
Real words or placeholder text in a wireframe
Many wireframes fill text areas with lorem ipsum, a standard block of scrambled Latin. It keeps reviewers from editing the wording too early, but it can hide a real problem. If the real delivery note reads "Leave at the door if nobody answers", it may not fit the field the designer drew. Where the real words are known, use them. Where they are not, write a realistic sample of the right length.
032 min
Where the word wireframe comes from
The checkout drawing takes its name from 3D computer graphics. A wire-frame model draws a solid object using only the lines along its edges, so you see the shape without the surface. Web designers took the word for the same reason: their drawing shows the structure of a page and leaves the surface off.
No single person invented wireframing for screens. It is practitioner convention, not a research finding. It became common as websites grew from documents into software, and teams needed to agree on a page before building it. Tools then followed the habit. Balsamiq, one of the best-known wireframing tools, was started in 2008 by an engineer who wanted to sketch product ideas fast, before they became full design projects.
Why 3D wire-frames were drawn as lines
In early computer graphics, the wire-frame was a speed decision, not a style. Filling every surface of a 3D object took more computing than the machines of the time could spare. Lines alone were fast to calculate, so they suited screens that had to redraw many times a second. Many video games of the 1980s and early 1990s drew their 3D objects this way. A web wireframe makes the same trade: it gives up surface detail to move faster.
Garrett's layers: what a wireframe leaves for later
In March 2000, Jesse James Garrett published a one-page diagram called The Elements of User Experience. It split web design into layers, from abstract goals at the bottom to concrete design at the top. In it, visual design is a separate top layer, which he described as the look in look-and-feel. Interface design, navigation design and information design sit one layer below it. A wireframe is a drawing of that lower layer, made before the top layer exists. That is why it can stay grey without being unfinished.
042 min
Wireframe fidelity: low, mid and high
Once the team agrees on the checkout structure, the next question is how much detail to draw. Fidelity means how closely a wireframe resembles the finished screen.
| Level | What it looks like | Good for |
|---|---|---|
| Low | Hand sketches or rough boxes, little real text, often on paper or a whiteboard | Comparing many layout ideas in an hour |
| Mid | Clean grey boxes drawn in a tool, real labels, consistent spacing | Agreeing the structure with the team; the level most teams use day to day |
| High | Exact spacing, real content, sometimes the real components | Handing over to developers, or testing details |
The checkout team would start low, with three or four quick sketches of where the address and tip could go. They would move to mid once one layout wins. High fidelity comes last, or not at all. A team with a mature design system often skips the high-fidelity wireframe. Its components already have a fixed look, so drawing grey copies of them adds a step and teaches nothing.
A useful rule is to draw at the lowest fidelity that answers the current question. A high-fidelity wireframe of an idea nobody has agreed on wastes effort. It also invites comments on spacing when the open question was the order of steps.
Paper or screen: the wireframe medium matters less
Many people believe a sketch on paper gets weaker feedback than the same wireframe drawn in a design tool. The research does not support that. In 2002, David Walker, Leila Takayama and James Landay tested paper and computer versions of web prototypes at low and high fidelity. Neither the level of detail nor the medium changed how many usability problems people found. The type of problem found changed with fidelity, and people made more comments on the computer versions. So the choice between paper and screen is about speed and convenience. It does not decide how much a test will find.
052 min
How to make a wireframe
With the level chosen, the work itself follows a short sequence. Here is how it runs for the checkout.
Write down the goal.
For example: a returning customer can pay for a saved order in under a minute. Every box on the screen should serve that goal or another named one.
Map the path first.
Decide which screen comes before checkout and which comes after. A user flow shows the path, and the wireframe shows each stop on it.
Pick the screen size.
Draw for the smallest screen that matters. A phone checkout has one column and large tap targets. A desktop version can show the order list beside the payment form.
Sketch several layouts.
Three quick versions of the checkout teach more than one polished one. The evidence is in the next part.
Place the parts.
Reuse the components the product already has, so the address field here matches the one on the profile screen.
Draw the other states.
An empty cart, a declined card, a lost connection, a sign-in prompt. These screens are often missing, and they are where many real problems are.
Annotate and review.
Add notes on behaviour, then walk the developers and the product manager through it. Ask what is hard to build.
Keep versions.
Save each round with a date and a short note on what changed, so nobody tests an old file.
Tools range from pen and paper to Balsamiq, Figma and Miro. Some tools now produce a first wireframe from a written description using AI. That saves the first few minutes, but someone still has to judge the layout. Treat a generated draft as one more option to compare, not as the answer. Designers also keep their wireframes for portfolios, because the wireframes show how a design was reasoned out before it was polished.
Sketch several wireframes before feedback
Steven Dow and colleagues at Stanford tested this question in 2010. Thirty-three novice designers made graphic web ads. One group got feedback after each version. The other group made several versions first and then got feedback on all of them together. The ads from the second group did significantly better, and outside raters judged them more varied. The team measured performance with real click-through data and expert ratings. For the checkout, the lesson is direct: draw all three layouts before anyone reviews any of them.
061 min
From single wireframes to wireflows
A checkout is not one screen, and a single wireframe is a still picture. It cannot show what happens when someone taps the pay button and the card is declined.
Teams use two common fixes. A user flow diagram shows the steps as labelled boxes and arrows, but it loses what each screen looks like. A wireflow keeps both. Page Laubheimer of Nielsen Norman Group described the wireflow in 2016 as a mix of wireframe layouts and a simple flowchart. Each screen is drawn as a small wireframe. Each arrow starts at the exact control that leads to the next state.
Wireflows suit apps where a screen changes in place: a total that updates, or an error that appears under the card field. A plain flowchart hides those changes, because it shows that a step happened but not what the person saw. For the checkout team, the wireflow is where the declined-card state gets drawn, right beside the screen that causes it.
072 min
Testing a wireframe with users
Once the checkout is drawn, the next step is to put it in front of people who will use it. A wireframe can be tested much like a finished screen. You give someone a task, such as ordering the same meal as last week, and watch where they hesitate. On paper, a team member plays the computer and swaps sheets when the person taps. That method has its own entry, paper prototyping.
What the 1996 GTE study found
A common worry is that rough drawings find only rough problems. Robert Virzi, Jeffrey Sokolov and Demetrios Karis at GTE Laboratories tested this in 1996. They ran two experiments. In each, one group used a low-fidelity version and another used a high-fidelity version or the real product. The first product was an electronic encyclopedia, and its low-fidelity version was more than 100 printed index cards. The second was a phone menu system, and its low-fidelity version was a person reading the prompts aloud. Both experiments turned up largely the same usability problems in both conditions. The authors concluded that low-fidelity versions stay useful through the whole of development, not only at the start.
Where a rough wireframe misses problems
That result has limits. In 2017, Jeff Sauro of MeasuringU reviewed 11 studies on prototype fidelity. Low-fidelity versions held up well for finding problems and for ease-of-use ratings. It does not hold for how long tasks take or for how attractive people find the design. In one 1990 study by Jakob Nielsen, expert reviewers found more of the major problems in a high-fidelity mockup than on paper. So a grey checkout can tell you whether people find the tip field. It cannot tell you whether the finished screen will feel safe enough for someone to enter a card number.
Why show three wireframes, not one
How you present a wireframe changes what people say about it. In 2006, Maryam Tohidi, Bill Buxton, Ronald Baecker and Abigail Sellen tested paper prototypes of a house climate control system with 48 people. Some people saw one design alone. Others saw the same design next to two alternatives that did the same job with a different layout. People who saw a single design rated it significantly higher and were less willing to criticise it. Seen beside alternatives, the same design received more criticism and stronger criticism. For the checkout, this means testing two or three layouts together, not only the layout the team likes best.
Users find problems, not fixes
The same study found a limit the authors did not expect. Even with three designs in front of them, people rarely suggested how to improve the design. The test told the team what was wrong. Deciding what to draw next stayed with the designer.
081 min
Wireframe vs. mockup vs. prototype
Testing raises a naming question, because the same checkout can exist in several forms. Each form answers a different question.
| Wireframe | Mockup | Prototype | |
|---|---|---|---|
| Answers | What goes where? | What will it look like? | How does it behave? |
| Shows | Layout, hierarchy, labels | Colour, type, images, final spacing | Taps, transitions, states |
| Can you use it? | No, it is a still picture | No | Yes, at some level |
| When | First | After the structure is agreed | Any time, from paper to code |
The one axis that separates them is the question each one answers. A wireframe settles structure. A mockup settles appearance on top of that structure. A prototype lets someone use the design, and it can be built at any fidelity. That is why a clickable set of grey wireframes counts as a low-fidelity prototype. Prototype testing is the practice of putting any of these in front of users.
Two more neighbours get mixed up with wireframes. A site map lists which pages exist and how they group, with no layout. A user flow shows the path through the screens, also with no layout. The wireframe is the first of these documents in which the screen itself appears.
091 min
Wireframing and accessibility
Grey boxes look neutral, but some accessibility decisions are already made in them. The order of boxes on the page usually becomes the order in which a keyboard user moves through it and a screen reader reads it aloud. The Web Content Accessibility Guidelines, known as WCAG, are the standard most teams design to. WCAG 2.2 success criterion 2.4.3, Focus Order, requires that when people move through a page in sequence, focus follows an order that keeps the meaning and the controls usable. Picture the checkout with the pay button drawn at the bottom but built first in the code. A keyboard user would reach the pay button before entering an address.
Fixing that in a wireframe is cheap. Number the focus order beside each control. Mark which text is a heading, and at which level. Write the label for every field and the text alternative for every image. Keep repeated navigation in the same place on every screen, which WCAG criterion 3.2.3, Consistent Navigation, also requires. These notes then reach developers with the layout, instead of arriving later as bug reports.
102 min
Where wireframing goes wrong
Wireframing goes wrong in a few predictable ways. Each one has a sign you can see in the file or in the review meeting.
- Too much detail too soon. The wireframe has brand colours, real photos and exact shadows. The sign: review comments are about the shade of a button, not the order of steps.
- Mistaken for the final design. A polished-looking wireframe gets approved as if it were ready to ship. The sign: a stakeholder asks when it goes live.
- Grey everywhere, so nobody can judge it. Clients who do not read wireframes struggle to picture the result. The sign: approval, then surprise at the mockup stage. Walk them through it aloud, or show one mockup early.
- Only the easy path. The checkout is drawn with a full cart and a card that works. The sign: developers ask what the error looks like, and nobody knows.
- Placeholder text that hides length problems. The sign: real labels stop fitting once they arrive.
- Shapes that mean different things. The same crossed box means an image on one screen and a video on another. The sign: developers ask what a shape means.
Kara Pernice of NN/g noted in 2016 that designers are also more willing to change a design that looks rough. That is one more reason to keep early wireframes rough on purpose.
Most wireframes are thrown away, and that is normal. Teams draw many layouts so they can choose one. The decision that matters is when to stop. Once the team agrees on the structure of the checkout, stop wireframing and move to visual design. If people keep polishing a wireframe after that point, they are making a mockup with the wrong tool.
?4 questions
Questions people ask
Is wireframing part of UX design or UI design?
Can developers build directly from a wireframe?
How many wireframes does a project need?
Should I wireframe for mobile or desktop first?
§12 sources
Sources
Robert A. Virzi, Jeffrey L. Sokolov and Demetrios Karis, "Usability Problem Identification Using Both Low- and High-Fidelity Prototypes", CHI 96 Proceedings, 1996.
Maryam Tohidi, William Buxton, Ronald Baecker and Abigail Sellen, "Getting the Right Design and the Design Right: Testing Many Is Better Than One", CHI 2006 Proceedings (course reading copy of the paper).
Steven P. Dow, Alana Glassco, Jonathan Kass, Melissa Schwarz, Daniel L. Schwartz and Scott R. Klemmer, "Parallel Prototyping Leads to Better Design Results, More Divergence, and Increased Self-Efficacy", Stanford University, 2010 (authors' submitted version).
Jeff Sauro, "Does the Fidelity of a Prototype Affect Results?", MeasuringU, 9 August 2017 (a review of 11 studies, including Walker, Takayama and Landay 2002 and Nielsen 1990).
Show all 12 sourcesShow fewer sources
Jesse James Garrett, "The Elements of User Experience" (one-page diagram), 30 March 2000.
Page Laubheimer, "Wireflows: A UX Deliverable for Workflows and Apps", Nielsen Norman Group, 4 December 2016.
Kara Pernice, "UX Prototypes: Low Fidelity vs. High Fidelity", Nielsen Norman Group, 18 December 2016.
W3C, "Understanding Success Criterion 2.4.3: Focus Order", WCAG 2.2.
W3C, "Understanding Success Criterion 3.2.3: Consistent Navigation", WCAG 2.2.
"Website wireframe", Wikipedia.
"Wire-frame model", Wikipedia.
Balsamiq, "Company".
