# 3.2 Conduct Early Usability and Inclusive Testing

## Test with real users

Test prototypes with real users to understand whether concepts, content, and flows work as intended.

<details>

<summary><strong>How to do it</strong></summary>

Testing with real users usually follows a simple loop:

1. Prepare to test
2. Recruit users
3. Test with users
4. Review what you learned
5. Decide what to change or test next

#### 1. Prepare to test <a href="#id-1.-prepare-to-test" id="id-1.-prepare-to-test"></a>

<figure><img src="/files/oSiJ4DtWXMsyTwwrBiTa" alt=""><figcaption></figcaption></figure>

Before testing, teams should agree:

* what they are testing (for example a journey, task, or decision point)
* what they want to learn
* which user groups to involve
* how many sessions are realistic

Document decisions using a discussion guide print out

#### 2. Recruit participants <a href="#id-2.-recruit-participants" id="id-2.-recruit-participants"></a>

Identify and recruit people who reflect the users you want to learn from.

Teams should agree:

* which user groups to involve
* how many participants are realistic (ofter 5-8 is enough to highlight 80% of the issues)
* how they will be contacted or invited
* who is responsible for recruitment

When contacting potential participants, make sure they understand:

* why they are being involved
* what will happen during the session
* how their data will be used

#### 3. Run testing sessions <a href="#id-3.-run-testing-sessions" id="id-3.-run-testing-sessions"></a>

During testing, focus on observing behaviour and listening, rather than explaining or defending the design.

1. **Test comprehension**\
   Ask users to:
   * think aloud
   * explain what they think the service does
   * describe what they believe will happen next
   * interpret key instructions, questions, or messages
2. **Capture issues and questions**\
   Note where users:
   * hesitate or get confused
   * misinterpret content
   * expect something different

Use a short discussion guide printout with the task/scenario and any questions you intend to ask. This helps you to stay focused.

#### 4. Capture and review findings <a href="#id-4.-capture-and-review-findings" id="id-4.-capture-and-review-findings"></a>

After testing, bring the team together to review what was learned. Look for:

* repeated issues or patterns
* differences between user groups
* assumptions that were challenged
* ideas that clearly worked or failed

Capture findings in simple language that others can understand.

Refer back to the guidance on [Analysing research findings](https://govstack-global.atlassian.net/wiki/spaces/GH/pages/1669464107)

<figure><img src="/files/s8DvOqzjKAJjg4Mat7Nv" alt=""><figcaption></figcaption></figure>

#### 5. Decide what to change or test next <a href="#id-5.-decide-what-to-change-or-test-next" id="id-5.-decide-what-to-change-or-test-next"></a>

Use what you’ve learned to decide:

* what to improve or change in the prototype
* what assumptions need further testing
* whether the current direction is strong enough to continue

Testing is most effective when it feeds directly into iteration.

</details>

<details>

<summary><strong>Research operations (supporting guidance)</strong></summary>

Research operations enable safe and repeatable testing but should be lightweight and proportionate.

Teams should consider:

* informed consent and participant understanding
* safeguarding and data protection requirements
* secure storage of notes and recordings
* clear ownership of research activities

Not all services require the same level of formality.

</details>

<details>

<summary><strong>Outputs</strong></summary>

* [ ] notes or summaries from user testing sessions
* [ ] identified usability, content, or flow issues
* [ ] clear changes made as a result of testing

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://specs.govstack.global/implementation-playbook/implementation/design-service/3-testing-and-validating-the-service/3.2-conduct-early-usability-and-inclusive-testing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.