Wireframing teaches you to organise a task before investing in visual polish. Start with the information a person needs, sketch a sequence of screens, and test whether the route is understandable. This roadmap uses a fictional room-booking service. Your deliverable is a connected set of low-detail layouts with annotations for choices, errors, and confirmation. The important question is whether someone can complete the task, not whether the grey boxes resemble a finished brand.
Map the task before drawing screens
The visitor wants a quiet room for two people on a selected afternoon. They need to know availability, capacity, location, and any booking conditions. Write the start and end points: arriving at the room list and receiving a confirmed reservation. List the decisions between them. A task map prevents a visually pleasing page from omitting an essential step.
Define a small fictional inventory: Room A holds two people, Room B holds six, and Room C is unavailable on the chosen date. Do not create a complete room-management platform. The purpose is to practise one flow and its exceptions. GOV.UK’s prototyping guidance describes using prototypes to explore and test ideas Source 1. Choose a fidelity that exposes your current uncertainty rather than imitating production software.
Build information hierarchy and navigation
Sketch the room list with the date choice near the availability results. Show capacity and location where the person compares rooms. On the details screen, include enough information to make a decision without requiring the visitor to remember labels from the previous page. Keep a clear route back that preserves their selected date.
Use meaningful text, not repeated lorem ipsum. A label such as “Reserve this room” communicates more than “Next.” Draw headings and fields in reading order. W3C’s forms guidance explains the importance of labels and instructions Source 2; your wireframe should reserve space for them rather than treating them as later implementation details.
Create a review screen showing room, date, time, and party size before confirmation. Let the person change an item without restarting the whole flow. Identify which action makes the reservation final. This distinction matters even in a prototype, because an ambiguous final button prevents a meaningful usability review.
Include the paths that interrupt success
Add three states: no room fits the selected party size, the selected time becomes unavailable, and a required contact field is missing. For each state, write what the person can do next. An error without a recovery route is a dead end, even when the main sequence is clear.
In the fictional exercise, the person chooses Room A for two people at 15:00. Before confirmation, the time becomes unavailable. The expected recovery is to choose another available time while retaining room and party details. Make that path visible in your screens. Annotate the assumption that the system checks availability again before final confirmation.
Use a simple clickable prototype or paper cards. Do not add animation unless movement is the question being tested. The GOV.UK component catalogue offers examples of familiar interface building blocks Source 3. Study their purposes, but avoid presenting an unimplemented sketch as proof of accessible behaviour.
Review and hand off the flow
Ask a peer to reserve a room using the fictional scenario. Give the goal without naming the buttons they should press. Observe where they look for availability, whether they understand the review step, and how they recover from the unavailable time. Note the screen and behaviour rather than simply marking the design good or bad.
Revise one structural problem and retest that part. For example, if the person compares capacities only after opening every room, move capacity into the list. Your final package should contain the task map, numbered screens, transitions, annotations, and a change log. Include a narrow-screen version showing how the reading order survives stacking.
Keep unresolved questions visible: who can book, how long reservations last, and what cancellation rules apply. Do not invent policies to make a mockup appear finished. Mark them as assumptions in the practice brief and explain that a real service would need confirmed rules before implementation.
- Task mapWrite decisions before screens.
- LayoutPlace information where each decision occurs.
- ExceptionsAdd missing, unavailable, and recovery states.
- ReviewObserve the flow and revise one structural problem.
| Checkpoint | What to produce | How to review it |
|---|---|---|
| Entry | Date and party-size choices | Results reflect the stated criteria |
| Comparison | Capacity visible on room cards | No need to open every detail page |
| Recovery | Unavailable-time state | Existing choices remain intact |
| Confirmation | Room, time and reference | Final action is unambiguous |
- Low fidelity can test
- Order, wording, grouping, and navigation.
- Low fidelity cannot prove
- Production keyboard behaviour or live availability.
- Handoff should identify
- Confirmed decisions, assumptions, and unanswered rules.
Common questions
How detailed should a wireframe be?
Detailed enough to test the question you currently have. If the uncertainty is navigation, show realistic labels and links. If it concerns visual hierarchy, include meaningful spacing and text lengths. Avoid spending time on branding before the task structure works, but do not remove information that a participant needs to make a realistic choice.
Can I use paper instead of software?
Yes. Paper screens can reveal missing steps and unclear labels quickly. Have someone change the visible screen in response to the participant’s choices. Explain the limitations of the simulation. Move to a clickable prototype when transitions, scrolling, or more complex interactions become important to the question you want to investigate.
Why should I avoid placeholder text?
Placeholder text often hides real content requirements. A long room name, booking condition, or error message may change the layout substantially. Write plausible fictional content and label it as such. The purpose is to test whether the structure supports the information, not merely whether empty boxes fit neatly on a canvas.
Do I need every possible error state?
Prioritise the exceptions most likely to interrupt the chosen task or create serious confusion. For this exercise, unavailable times and missing contact details are enough to expose recovery design. Record other cases for later. A bounded but complete flow is more useful than dozens of disconnected screens with no tested route through them.
Should the mobile layout be a smaller desktop layout?
No. Preserve the task and information hierarchy while adapting the arrangement to the available space. Columns may stack and controls may need different grouping. Test long labels and the review screen at a narrow width. Shrinking everything can make text and interaction targets difficult to use without solving the underlying structure.
How do I annotate a wireframe?
Explain behaviour that a static screen cannot show: validation timing, preserved values, data dependencies, and destinations. Keep annotations separate from user-facing content. A developer should understand what happens when a room becomes unavailable. Avoid notes that merely repeat visible labels without clarifying a decision or rule.
What if a reviewer suggests a different layout?
Ask which task problem the suggestion addresses. Compare the alternatives using the same scenario rather than defending your first sketch or accepting every preference. A change should make information easier to find or an action clearer. Record the evidence and tradeoff so the revision has a reason beyond personal taste.
When am I ready to add visual design?
Move forward when the main task and important recovery routes are coherent, the content requirements are known, and a reviewer can follow the flow. Some questions will remain, but identify them explicitly. Visual design can then reinforce hierarchy instead of covering gaps in the task model with attractive colours and illustrations.
Continue your learning
UI Design Learning Roadmap: Build a Consistent Interface from a Brief. Usability Testing Roadmap: Observe Tasks and Turn Findings into Improvements.
Sources and further reading
- GOV.UK: prototypes — Choose prototype fidelity to explore service ideas.
- W3C: forms — Labels and instructions need space in a form.
- GOV.UK: components — Common interface building blocks and their purposes.
Skills & Learning Desk
MP Job Hub’s organisational byline for sequenced practice, course evaluation and useful learning habits.
Skill roadmaps · Learning resources · Practice projects
View profile →Read our research process or request a correction.
