Design thinking — testing the solution in the ‘Implementation’ phase
In the Implementation phase, we should have roughly a dozen concepts as outputs of the Ideation phase and will need to select among them by getting the actual customers involved. As outlined previously, design thinking is termed a customer-driven approach, for two reasons:
- The deep study and understanding of customer problems in the Inspiration phase, and
- The understanding of the way these customers interact with the proposed solutions in the Implementation phase
In the Inspiration phase, knowledge was built through detailed observations. In the Implementation phase, knowledge is built by experiments that involve:
- Designing and building prototypes as solutions — on the one hand — and
- Running interactive prototype tests with the customers — on the other
Therefore, the implementation phase is mainly about solution validation by testing underlying assumptions and gathering feedback from the customers on the solutions. The concepts generated after the Ideation phase are based on the customer insights that were gathered during the Inspiration phase. These insights are based on intuitive thinking, relying on assumptions about customer behavior and what they value or dislike that need to be validated.
The Implementation phase is based on three pillars:
- Assumptions: identification and selection of
- Prototyping: design and building
- Experimenting: design and execution
Iterative testing loops are a crucial part of the Implementation phase. Each experiment generates knowledge that may require further prototyping and experimentation to be validated. Each test and iteration loop converts an assumption into validated knowledge. For a successful implementation phase we will need:
- Frequent iteration cycles
- Prototype development
- Customer testing
- Constant learning from prototype iterations and testing
Step 1 — outlining the assumptions
For each solution or concept developed, there are three key assumptions:
- The pain or the dissatisfaction to be addressed
- How it is to be addressed — i.e. what is the overall solution
- How the customer benefits from the solution
One method to identify the underlying assumptions is to analyze the solution with detailed critical thinking. This means we need to thoroughly analyze how the solution is delivered and how the customer will benefit from it. This can be done in the following ways:
- Using a storyboard of the solution
- Using a journey map of the customer including the solution
- Using a usage scenario of the solution
For example, with a journey map, you have to go through it step by step, each time checking what could cause the solution to fail — a potential flaw is an assumption that is not validated.
Compared to the Inspiration phase, the thinking in this step is analytical, precise, and critical rather than intuitive and supportive. The team mindset is non-tolerant, questioning, and challenging. In this step, the team needs to be made up of new members who carry spectacles of skepticism with them. They will have the mission of challenging every detail of the solution.
Here are some trigger questions that can help you identify assumptions and potential flaws.
- Why will the solution benefit the customer?
- How much time, effort, and/or money do customers have to put into the solution to benefit from it?
- Does the solution involve other stakeholders or third parties to fully benefit the customer?
After the identification of the solution assumptions, we need to classify and cluster the assumptions based on their criticality. A critical assumption is one that if it is not validated, will result in the biggest flaw in the solution. We will start by testing the most critical assumptions that can have the largest impacts on the project.
Step 2 — prototyping
Once the assumptions to be tested are identified, we’ll need to identify the data needed to test the assumptions; the data either already exists or you will need to create it, and this is where prototyping comes to the rescue.
A prototype is a way to materialize and test an assumption
The most crucial principle of prototyping is:
Fail often and fail fast — John C. Maxwell
In the principle above, the word ‘often’, means testing a high number of prototypes, and therefore, we need to keep costs low. The experiments need to be low-risk also as we have to control the potential impact of the experiments, such as their impact on the image of the company. The word ‘fast’ means that the prototype will not be very detailed, because, in the early stages, many elements and features will be missing. In other words, the principle above results in building low-cost, low-risk, and rough prototypes.
Two additional positive side effects of ‘failing often and failing fast’ in prototyping are:
- It reduces emotional attachments. Suppose the team spends a lot of time building the prototype. In that case, they will become attached to it as it equates to hours of effort and dedication and this will in effect result in a loss of distance and critical thinking required to understand or listen to customers’ feedback if they challenge the solution.
- It enhances customer feedback. Customers tend to refrain from providing critical and honest feedback about a detailed, almost developed product or service, as humans are social creatures and tend to be empathetic towards others’ emotions. However, a rough prototype will signal a work in progress and customers will feel that they are co-creating with the team, offering constructive and critical feedback.
In prototyping, we are testing assumptions and in this phase, a failure or invalidation of an assumption, represents a very valuable piece of knowledge — that the feature/prototype was not satisfying customer needs — but at least we know it before launching the product and hopefully, we know the reasons, so we can design a better version. It is better to have this knowledge through a prototype than through a complete, real offer that requires a large investment in time, effort, and money.
I have not failed. I’ve just found ten thousand ways that won’t work — Thomas Edison
An additional goal is to test assumptions separately and to design one prototype for each assumption, rather than to group assumptions, making the prototype complex to build. When building a prototype ask the following questions:
- What do I want to learn by testing this prototype?
- What’s the simplest pass/fail test I can run to do so?
Such a mindset will result in the development of a prototype more commonly known as a ‘minimum viable product’ or MVP, emphasizing that a prototype has to focus on a feature to test, while providing an experience to the customer. In the case of digital and software solutions, agile methodologies such as Scrum can be adopted to develop such prototypes as they enable numerous iterations and frequent short design cycles.
Startup environment
In a new product development or a startup project, the prototype is used to test the feasibility, desirability, and viability of the solution in mind. A prototype is a low-cost, low-risk, and rough artifact that aims to test the waters. Taking into account that in a design thinking project, and more importantly in a startup, desirability prevails over feasibility and viability, the objective will be to test whether there is a market opportunity or not. In other words:
- Does the offer address a problem or a need?
- Will it create a desire leading to a market?
Step 3 — Experimenting
In the experimentation step, we will engage with potential customers to learn about their experiences with the solution. We need to:
- Select the appropriate customers
- Engage the customers with the prototype and choose the context in which they will interact with the prototype
- Run the experiment, and capture all of their feedback
Selecting the customers
You will need:
- Customers that you can trust, because you will be showing a very rough, incomplete, and unpolished version of your solution
- Customers who are willing to provide time and effort and are interested in taking part in your design process
- Customers who are conducive to such an approach and have the required mindset
- A diverse set of customers, to diversify types of interaction and feedback
Engage the customers with the prototype
Depending on the context of the problem, the prototype can be a storyboard, a poster, or a journey map, showing how the solution works. The focus here is on the accuracy of the feature to be tested to stimulate constructive feedback. It’s alright to show unpolished and unfinished versions of the prototypes but show as many as you can so you can gather as many responses as possible.
Running experiments and capturing feedback
To engage in fruitful discussions, customers need to feel comfortable using and manipulating the prototype. This can take time, be patient, do not rush them, answer questions with questions, and do not sell the prototype, they need to feel that you are listening and interested in what they think, feel, and say, they need to feel that you are open to their feedback, and you care about what they are saying — you need to project a collaborative mindset.
Additionally, to learn from the customers, you can record their voices or videos to capture their body language and facial reactions. Have a team of two people, one asking follow-up questions to stimulate feedback, and the other taking detailed notes. The person conducting the interview is preferably not a member of the concept development team, because of emotional commitment biases, potentially being tempted to sell the concept. Do not run focus groups or group thinking sessions and focus on single interactions and the customers’ unbiased emotions.
This is part of a 5 series article. You can find all the other articles here:
Hope you enjoyed reading this article! :)
If so, then:
- Follow me on Medium
- Become a Medium Member
- Subscribe to hear more
- Let’s connect on LinkedIn
