Testing prototypes helps keep our assumptions in check, and to see what aspects of prototypes do or don’t land for people who are the intended users.
The following information has been contributed from Ben Weinlick and Aleeya Velji as Think Jar Collective in the Social Innovation Field Guide found here:


It’s a bit scary to test prototypes
When lab teams test prototypes they often feel a little vulnerable when they go out, share ideas they are excited about and open themselves up to feedback and critique.
Be brave, be willing to be wrong, be humble
Being willing to have your ideas critiqued and challenged is a brave and humbling experience, but when embraced, will ensure ideas and prototypes improve so they have deeper impact.
Starting place for testing
If the majority of lab participants are new to labs and prototyping, then we recommend a couple testing rounds among lab participants first before going out into community to test them with people whom the prototypes are supposed to help. This approach will help with building confidence of lab participants to test prototypes humbly and be brave enough to take in feedback.

Getting Ready

Below are some things a lab team will need to think about to plan for feedback:
How should the team conduct the feedback sessions?
  • What kind of setting would be best?
  • What is the lab team going to test?
  • What feedback do we need in order to make decisions about the next stage of prototypes?
  • Who should test the prototype and give feedback: People the prototype is meant to help? Service designers or system leaders with domain expertise? A lab advisory group?
  • Is a large testing session with many people best?
  • Is small-group testing best?


Sometimes a prototype will be so coherent you can simply present it to people and it will be clear how to test it. Most often, however; a prototype needs a bit of an intro. Work with your lab team to clearly and succinctly explain and pitch a prototype.
When pitching a prototype try the framework below to help with communicating succinctly about a prototype:
  1. 1.
    Share clearly and succinctly what the challenge is that your lab team is trying to solve for
  2. 2.
    Share in a nutshell what the “big idea” of the prototype is
  3. 3.
    Share who the prototype is meant to help
  4. 4.
    Share the prototype and show what it is supposed to do
  5. 5.
    Share what the team at present thinks are possible next steps with the prototype


A simple feedback tool is to ask participants testing a prototype to offer feedback that falls within two categories. Feedback givers hear a prototype pitch and then say...
Have you considered the following ... and ...
Here’s an idea I have that might work to make the prototype better ...
Also ensure the lab team invites testers to ask clarifying questions if something about a prototype is unclear. Have a person record feedback. Alternatively, you could have testers write sticky notes on Considerations & Ideas that might work.


Post-Test Reflections
Once you have conducted testing and feedback sessions, it is important for the lab team to reflect and capture what was learned.
Below are reflection questions to use after a testing session. It is good to reflect as soon as possible so that important insights are not lost.
  • What did participants really like about the prototypes?
  • What got people excited?
  • What pieces seemed to be most important to them?
  • What parts would participants like to improve?
  • What didn't work?
  • What needs further research?
  • What ideas do I have to improve the prototype based on this session?
Feedback on prototypes helps a lab team to make decently informed decisions about what to do next. After reflection, a lab team needs to make decisions on what to do with each prototype.
  • Discard? Team decides it’s not worth continuing.
  • Evolve it: Adapt or tweak the prototype in some way - get more user feedback?
  • Graduate to Pilot: Team and stakeholders feel positively enough to formally pilot.
  • Go to Scale: The test results and feedback are so positive that the team is ready to scale without further testing.
  • Keep Testing: The testing results weren’t strong enough to make any decisions at this time. Upgrade the evaluation design and try again.

Desirability, Viability, Feasibility

The following content has been contributed by Roya Damabi from Alberta CoLab.
Innovators must be willing to completely change or remix their proposed idea based on the feedback they receive. This is easier to do when a prototype is grounded in what people actually want and need, rather than what an innovator wants to deliver.
What people actually want is the primary criteria against which innovators must test their prototypes. This criteria is called desirability. Iteration enables innovators to test their prototypes for desirability and two other important criteria: viability and feasibility.
  • Desirability: Is the proposed solution something that people actually want?
    • Test whether the solution solves the right pain point or challenge.
  • Viability: Is the proposed solution sustainable over the longer term?
    • Test whether it is financially and operationally possible for people or organizations to implement the solution.
  • Feasibility: Is it possible to implement the proposed solution?
    • Test whether the technology and capabilities exist to implement the solution.
Prototypes that are desirable, viable, and feasible – that achieve the ‘sweet spot’ – are more likely to create the desired change when implemented.
Innovators can brainstorm hypotheses related to each of these criteria, and design ways to test these hypotheses through iteration.
As iteration and learning happens, each round of prototyping builds on the one beforehand and aims toward greater fidelity.
To read more about Fidelity click below: