A Practical Guide to Remote User Testing

A Practical Guide to Remote User Testing

As designers, we know that we should be testing our products all the time, but toward the end of a project, we often prioritize production over research. When the post-it and whiteboard days are behind us and the project is well underway, it can be tough to step away from the text editor and make time to talk to users. Here are some things you need to remember when getting started with remote user testing.

Make it happen

People are hard to pin down. They make plans, then cancel them. They show up late, or sometimes not at all. Coordinating online meetings with users in remote locations brings in a whole new set of time zones and schedules. It’s important to acknowledge this issue from the start and be proactive about planning. In the first week of a recent project, I started a discussion with the client about user testing. It took over a month of back-and-forth with the client and the users before the tests were held. It is the shared responsibility of you and your client to set this process in motion. Don’t say you never got around to testing because of scheduling.

Get the right tools

Don’t hold a failed user test or fail to hold a user test with the excuse that you didn’t have the right tools. Make sure you have:

  • A screensharing program. I chose GoToMeeting. Other options include Fuzebox or Google Hangout.
  • A phone and a call recording program. I used Skype and Ecamm Call Recorder. With GoToMeeting, it is possible to communicate via built-in microphone, but to avoid “Is this thing on?” situations, I decided to talk over the phone instead. Again, if we are trying to be conscious of blockers, don’t let a user test fail because the participant didn’t know how to use the microphone or didn’t have one. Calling someone on the phone is a much more normal human action than navigating a foreign software program. Make it dead simple for everyone involved.
  • A note taking plan. While there’s nothing wrong with pencil and paper, a digital tool will let you store and share your research. Evernote is a good option. You can create an individual account and provide the login info with your team, or take advantage of the group sharing capabilities of Evernote Business. And just like that, you’ve started your own searchable feedback database; you’re on your way to Connected UX.
  • Sound editing software. I started out using Audacity, but turned to Adobe Audition. This will allow you to create sound bytes to share with your team.

Diversify your feedback

This certainly was not the first time that our team had solicited feedback on the product. Before this round, we did usability testing with participants that we recruited via Craigslist, and throughout the project, we gathered feedback from the “Contact Us” page of the site. Set up a tool like Intercom early in the life of a product and make sure you are given admin access so that you can read through the support threads. Ask for access to Google Analytics and other systems so that you can go digging through what’s been happening at the client’s organization.

Empathy isn’t just a design buzzword

Only by hearing users' authentic feelings about the site did I truly understand the problems that needed to be solved. For example, two people with whom I spoke told me they were the only members of their families with diabetes, and they wouldn’t know what to do without the support from this online community. Their comments let me know to prioritize communication and relationship-building among members of the site. These tests also energized me. With the project well past the ideation phase (a year in the making), there sometimes seemed to be an endless stream of bug fixes with little room for creativity. Talking to users was a welcome step back from the technical side of design, and it reinvigorated my belief in the product’s value.

Haters gonna hate

Active users are usually the ones that volunteer for these tests, and as such, the feedback is largely positive. Some might say that leaves you with an unbalanced view of people’s reaction to the site. Sure, seek out those users who made accounts and never came back. It’s important to remember, though, that the ones who use and enjoy the site are the lifeblood of the product. Listen to them. However, don’t put too much stock in any one comment. You can’t add or eliminate a feature based on one user’s opinion. As Steve Jobs said, “it’s not the customers' job to know what they want.” Look for patterns, and use what you discover to back up your own convictions.

Don’t wait to test new things

Our team was very close to completing a feature that would expand the user’s profile, but it wasn’t quite ready. Instead of waiting for it to be coded, I showed a mockup, asked if it was clear how to get to the page and if they would use the section. At that moment, this was the best representation of the design, and not showing it because it wasn’t “done” would have been a missed opportunity. Show what you have in exactly the state that it’s in. Insights from real users at this stage can guide you on the right path before wasting time, money and effort to rework the design.

Lydia Damon Designer

Hound reviews Ruby and CoffeeScript code for style violations and comments on your GitHub pull requests. Free for open source repos.