Should a wireframe specify dimensions?

Not exact ones, though relative proportions and spacing relationships between key regions are worth noting. Design concerns hierarchy and structure; precise sizing belongs to visual design and implementation, and locking it early restricts later adjustment.

Which tool is best for wireframing?

Speed matters more than the tool. While structure is still moving, a general diagramming tool you can copy and rearrange quickly beats specialised design software, precisely because it makes you more willing to throw work away. Move to specialised tools once the structure is stable.

Should a wireframe use colour?

Greyscale plus one or two accent colours works best. Reserve the accent for interactive elements and primary actions, so review attention lands on interaction paths rather than colour preferences.

Do mobile and desktop need separate wireframes?

If the information hierarchy differs between them, yes. If it is only layout adaptation, draw one primary set and annotate the responsive rules. The deciding question is whether content priority changes with the device.

How to Make a Wireframe: Low-Fidelity Prototyping and Review

The point of a wireframe is deciding what goes where, not making something attractive. Grey boxes and placeholder-free real copy settle structure and hierarchy first, so discussion stays on content and flow. Introduce real colours and imagery and every conversation drifts to visual detail.

Know which fidelity you are at

These three stages answer different questions. Sketches test structure quickly, wireframes fix information hierarchy and interaction paths, and visual comps handle colour and finish. Skipping low fidelity and jumping to comps usually means structural problems surface during implementation instead.

Sketch: hand-drawn or minimal boxes, answering only whether a block exists
Wireframe: greyscale, real copy, marked interactive elements, answering where things sit and where they lead
Visual comp: colour, type, spacing, imagery, answering how it looks
The more expensive a change is later, the earlier you should be working

Decompose by hierarchy, not by layout

Before drawing, rank the content by importance: what must a user see immediately, what comes second, and what can hide behind an expander. Rank first and the layout choice largely makes itself — layout follows hierarchy, not the other way round.

List all content and actions on the page without arranging anything
Sort by "what breaks if this is missing" and cut anything that does not
Put tier-one content above the fold and tier-two in the scroll region
Move the rest into disclosures, secondary pages, or nowhere

Use real copy, not lorem ipsum

Placeholder text makes every layout look equally polished. Using real copy at real length — especially the longest button label and the longest heading — immediately exposes truncation, wrapping, and spacing problems. Those cost far more to fix in implementation than in design.

Use genuine copy, or at minimum genuine length
Deliberately test the longest heading and button text against the layout
Design empty, error, and loading states — not just the populated case
Mark interactive elements so buttons, inputs, and tappable cards read differently

Draw the transitions between pages

A single wireframe cannot reveal flow problems. Lay the main screens side by side and arrow the navigation and return paths between them, and dead ends (nowhere to go back) and detours (five taps to reach a destination) surface early. Mobile especially needs the back path checked — that is where it breaks most often.

Label every transition with its trigger, such as "tap card" or "submit succeeds"
Confirm every screen has a clear way back or out
Draw at least one exception flow, such as submission failure or lost connection
Count the steps for a key task; above three, look for a way to merge

Review: what to actually check

Wireframe reviews drift into visual debate easily. Pulling the conversation back to structure works better with a fixed checklist. The goal is finding problems, not agreeing on taste.

Does the information hierarchy match the content priority?
Is the primary action visible without scrolling?
Are empty and error states designed rather than left blank?
Does the layout survive when copy length changes?
Are tap targets large enough, particularly on mobile?

Frequently asked questions

Should a wireframe specify dimensions?: Not exact ones, though relative proportions and spacing relationships between key regions are worth noting. Design concerns hierarchy and structure; precise sizing belongs to visual design and implementation, and locking it early restricts later adjustment.
Which tool is best for wireframing?: Speed matters more than the tool. While structure is still moving, a general diagramming tool you can copy and rearrange quickly beats specialised design software, precisely because it makes you more willing to throw work away. Move to specialised tools once the structure is stable.
Should a wireframe use colour?: Greyscale plus one or two accent colours works best. Reserve the accent for interactive elements and primary actions, so review attention lands on interaction paths rather than colour preferences.
Do mobile and desktop need separate wireframes?: If the information hierarchy differs between them, yes. If it is only layout adaptation, draw one primary set and annotate the responsive rules. The deciding question is whether content priority changes with the device.