Here’s a question: when did you last use user feedback to iterate on your design three times in a single day?

It’s understandable if you haven’t. User testing is kind of a pain. Recruiting people, finding a location, writing notes, sharing learnings — it’s a time sink. No matter how important we tell ourselves it is, it’s easy for it to get postponed, or even abandoned, when time’s tight.

Enter video testing, the most indispensable design tool I’ve come to rely on for UX and design. In my last three jobs, testing has been a crucial — sometimes only — source of user feedback, allowing me to 10x the frequency with which I could get game and app prototypes in front of users.

It’s pretty simple to use.

You write instructions, which can be specific tasks or more general, such as “play it and think outloud”. Then send it along with a build or prototype to a testing service. Some time later — maybe as little as half an hour — you’ll get x video recordings back of someone playing your game and answering your questions. Watch and share at your leisure.

But remote testing isn’t just a case of making my life easy. The impact goes deeper than that — straight to my core values of how to build great products.

Remote is super agile.

It takes so little time to set up, taking care of recruiting, compensating and recording users. It removes any logistical faff, and doesn’t take up time from multiple team members. You can decide to test in standup and have results by lunch. As often as you have changes, you can test them — and you can iterate on your test script or audience screeners equally fast. If you value fast iteration, you won’t find a better method.

Remote testing can get you the right testers.

Testing in-person means finding people, and that can mean relying on those who live nearby and are free on a weekday, strangers in a coffee shop or even family and friends. Do these people really represent your target players?

Remote testing means you can get your game in front of the right users. Need testers in the US age 24–30 who play mobile games 8–15 hours a week? Easy — set the demographic criteria, add any screener questions and get testers who haven’t seen your game before. Didn’t quite get the right people? Tweak your screeners, run it again. If you know who your target audience is, you should be testing on them.

Testing for everyone!

With a bit of intro and some sample questions, anyone in the team can start running tests, and anyone can see the results. Understanding how players interact with our games shouldn’t be the sole responsibility of designers or researchers — having the team involved, and seeing first hand the impact of changes, is infinitely more powerful than reading a test report doc. Instead of relying on one person’s interpretation of what users says, the team can get together and give different perspectives. It helps put product direction in the hands of the team, and brings them a step closer to the player.

It does have a few limitations…

You can’t react to the user, digging deeper into what they say or nudging them along when they get lost in the test. There’s some tech and logistical limitations — multiplayer is tricky, creating test accounts can be fiddly for online play, and things that require more in-depth sessions (more than 20 minutes) might be off limits.

Remote playtesting may not be suitable for every game, or at every stage of development. But when it can be used, you’ll be able to accelerate your learning and iteration so fast that you’ll wonder how you ever managed without it.

Source link—-138adf9c44c—4


Please enter your comment!
Please enter your name here