Design Thinking

Testing: What works, and what doesn’t

Design thinking in product development is all for nothing if you aren’t learning. For successful product development using Design Thinking, you must plan careful tests, identify what you want to learn, and organize feedback accordingly.

Empathy places the user at the center of our focus, and testing gives us the opportunity to prove the theory our solution proposes.

Testing is useless without a learning mindset and requires the resolve to abandon ideas when the evidence is clear.

There is never a single way to solve a problem.

Each prototype that we create represents a theory:

  • Perhaps this is how we will ease this pain?
  • Perhaps this solution is the most efficient?

And so, placing a prototype in the hands of real users allows us to learn whether we are addressing user needs by solving the right problem.

Testing in Design Thinking provides incremental value at low risk

There is no need to envision the entire customer journey or product roadmap. We make small, intentional, incremental improvements to a product or experience by testing each significant function.

When we conduct user research prior to ideating solutions, we listen to what our customers say they want to achieve and how they want to feel.

Engaging with customers during testing helps us prove (or disprove) our assumptions.

Perhaps our theory was wrong. Perhaps the customer’s description of their problem or need was wrong.

Testing a prototype, rather than releasing a fully fledged product to the open market, is the most risk-free way to scale businesses and product offerings.

Gathering useful feedback

Just as we remember that user research is not a prescriptive process where we suggest a solution and get opinions, we know that testing is not a product demo.

User observation is a process of learning about real interactions. This illustration depicts a product team who is standing back with a clipboard to watch the subject. The user is engaging with software on a laptop, and talking through their actions and thoughts.

Allowing a user to interact with a prototype means watching and asking questions, not displaying and demonstrating how to use it.

But that doesn’t mean we enter this blindly.

Allow the user to interact with and experience the solution. Ask them to walk through what they’re doing and why.

We aren’t asking to be graded or evaluated – we want to know how they are reacting, not how they are judging the experience.

Before launching a test session, we identify what it is we’d like to learn about the user experience, so that we know what to ask the user. We are not going to defend or be too attached to our solution while the user kicks the tires.

Empathy is constantly our guiding force: how does this user feel as they move through our proposed solution? We ask open-ended, open-minded questions and receive feedback in the same way.

How we go back and iterate

We are not going to solve this problem with our first swing. We don’t expect to, anyway. Product development is an iterative cycle of building and learning, so every chance to tweak some bit of the process is an essential opportunity.

During observation, the comments that users make will form new “How Might We” statements and hypotheses.

“I wish I could do this right here.”

“I was expecting that this button would lead to some other information.”

When the feedback becomes seemingly inconsequential, such as the choice of color, it’s time to realize that we are getting close to the actual solution. Yes, color is an important part of the customer experience, but if we’ve presented someone with the most direct way to solve the most pressing problem, we can move on to colors and button shapes later.

We don't launch a product until it has been validated. This illustration depicts a lightbulb, which represents a product idea, that has wings and is being launched by a pair of hands into the world.

This is when we know we have validated the idea to the point where it can be built and launched.

Now, product implementation can begin.

We follow a “release early, release often” philosophy. Rapid iteration is the name of the game. We believe that projects succeed more often with continuous communication, evaluation, and response.

At Revelry, we’ve optimized our workflows over 5 years and have developed a handful of bare-bones tools that automate repetitive tasks and produce software that can be delivered in usable, testable pieces every week.

Reach out to us today, and we will schedule a demonstration to understand your business and establish the fastest way to implement your ideas.