This is part 7 in a series exploring design thinking in strategy development. If you are just joining, I encourage you to start at the beginning and read part 1 here.
Why We Test
Everything is nearly complete: you have gained empathy for your customer, defined the problem, developed numerous solutions and built a prototype. However, you’re not quite done yet. The last piece of the puzzle is to engage in real-time, focused, real-life testing. Testing should not be rushed or thought of lightly. In fact, it is THE most important stage of the design thinking process.
There are three key reasons to test (Stanford d.school):
- To refine solutions by informing the next iteration of a prototype, even if it means going back to the drawing board
- To accelerate the learning process by providing additional opportunities to learn about users, often through deeper engagement and observation that yields unexpected insights
- To reveal instances where individuals or teams failed to frame problems correctly, which may invalidate favored solutions
Testing and Prototyping
Testing and prototyping should be done in an iterative fashion. When your prototype is ready, solicit users for feedback, revise your prototype and repeat. Through this process, you are continually engaging with your users to understand the things that they like and what they don’t. Your users are a critical part of the process since they will be exposed to your product or process day in and day out.
So, how do we go about testing? Let’s get into the nuts and bolts.
How to Test
Testing doesn’t have to be extremely complex or involved. Your approach to testing can be as simple as having some users run through a new process and asking for their opinion. You will want to show, not tell, the users by letting them come to their own conclusions. Then use the observation skills you picked up in Part 3 of this series.
5 Guidelines for Planning a Test
- Let your users compare alternatives. Create multiple prototypes, each with a change in variable, so that your users can compare prototypes and tell you which they prefer (and which they don’t). Users often find it easier to explain what they like and dislike about prototypes when they can compare, rather than if there was only one to interact with.
- Let your users experience the prototype. Avoid over-explaining how your prototype works or how it is supposed to solve a problem. Let the users’ experiences using the prototype speak for themselves and observe their reactions.
- Ask users to talk through their experience. When users are using the prototype, ask them to tell you what they are thinking. This may take some getting used to for many users. It might help to chat about an unrelated topic, then prompt them by asking questions such as, “What are you thinking right now while using the prototype?”
- Observe. Observe how your users use — either “correctly” or “incorrectly” — your prototype, and try to resist the urge to correct them when they misinterpret how it’s supposed to be used. User mistakes are valuable learning opportunities. Remember that you are testing the prototype, not the user.
- Ask follow-up questions. Always follow up with questions, even if you think you know what the user means. Ask questions such as, “What do you mean when you say … ?”, “How did that make you feel?”, and most importantly, “Why?”
How to Respond to Negative User Feedback
Hopefully, your users will give you insight into your prototype. This may come in the form of negative feedback. Don’t shy away from it. You can learn a lot by observing how users struggle with your prototype or by listening to what they don’t like. It is the tester’s job to learn and revise. Also, don’t be afraid to scrap everything and go back to the drawing board. It is common to be completely off base with your prototype, and it is cheaper to find out now than after a multi-million-dollar implementation. As a culture of design organization, you must embrace failure as a method of learning.
Scaling and Implementing
When you’ve completed testing, your next step is to scale and implement. You are finished testing once you feel you’ve gathered the desired insights. This could be in the form of the users’ feedback being mostly positive or when you have achieved optimal efficiency in the process. You most likely have also learned that some ideas were not valid at all, in which case you’ve just saved your organization a lot of money by not implementing them.
The last installment in this series, Part 8, is likely the most controversial. There are a lot of buzzwords floating around regarding Digital Transformation (DX). My goal is to give you one perspective on digital transformation and the people who are critical to completing a successful DX initiative. Until then, if you have any questions, just ask our experts.
