Usability testing examines how relevant participants attempt defined tasks with your system or prototype. Plan the question, task instructions and observation rules before the session, then record what happened, including assistance, errors and unfinished attempts. Demonstrating your own application is not the same as observing someone use it.
Your evaluation chapter needs more than a claim that users liked the interface. UniDraft helps organise your actual method, permitted observations and verified findings into an editable Word document. Start your project document with UniDraft and bring the evidence you can explain. The final-year project workflow supports the writing; it does not recruit participants, run sessions or produce test results.
What question will the evaluation answer?
Start with a concrete uncertainty, such as whether a relevant user can recognise that a booking request has been submitted. Specify the version and part of the system being evaluated. A prototype with simulated responses supports different claims from an implemented service.
GOV.UK's user-research planning guidance connects research questions, user groups and method choice. Its service-delivery advice is a useful planning resource, not a Nigerian university assessment rule or a fixed student sample-size requirement.
Keep these forms of evidence distinct:
| Activity | What it can show within its scope |
|---|---|
| Functional test case | Whether observed software behaviour matches a stated requirement under the tested conditions |
| Usability session | How participating users attempt the selected tasks, including observed barriers |
| Opinion questionnaire | What respondents report about specified aspects of their experience |
| Your defence demonstration | What you show during that demonstration, on that version and equipment |
Use the software test-case guide to document functional checks and execution records. Neither passing those cases nor collecting favourable opinions automatically establishes task usability. Likewise, observing a confusing label does not by itself identify a code defect.
Plan participants, consent and a safe test environment
Explain who the intended users are and why the proposed participants are relevant. If only classmates are available, record the limitation rather than calling them representative of every future user. Justify the recruitment and number of sessions against the question, design and practical access with your supervisor. There is no universal rule that five people will find every problem.
Before recruitment or collection, confirm the applicable institutional review, access and participant arrangements. GOV.UK's informed-consent guide discusses explaining the purpose, activities, data use, observers, recordings and voluntary participation. Use it to identify planning questions; follow your own approved process, including its withdrawal and retention arrangements. It is not local ethics clearance.
Use authorised test accounts and suitable test data. Avoid asking participants to enter private passwords or real payment details merely to make the session realistic. Check recording permissions and what may appear on screen. A participant code does not necessarily anonymise a recording that contains a face, voice or identifying details.
The research ethics guide and data management plan help document those decisions. Do not invent approval, consent records or participant attendance in the methodology.
Write a goal rather than a route through the interface
GOV.UK's moderated usability-testing guidance describes observing people attempt specific tasks. It recommends believable goals and neutral instructions that do not reveal the solution. Its session schedules are service-research examples, not compulsory project durations.
Original fictional planning example: imagine an equipment-booking prototype with an approved test environment. No application or user session is being reported.
- Leading instruction: “Click Book Equipment, choose Item A, press Confirm and read the green message.” This reveals the interface route.
- Goal-based candidate: “You need Item A for the specified available period. Using this test account, make a request and tell me when you believe it has been submitted.”
Check that the task is appropriate to the actual participant and system. Before using it, define the starting state and what evidence would establish completion. If submission is simulated, say so. Do not describe a prototype response as a real reservation.
Prepare a short moderator script
Use a discussion guide so the task and instructions remain traceable. The following is an original rehearsal outline, not a consent form or an approved institutional script:
- Explain the study and the agreed arrangements for observers and recording; check that the required participation process is complete before starting.
- Explain that you are examining the interface, not grading the person. Confirm how they can pause or stop under the agreed process.
- Describe the starting situation and give one task without naming the buttons to press.
- Ask for the participant's thoughts where this fits the method. Avoid turning the session into a tutorial.
- Record prompts and task-solving assistance. Ask neutral follow-up questions about observed actions, then close the session through the agreed process.
Try the instructions and recording setup before the planned sessions. Label a rehearsal separately; it is not automatically a participant session or a result to include. If instructions change, retain the version and note which sessions used it.
Keep observations separate from explanations
GOV.UK's notes and recording guidance distinguishes observed actions and words from interpretation. It also discusses privacy and appropriate permission for recordings. Do not transfer its organisation-specific storage instructions into your project without checking your agreed plan.
Write “opened the request page twice and asked whether submission had happened” rather than “did not understand anything”. The first records observable events; the second supplies an unsupported general judgment. A follow-up explanation is another piece of evidence to record accurately, not a reason to silently replace the observation.
Use this original observation worksheet, adapted to the evaluation:
| Field | Record |
|---|---|
| Session and task IDs | Codes that connect the permitted records without exposing identity |
| Version and conditions | Build/prototype, device, relevant settings and starting state |
| Task wording | The instruction version actually used |
| Completion rule | Observable condition required for this task |
| Observation | Action or permitted exact words, with a useful time reference |
| Prompt or assistance | What the moderator said or did, and when |
| Outcome | Independent completion, assisted completion, not completed, or another explicitly defined status |
| Issue and uncertainty | Observed barrier, interpretation to check, and evidence reference |
If an attempt is stopped by a broken connection, unavailable test data or another interruption, record that reason. Do not silently treat it as either successful use or a participant failure.
Define completion, assistance and errors before counting
For each task, specify which attempts belong in the summary and how interruptions are handled. Independent completion and completion after task-solving assistance should remain distinguishable. A neutral reminder to think aloud is different from telling someone where to click; record enough detail to explain the distinction.
An error count also needs a rule. In the fictional booking exercise, an evaluator might define an observed input error as submitting a period that the task specified differently. That is an illustrative rule, not a universal usability metric. Going back to read a label is not automatically an error. One attempt may include multiple errors and still finish, so errors and unfinished tasks are not interchangeable totals.
If timing is relevant, define when it starts and stops and how pauses, assistance and interruptions are recorded. Think-aloud activity and differing conditions can affect comparisons. Do not label a measured task time “system response time”; the latter is a different technical measure.
A small fictional counting exercise
All rows below are invented for teaching. No participants were recruited, no sessions occurred and these are not findings to put in your project. Three rows are not a recommended sample size.
Suppose one task uses an agreed completion rule: the test system shows the recorded request and the participant identifies it as submitted.
| Fictional attempt | Observation under the exercise rules | Outcome | Defined input errors |
|---|---|---|---|
| P01–T01 | Reaches and identifies the recorded request without task-solving help | Independent completion | 0 |
| P02–T01 | Enters the wrong period, corrects it, then completes after the moderator identifies the submission control | Assisted completion | 1 |
| P03–T01 | Enters the wrong period and does not reach the required completion state during the attempt | Not completed | 1 |
For this invented exercise, one of three attempts completed independently; two of three completed if assisted completion is included. There were two defined input errors across the three attempts. These are different summaries, not three ways of saying the same thing. The rows do not establish population rates, the cause of the errors or that the interface is generally easy to use.
In your real report, give the task and denominator beside each count. Explain whether repeated attempts by the same person are included and whether a changed version was tested. Do not combine different builds into an apparent improvement without describing the design and its limits.
Turn observed issues into a traceable report
For each proposed issue, connect the task, observation, evidence and bounded interpretation. Record the practical consequence in the session, what needs further investigation and any change you made. If you conduct another authorised round, identify the version and participants or attempts; do not overwrite the earlier record.
The results-chapter guide helps present verified findings. Your conclusion should describe the selected tasks, participants and conditions, including inaccessible groups, untested paths and remaining uncertainty. Task testing alone does not prove accessibility for every user, security, performance or institutional acceptance.
Before writing “users preferred the new design”, check that you actually collected evidence for that claim. Before writing “all problems were solved”, check what was retested and what remains unexamined. Use permitted evidence in the report and appropriate appendices, rather than publishing identifiable raw session records.
When the evaluation is complete, bring the confirmed method, observations and limitations into UniDraft for the written project. Review the document against your records and the instructions you supplied; the writing should explain the evaluation you carried out, not create one for you.