# Testing Plan

## Overview

Before moving into full implementation, it's important to **test** whether your proposal works in practice—and whether users actually want or understand it. This tool helps you define a simple testing plan by clarifying four things:

* What do you want to learn?
* What are you going to test?
* Who will you test it with?
* How will you carry it out?

Testing doesn’t need to be complicated. Even a simple sketch or conversation can help you spot flaws or improve your idea. The key is to test *early and often*.

{% embed url="<https://docs.google.com/presentation/d/17nR2Ngj-dtty_uMFjZNUkbbccm3X2c5_vm9NmHSv5yc/edit?usp=sharing>" %}
[Open in Google Slides](https://docs.google.com/presentation/d/17nR2Ngj-dtty_uMFjZNUkbbccm3X2c5_vm9NmHSv5yc/edit?usp=sharing)
{% endembed %}

{% hint style="info" %}
**⏱️ Time:** 45–60 minutes (to create the plan)

👫 **Participants:** Core team (especially those who will help run the test)

🛠️ **Materials:** Testing Plan template, your service concept, journey or storyboard, persona
{% endhint %}

## Input

Before completing this canvas, ensure you have completed the following steps:

{% content-ref url="/pages/UCNPTpLQZVD4FdAEW3bm" %}
[Service Concept](/publicservicebooster/design-steps/5-design-what-ideas-could-address-the-challenge/service-concept.md)
{% endcontent-ref %}

{% content-ref url="/pages/xWCePP2HIrOH4zDuUXn7" %}
[Tomorrow's User Journey](/publicservicebooster/design-steps/5-design-what-ideas-could-address-the-challenge/tomorrows-user-journey.md)
{% endcontent-ref %}

{% content-ref url="/pages/hC1036MQHlNMljLvKikB" %}
[Tomorrow's Business Process](/publicservicebooster/design-steps/5-design-what-ideas-could-address-the-challenge/tomorrows-business-process.md)
{% endcontent-ref %}

## Context

Use this tool after you’ve created a concept and visualised the user’s journey. It’s your last step before running a real-world test or presenting the proposal for approval.

The plan should be tailored to your **local context**—considering the users you serve, the environment where the service takes place, and the resources realistically available to you.

## Recipe

{% stepper %}
{% step %}

#### Set your testing goal

What is the purpose of this testing?&#x20;

* To align internally or explain the idea? (Do we internally agree with the direction? Do users resonate with the benefits?)
* To improve the details or flow? (Adding detail to the prototype. What needs improvement?)
* To get real-world evidence? (What is the evidence that users will want to use this initiative?)
  {% endstep %}

{% step %}
Define your prototype or action

What will you actually use to test? Depending on the purpose of your testing, choose which prototype you will use. Choose something you can create **quickly** and **cheaply**, but that still gives you insight.

<table data-full-width="false"><thead><tr><th>Prototyping for getting aligned</th><th>Prototyping for improvement</th><th>Prototyping for evidence</th></tr></thead><tbody><tr><td><ul><li>Concept sketches </li><li>Concept descriptions</li><li>Storyboards</li><li>Journey maps</li><li>Paper prototyping</li></ul></td><td><ul><li>Cardboard models </li><li>Lego mockups</li><li>Role plays</li><li>Service blueprint</li><li>Simple videos</li><li>Interactive mockups</li><li>Landing pages</li></ul></td><td><ul><li>Rented spaces with basic elements</li><li>Functional prototype</li><li>Quick service experiment</li><li>Video-adverts</li><li>Real site in beta with limited access</li><li>A/B testing with functional prototype</li></ul></td></tr></tbody></table>
{% endstep %}

{% step %}

#### Choose your users

Looking back into the [persona](/publicservicebooster/design-steps/3-understand-what-is-happening-now-and-why/persona.md), [user characteristics](/publicservicebooster/design-steps/2-engage-who-are-we-designing-for/user-characteristics.md) and [stakeholder map](/publicservicebooster/design-steps/2-engage-who-are-we-designing-for/stakeholder-map.md), who do you want to get feedback from? Think about:

* Relevance (are they likely to use this service?)
* Diversity (different user types?)
* Access (how will you reach them?)
  {% endstep %}

{% step %}

#### List your resources

What do you need to carry out the test? (e.g. time, staff, materials, location, equipment)
{% endstep %}
{% endstepper %}

## Results <a href="#results" id="results"></a>

A clear and actionable test plan that your team can implement, to align, improve, and validate your idea.

## Tips

* Start small: what’s the **minimum viable test** you can run?
* Don’t wait for perfection—test early and refine
* Test with real users when possible, not just your team
* Capture not just what people say, but what they do
* Use simple formats—sketches or printed storyboards are often enough

***

### [Share Your Experience](https://padlet.com/opsi/innovation-booster-collaboration-lmuadp5wornnbo86)

We'd love to hear how you're using this tool! Please share your examples and feedback to inspire others and help improve the Booster. Submit your example today and be part of our community.


---

# 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://oecd-public-service-innovation-b.gitbook.io/publicservicebooster/design-steps/6-test-would-the-idea-really-work-in-the-real-world/testing-plan.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.