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.
| 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 | 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 |
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.
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) |
GovStack facilitators |
| 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 |
| 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 |