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

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

---

Criteria for success for to-be

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

---

Run a test and learn workshop

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

Day 1 – Focus and prepare

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

Day 2 – Test with users

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