Overview
Product teams leverage design testing to understand the value of a new or improved feature before releasing it to the market.
While this is important for all types of products, it has special implications in product-led growth models. In PLG companies, the product needs to be really easy to use. It requires massive user discovery, although users don’t really expect guidance.
The problem many companies face today, is that not many users want to jump on a call. With everyone jumping to full-time remote, customers already spend their days in back-to-back video calls. But we need their feedback.
The solution? Turn your user research async.
When to use the Design Testing Playbook
In this guide, we walk you through the steps to run an asynchronous design testing.
Before we jump in, we want to be clear we’re not advocating you shouldn’t speak with your customers! You definitely should have as many live user sessions as you can.
The beauty of async testing is that you can use it alone or in parallel with more traditional methods. The hours you have available to meet with customers is limited, but with Claap you can get feedback from your entire user base!
Let’s start.
How to get started
Give context and be clear on your ask
Start recording by giving context on the problem, what you will present, and how can your users contribute. Take this example from Sean, our Product Designer:
- He creates a few slides to give context before showing mockups
- Sean mentions in the description of the claap that he added some polls to facilitate the feedback
Ask for feedback on upcoming features
It’s time to get some feedback! Use video annotation and polls to ask two types of questions:
- General feedback: ask a general feedback about the problem and whether the new feature addresses it.
- Vote on design options: ask your users to vote on different design options. It helps us pick the right solution.
Engage with discussions and keep your users updated
Some power users have a clear idea about what they need and what they don’t need. Exposing our prototypes in advance let them share their views in context. It often helps us identify points we didn’t expect in the first place, or explain why we chose this option in the beginning.
One of our best design change actually came from such community feedback.