# 3 Testing and Validating the Service

## Before you start test and learn

\
Before you start check you have:

* [ ] a clear understanding of which concepts, journeys, or assumptions they want to test
* [ ] one or more draft to-be journeys or service options to prototype
* [ ] clarity on what success or learning would look like from testing
* [ ] an agreed approach for involving users safely and ethically

If these conditions are not met, teams may need to return briefly to the To-be stage to refine options or reduce uncertainty before testing.

## Skills required 

<table><thead><tr><th width="374">Skill area</th><th>Details</th></tr></thead><tbody><tr><td>User research</td><td>Plans and runs user testing to gather evidence about what works, what doesn’t, and why.</td></tr><tr><td>Design (service, UX, or content)</td><td>Creates and iterates prototypes based on user feedback and learning.</td></tr><tr><td>Content design</td><td>Ensures language, structure, and guidance are clear, usable, and inclusive for users.</td></tr><tr><td>Accessibility and inclusion</td><td>Helps ensure testing considers accessibility needs and diverse user contexts early on.</td></tr><tr><td>Product or delivery</td><td>Keeps testing focused on learning goals and makes evidence-based decisions about what to take forward.</td></tr><tr><td>Service owner or policy representative</td><td>Provides domain knowledge and ensures emerging solutions align with policy intent and constraints.</td></tr><tr><td>Technical lead</td><td>Sense-checks technical feasibility and highlights delivery risks during testing.</td></tr></tbody></table>

***

## Criteria for success for to-be

<table><thead><tr><th width="374">Criteria</th><th>Evidence</th></tr></thead><tbody><tr><td>Prototypes have been built to support learning</td><td><p>Content and end-to-end flow have been tested</p><p></p><p>Prototypes have been tested with real users, and core concepts are validated or refined based on evidence</p><p></p><p>Prototypes have been tested with diverse users, and content issues are discovered and resolved</p></td></tr><tr><td>Accessibility validation against WCAG</td><td>Prototypes are tested for accessibility and refined to meet WCAG 2.1 AA</td></tr><tr><td>Clear MVP Scope and prioritisation</td><td>Features for the MVP are prioritised based on user value, feasibility, and test results</td></tr><tr><td>Iterative cycles documented</td><td>Iterations are clearly documented, showing progression toward expected UX quality</td></tr></tbody></table>

***

## Run a test and learn workshop <a href="#heading-title-text" id="heading-title-text"></a>

Teams often work in short cycles that involve building or refining a prototype, testing it with users, reviewing what was learned, and deciding what to change next. Below is an example of a rapid test and learn workshop however in practice you may decide to spend more time prototyping and interviewing users.

### Before the session (Preparation phase)

Recruitment and preparation should happen 1–2 weeks before the workshop days.

| Session         | Activities                                                                                                                                                                                                                                                   | Who to involve                                                                               |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| **Preparation** | <p>• Agree which part of the service will be tested (specific journey slice)<br>• Define learning goals and key assumptions<br>• Prepare low- or mid-fidelity prototype<br>• Recruit 3–5 representative users<br>• Confirm consent, logistics, and roles</p> | <p>GovStack facilitators<br>Service owner<br>Designer / content lead<br>Research support</p> |

### Day 1 – Focus and prepare

<table><thead><tr><th width="210">Session</th><th>Activities</th><th>Who to involve</th></tr></thead><tbody><tr><td><p><strong>Align on learning goals</strong></p><p><em>60 minutes</em></p></td><td>• Revisit assumptions and risks<br>• Agree clear research questions<br>• Confirm what success looks like</td><td>Whole delivery team</td></tr><tr><td><p><strong>Prepare prototype</strong></p><p><em>All day</em></p></td><td>• Refine prototype (avoid testing the whole service)<br>• Ensure realistic content and flow<br>• Prepare any supporting materials</td><td>Designer<br>Content lead<br>Service owner</td></tr><tr><td><p><strong>Prepare for research</strong></p><p><em>60 minutes</em></p></td><td>• Draft discussion guide<br>• Assign roles (facilitator, observer, note-taker)<br>• Run internal dry run</td><td>Research lead<br>Observers</td></tr></tbody></table>

### Day 2 – Test with users

<table><thead><tr><th width="210">Session</th><th>Activities</th><th>Who to involve</th></tr></thead><tbody><tr><td><p><strong>User testing sessions</strong></p><p><em>All day</em></p></td><td>• Run 3–5 moderated sessions (45–60 minutes each)<br>• Encourage think-aloud behaviour<br>• Capture structured notes</td><td>Researcher<br>Observer<br>Note-taker</td></tr><tr><td><p><strong>Group synthesis</strong></p><p><em>60 minutes</em></p></td><td>• Cluster findings into themes<br>• Identify repeated issues and breakdowns<br>• Compare findings to original assumptions</td><td>Whole delivery team</td></tr><tr><td><p><strong>Decide next steps</strong></p><p><em>60 minutes</em></p></td><td>• Agree what to change in the prototype<br>• Identify what needs further testing<br>• Decide whether confidence is high enough to move toward MVP</td><td>Product lead<br>Service owner<br>Designer</td></tr></tbody></table>


---

# 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/1.0.0-rc/implementation/design-service/3-testing-and-validating-the-service.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.