RemoteWorks

How we do async design research at Claap

A step-by-step playbook to validate your design specs efficiently

Sean Tiffonnet

You’ve worked to create a product you think users will love and build features they'll use every day. You launch it and then realize this killer feature actually goes unnoticed.

This is what happened with our system of video annotation. Users that saw it loved it but most of them missed it.

We knew we had to re-design the cursor and improve the product to make our commenting system more obvious.

But how could we reduce the risk of building something that wouldn’t work?

Design research with our users seemed like a great option but they’re hard to schedule. It can take weeks before having enough feedback from users.

So we decided to go with another option: async design research.

What is design research

Pushing developers and designers to sacrifice quality and good design as a strategy for rapid delivery is costly. You end up shipping a feature your users won’t use because of its quality, having no learning at all, and re-do the whole work again.

Instead of spending time developing a feature you’ll have to improve, design research helps you validate your concept and prototype among your users even before starting to write the first line of code.

How to do async design research

1. Present the context & objective

Before jumping to the solution, it’s important to present the context and objective of the research. We like to have one slide (in Figma) that presents those elements at the beginning of the video.

In our case:

  • Context: many users don’t understand that when you click on the video you create a new comment. Instead, they think that you can pause the video because of regular patterns like Youtube or Netflix
  • Objective: Make it more understandable that when hovering the claap, you can leave a comment

To make the context super clear, we also show the existing feature during the recording. And I’m pretty sure you didn’t notice the cursor 😉

2. Present the different solutions

Once the context is clear, it’s time to present your different options. In our case, we like to do it in 2 steps.

First, we introduce the different options and their behavior so that users understand clearly what we want to validate

Then, we show those different options in a real environment so that users have a better idea of what it could look like.

3. Ask users to vote on their preferred option

The goal of design research is to gather user feedback. To make sure users really give their feedback, we’ve noticed that it was much more efficient to clearly ask when we expect their feedback.

We like to have a slide or a view that clearly indicates the different options we want to test and ask users to vote on their preferred one with an option. (note: we now have the possibility to add polls to do that).

As we also wanted to validate if the zoning system was clear enough, we also asked a second question where users could also add their feedback. This is how we actually came up with the final solution that was brought to us by Victor, one of our users.

4. Wrap up

Once we decide on the final option, we like to inform the participants what choice we made and thank them. We realized that those design research sessions were actually a really good way to engage our community and create more champions!