3. Test early and often

This standard is linked to the following Principle for Digital Development: Design With the User.

We test things to reduce the risk of failure later on. Every product or service is built on a series of hypotheses and assumptions. The larger the assumption, the more likely it needs to be tested. For instance: 

  • Desirability —  Do users want this? Are we meeting their needs?
  • ViabilityCan we create enough value that people will use it? Can the solution exist in our local context?
  • Feasibility  Can we legally do this? Can this be built with available technology? Do we have a third-party company that can provide this solution for us?

We test by creating simple prototypes. These can be as simple as a series of sketches or a design prototype made in a tool such as Figma. Prototyping tests your ideas in real life-context instead of describing your solution. 

The feedback you receive from testing prototypes can help you make better decisions about your product and service without the time-consuming and expensive route of building the entire product up front. 

The typical process is: Idea → Build → Launch → Learn.

Prototypes can help skip the build and launch phases, and you can go straight from Idea → Learn. 

Testing should then be done repeatedly in your project lifecycle. Building a digital product or service needs continuous user feedback to ensure you are launching the right solution. 

Be prepared to be wrong. Stay open to changing your original plan based on feedback. If things don’t work, iterate based on user feedback. Changing and testing a prototype is much faster and cheaper than doing so with a real product — so use this opportunity to prototype and learn!

"If a picture is worth 1000 words, a prototype is worth 1000 meetings." Tom & David Kelley

 

Do:

  • Base your decisions on actual user data and feedback
  • Create prototypes before building anything
  • Gather feedback on early ideas from at least 5 users
  • Create a list of your assumptions
  • Test any existing solutions you plan to use to make sure they can be adapted
  • Conduct usability testing to ensure you understand how the solution can be improved before, during, and after going live (launch)
  • Start small and leave room to iterate and re-evaluate decisions 

Don't:

  • Base your decisions only on managerial opinions
  • Ask leading questions during usability testing
  • Test functionality without the users
  • Overtest: focus on the most important parts of your solution

Tools

 

To Watch

 

To Read

 

Case Studies.

  • M-Pesa: A Case Study in Financial Inclusion  Providing financial services to those without bank accounts is a significant challenge. Read about how the company behind M-Pesa, a phone-based money transfer service started in Africa, pivoted their initial idea after seeing how people used their product during a pilot. Millions of people now use it to deposit money into an account stored on their cell phones, send balances using PIN-secured SMS text messages, and redemption deposits.
  • IOM Pre-testing guide to their communication for development campaign