# How to run a small usability test without coaching the answer. Watch someone attempt a realistic task, record where help was needed, and make a bounded improvement decision. Includes a task script, worked example, and worksheet. ## The direct answer Run a small usability test by choosing a realistic task, preparing a specific version, and observing relevant participants attempt it with neutral instructions. Record what happened, including assistance, errors, and unfinished tasks. Keep observations separate from interpretation, then choose a change or another test. A small session can reveal a usability issue; it cannot establish wider demand, accessibility conformance, or long-term impact. - Author: Daniel Ziedins (https://www.danielziedins.com) - Published: Oct 21, 2026 - Updated: Oct 21, 2026 - Scripture: James 1:19 - Read: 7 min - URL: https://www.agent-six33.com/journal/how-to-run-a-small-usability-test > Let every person be quick to hear, slow to speak, slow to anger. > — James 1:19 A person can like your idea and still be unable to use it. A helpful-looking page can hide the one detail somebody needs before acting. Asking whether the design is clear gives you an opinion; watching a person attempt a meaningful task gives you a different kind of evidence. Both may be useful, but they should not be mistaken for each other. The working method below is for a small, low-risk resource or prototype. It is an original practical structure informed by the sources below, not a formal research standard. Do not test an unreliable service by asking people to depend on it for essential help. Resolve safety, permission, and operating responsibilities first. Use a sandbox when a task could send a message, spend money, publish information, or change a real record. ## 1. Choose a task and a decision, not a tour. Write the decision the session could change: whether to rewrite arrival instructions, move a confirmation detail, or remove a confusing step. Then state what you want to observe. Can a first-time visitor find a suitable session and explain what happens after choosing it? This is more useful than a broad request to explore the website and say what you think. Freeze or identify the version being tested. Record the page, prototype link, device context, starting point, and any unavailable parts. If the prototype cannot complete a step, say so in the record rather than turning that technical limit into a participant failure. Decide what counts as completion before the session, while leaving room to record an outcome that does not fit your expected categories. ## 2. Write the goal without naming the controls. GOV.UK's moderated-testing guidance recommends believable tasks that do not reveal the route to the answer. Keep that principle short and concrete in your script. Compare find the Contact tab and click Volunteer with you want to ask whether a role fits your available time; show what you would do next. The second instruction leaves the navigation open to inspection. Prepare a moderator-only note with the research question, the visible endpoint, and the assistance boundary. Do not read that note as part of the task. A scenario can provide necessary circumstances without supplying the right label. If a participant needs a different but equally relevant scenario, record the variation so you do not later imply that every session used identical conditions. ## 3. Prepare the participant and the test setting. Explain that the resource is being examined, not the person's ability. Set out the activity and agreed recording arrangements before beginning. Offer a way to pause or stop, and check that the person can use the materials and equipment. Do not assume that a familiar video platform, a desktop browser, or a spoken think-aloud instruction will work equally well for everyone. Use invented task details in a prototype that does not need personal information. Remove real submission destinations, or make the sandbox boundary unmistakable. A note-taker needs only the information relevant to the question. Keep a participant code beside observations and store contact details separately where practical. If you cannot provide an appropriate setting or review for the people involved, change the plan before recruiting them. **Recruit for the task, not for agreement:** Choose relevant experience and participation arrangements before scheduling a session. https://www.agent-six33.com/journal/how-to-recruit-user-research-participants ## 4. Observe first, and make assistance visible. Give the task, then leave enough space for the participant to act. Do not convert each pause into a hint. If you ask a clarifying question, record it when it could influence the next action. A useful note says the participant reopened the schedule twice and asked whether confirmation was immediate; an interpretation such as the page creates anxiety belongs on a separate line. Stopping or helping can be the responsible choice. Decide how you will respond to distress, a technical block, or a task that is going nowhere. Record the prompt or intervention and describe any later completion as assisted. You can continue learning after assistance; you simply cannot report that path as an unassisted success. Preserve the difference between did not finish, chose not to continue, and could not proceed because the prototype ended. ## 5. Turn a hypothetical session into a bounded finding. Imagine a draft community-workshop page. This is a hypothetical example, not a SIX33 result. The task is to choose a session the person could attend and explain how they would know their place was confirmed. In the scenario, the page offers a time and a request button, but the confirmation process is buried in a separate paragraph. One participant finds the time, requests a place, and assumes the request is a booking. Another asks whether a reply is needed; the moderator points to the confirmation paragraph. Record those sequences separately. Do not compress them into both users completed booking, because the prototype did not establish a booking and the second path included help. Do not infer how often this issue occurs across all visitors. A candidate finding is that the tested version left the confirmation boundary unclear in these sessions. A reasonable next change is to state beside the request what is and is not confirmed, then observe the revised task with relevant people. The record should retain the original wording, the observations, the intervention, and the alternative explanation that the scenario itself may have implied an immediate booking. ## 6. Make one decision and keep the limits beside it. After the session, connect the task note to a candidate issue and its consequence. Distinguish a wording improvement from an unresolved service dependency. Clearer text cannot repair a coordinator who has not agreed to confirm places. Give the next action an owner and define what you will observe after the change, rather than treating the redesigned screen as a successful result on its own. Report the number of sessions, the relevant version and conditions, and which paths involved help. Do not turn a small convenience group into a reliable population success rate. Testing with people who use different access methods can reveal valuable barriers, but a small usability round does not replace a specialist accessibility audit or establish conformance. Likewise, successful task completion says nothing by itself about repeated use or lasting change. Keep a review record when the next version is ready. Which issue was addressed, which remains, and what would make you revisit the decision? An honest usability report can end with unresolved questions. Its value is in making the next change more accountable, not in giving a finished design a research-shaped seal of approval. **Keep the evidence traceable:** Adapt the source-to-finding discipline without treating interviews and observed tasks as interchangeable methods. https://www.agent-six33.com/journal/how-to-synthesise-customer-interviews ## Usability task script and observation worksheet Copy this blank template into your private working document. It contains no journal notes or tool drafts. ```markdown # Usability task script and observation worksheet Project, version, and date: [name / tested version / date] Decision this session could change: [specific decision] Question: [what you need to observe] Relevant participant experience: [criteria, not identifying details] Moderator / note-taker: [owners] ## Prepare the boundary Starting point and device context: [page / device / access method] Prototype limits and sandbox checks: [unavailable steps / no real submissions] Participation and recording arrangements: [agreed process / pause or stop option] Support or format requested: [arrange privately] Source-record access and review date: [who / date / handling process] ## Task — repeat as needed Participant-facing scenario: [realistic context and goal, no control labels] Moderator-only research question: [uncertainty] Visible endpoint agreed before the session: [what completion would mean] Assistance or stopping boundary: [when and how to intervene] ## Observation record Participant code and task ID: [private code / task] What happened, in sequence: [actions / words / relevant context] Questions, prompts, or assistance given: [exact intervention / when] Outcome: [unassisted / assisted / unfinished / chose to stop / prototype blocked / other] Unexpected result or disagreement: [details] Interpretation, separate from observation: [candidate explanation] Alternative explanations and limits: [what is not established] ## Review Candidate issue and consequence: [finding / source IDs] Change or operating dependency: [action / owner] Next observation after the change: [task / version / question] What remains unknown: [demand / wider frequency / conformance / long-term outcomes] Decision and review trigger: [proceed / change / investigate / stop] This is a planning aid, not a consent form, accessibility certification, or proof of demand or impact. Keep completed copies and participant records private. ``` > **The short version:** A completed task is only useful evidence when the conditions and the help remain visible. ## Questions ### What is the difference between an interview and a usability test? An interview explores an account of an experience. A usability test observes someone attempting a task with a particular version of a resource or service. You may use both, but an opinion about ease of use is not the same as an observed task outcome. ### What makes a usability task leading? A task becomes leading when it supplies the label, sequence, or answer you want to inspect. Give a believable situation and goal instead. Keep the expected route in the moderator's notes, and record any hint or assistance that influences the attempt. ### Can I help a participant who gets stuck? Yes, when that is appropriate to the session and the person's wellbeing. Record when and how you helped, and describe any later completion as assisted. Help can allow further learning, but it must not disappear from the reported result. ### Does a small usability test prove that a website is accessible? No. It can reveal barriers experienced by the participants with the tested version and conditions. It does not establish accessibility conformance or replace an appropriate audit. Keep access methods, support, missing perspectives, and limits visible in the record. ## Sources - GOV.UK Service Manual: moderated usability testing: https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing — Reference for observing realistic tasks and avoiding instructions that reveal the answer. The worksheet and workshop-page example are original illustrations, not a reported study or government endorsement. - GOV.UK Service Manual: finding research participants: https://www.gov.uk/service-manual/user-research/find-user-research-participants — Further reading on relevant participants and participation arrangements. A small task observation is not a representative survey. ## Explore the wider topic - Research and testing: https://www.agent-six33.com/journal/topics/research-and-testing — Daniel Ziedins · https://www.danielziedins.com · AGENT SIX33 https://www.agent-six33.com/journal/how-to-run-a-small-usability-test