Prepare website wireframes around the task a visitor needs to complete, the information needed at each step and a decision you can test. Choose enough detail to examine that decision. Use realistic content, a clear observation plan and a record of revisions before treating the layout as ready for implementation.
A useful wireframe makes an unresolved design choice visible. It might show where visitors find requirements before an enquiry, how they compare service options or what happens after submitting a form. Begin by writing the question the wireframe should answer, so the team can assess its usefulness beyond visual preference.
What should a wireframe help the team decide?
The GOV.UK prototyping guide provides a method that can be adapted to a business website. GOV.UK describes prototypes as a way to explore and test designs before building. Its guidance allows prototypes to range from paper sketches to interactive code. Choose the form that supports the question under discussion.
For an early conversation about information order, a labelled sketch may be sufficient. If the question concerns what happens when a visitor opens a menu, corrects a form or returns to a previous step, prepare an interaction that lets the participant attempt that action. Document which parts actually respond and which are explanatory placeholders.
It describes sketches as useful for discussing basic ideas with colleagues. It describes code prototypes as more realistic for user research. Keep that distinction tied to the decision: a paper sketch can support a discussion about content priority, while an interaction question may need behaviour the sketch cannot demonstrate.
It cautions against copying prototype code directly into production. Record the production requirements separately from the experiment. An approved direction still needs its implementation, content and functional checks before it becomes a working page.
How do task flow and content priority fit together?
Write the intended journey in plain language: arrive with a question, identify relevant information, assess the answer and choose a next step. Map each stage to content the visitor can actually use. If a proposed section does not help with that journey, ask which reader need justifies its place.
Use representative headings and explanations in the wireframe. A placeholder labelled “benefits” leaves reviewers guessing about what the page will say. Draft enough real wording to reveal whether the proposed content answers the visitor’s question and whether the next action follows naturally from it.
Include the awkward states that affect the chosen task. A visitor may have no existing website, may not know a technical term or may want to return to requirements after starting an enquiry. Show the relevant branch in the flow rather than assuming every person follows the ideal path.
The table below is an original decision worksheet for a service-enquiry wireframe. Complete it before choosing colours or polishing presentation. Each row connects an intended decision to something a reviewer can observe.
| Design question | Content or behaviour to show | Observation to record |
|---|---|---|
| Is the service relevant? | Plain explanation of purpose and scope | Where the participant looks for fit |
| What should I prepare? | Project information with short explanations | Which request needs clarification |
| Where do I enquire? | Descriptive action and destination | Whether the participant finds the route |
| What happens after sending? | Proposed confirmation content | What the participant expects next |
| Can I correct a mistake? | Return or correction behaviour | Whether the previous information remains understandable |
Keep proposed operational statements in the worksheet for the business owner to confirm. A wireframe should not silently establish a response time, service promise or required customer process. Mark the content decision and who must resolve it before implementation.
How can a task test avoid coaching the participant?
The GOV.UK moderated-testing guide explains the observation approach. Moderated usability testing observes participants attempting specific tasks. Thinking aloud can reveal what a participant is doing and thinking. Ask for the participant’s interpretation without turning every hesitation into an instruction from the facilitator.
The guide says research participants should be actual or likely users. Choose people whose intended task resembles the question being investigated, and arrange an accessible way for them to participate. Explain the exercise and any recording arrangement before starting. Use appropriate sample material where the prototype cannot safely handle real information.
Its task-design guidance calls for a clear participant goal. Its task-design guidance says instructions should avoid giving away the answer. “Find out what you would need before discussing this project” leaves room to observe the route; “click the preparation tab” supplies the very route being examined.
Distinguish an observation from an interpretation in your notes. “The participant opened the contact page before finding the requirements” describes what happened. “Move the requirements higher” is a proposed response. Keep both, then identify which revision would best address the evidence from the session.
Original enquiry-flow comparison exercise
Prepare two hypothetical arrangements for a website project enquiry. In one, the requirements appear beside the service explanation. In the other, they appear on a linked preparation page. Keep the underlying information consistent so the exercise examines placement and flow rather than entirely different offers.
Write a neutral scenario: the participant wants to discuss replacing an existing website and needs to understand what to prepare. Give them the starting page and ask them to explain what they would do. Observe the route, the information they identify and any uncertainty about beginning the enquiry.
Retain the wording and version of the arrangement used in each session. If the facilitator explains a label or helps the participant recover, record that intervention. It provides context for interpreting the subsequent action and for designing a clearer instruction or page revision.
Review the evidence with the content owner and implementer. Ask whether the difficulty arose from information order, a confusing heading, an incomplete explanation or behaviour that the prototype did not support. Choose a revision that addresses the identified issue and write the question for a further check.
Before handover, annotate the selected wireframe with final content responsibilities, destination links and the behaviours that still need implementation. Preserve unresolved decisions explicitly. A developer should be able to understand what was agreed and which details still require a business answer.
Give the handover a readable change record. Link each chosen revision to the question it addresses and identify any competing option that remains worth checking. When the team revisits the layout, this record explains why the page took its current form. It also helps a new reviewer distinguish a deliberate content choice from an accidental omission, without requiring them to reconstruct every discussion that happened during design.
For related work, see website development and SEO. Get started with your visitor task, existing content and the layout decision you want to examine.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.