This piece was originally written for the Decision Support Tool, developed by The Systems School and Orange Compass.

Prototyping is a process we can use to test and refine an idea or response to a problem, a prototype is the actual ‘thing’ we are working to improve.  The value and strength of prototyping comes from the multiple rounds of testing and learning inherent to the process.  These rounds of testing and learning are called iterations. In each iteration we make assumptions about how the prototype will work, and then test the assumption to gather new feedback and insights. These insights are used to refine the prototype, gradually improving its quality and fit as a response to the challenge. 

Prototyping helps us bridge the gap between our first idea of what a good response  would look like, and fully implementing that idea. The emphasis is on rapid learning through small tests of change. In order to maximise how much we can learn in the time we have, our aim is to fit in as many iterations as we can, creating a series of prototypes, adapting each one to reflect the learnings from the last.

Prototyping as part of systemic change

Systems are more than the sum of their parts. They have emergent properties – characteristics and behaviours that arise when these parts are brought together. By introducing or changing a process within a system you are changing this combination of parts, and what emerges in response can be surprising and unpredictable. Making change within a system requires working with the system, paying attention to how the system responds and adjusting our approach accordingly.

When we find ourselves trying to make progress in complex systems where there is much we don’t know, prototyping can help us find our way forward. Organisational theorist Karl Weick argues that an emergent approach – observing and working with what arises from a system – is more useful for making progress in complex systems than a good strategy or map. He tells us that when people “begin to act, they generate tangible outcomes in some context, and this helps them discover what is occurring, what needs to be explained, and what should be done next.”

Prototyping for processes and services

When it comes to prototyping, you might have heard about Minimum Viable Product, or MVP. This is a well-known form of prototyping where you launch a good, small, simple version of a product so you can quickly get real feedback from people who use it, allowing you to iterate and add features that actually meet the needs and desires of the people you are creating for.

But how does this work when we are prototyping a service or process?

There are two different approaches that are useful for prototyping something less tangible, like a process or service: conceptual prototypes and experiential prototypes.

Conceptual prototypes test solutions, changes, or ideas using conversation or tools. These act as prompts that help us imagine what the changed process or service would be like instead of actually experiencing it. Conceptual prototypes tend to be low-fidelity, making them quick to create and easy to adapt. Examples of conceptual prototypes include:

  • back-of-the-envelope models

  • decision trees

  • diagrams

  • wireframes

  • storyboards

  • patient journey maps

  • process maps

  • paper prototypes

  • LEGO models.

Experiential prototypes provide a window into what it would be like if your idea came to life. Experiential prototypes are excellent for giving rich insights into how your idea, solution or change would feel and function if implemented. Examples of experiential prototypes include:

  • role plays

  • simulations

  • service walkthroughs

  • small scale, limited tests of a change in live service.

A good prototype helps us to learn quickly without overinvesting.  Your early prototypes will feel unfinished and look messy, but that is part of the iteration process. It is important to stop tinkering with your prototype once your changes stop being functional and are just making it pretty and presentable – it’s time to learn from it and continue iterating!

Learning from your prototypes

The true value of prototyping comes from what we can learn from the process. By testing a prototype we gather information about what happens when it encounters the world. This information allows learning to happen on two levels:

  • The first level is learning about your prototype itself – how well it meets needs and expectations, what the experience is like, how intuitive others find it.

  • The second level is learning from what happens when the prototype encounters the system you are introducing it into. Is this a hospitable environment your prototype can grow and thrive in, or is it hostile? 

In order for your idea to be adapted and successful longer term, some necessary conditions will need to be present or established – things like adequate buy-in, resourcing, leadership, policy, and authority. Learning where your prototype creates friction, is met with tension, or causes other parts of the system to pull back provides important insights on how to improve its fit within the broader system.

It is important to think about and write down how we anticipate the system will respond to a change before we actually test it. Having a record of our assumptions allows us to compare how the system actually responds to what we anticipated, learn from our test and strengthen our understanding of the system. Without a record, there is a natural tendency to assume the outcome is just what we expected and we lose the opportunity to learn from it.

During each prototype test, you will gather information about what happens so you can compare this to your assumptions, continue your learning and use the insight to build your next iteration. The type of information you will gather during testing depends on the prototype itself, the system you are testing it in, and what you are hoping to learn or confirm.

A good place to start is to think about your reason for introducing this idea or response. What do you think it will help you to do that you couldn’t do as well before? What signals would you see if this change is working as intended?

Ultimately we want our final approach to be successful and sustainable. It’s useful to gather information to learn if your change or solution is:

  • Feasible – Is it easy? Is it convenient?

  • Viable – Can this be sustained at scale? Is it desirable?

  • Attractive – Is this useful? Is this necessary?

  • Creating unintended consequences – Is this change just moving a problem from one place to another? Does it create new issues in other parts of the system?

When testing your prototype, you will gain better insights, develop stronger relationships, and build energy for change by involving people who have a role to play in delivering the solution or change in both testing the prototype and reflecting on your learnings.