# 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>