---
title: A Practical Guide to Remote User Testing
teaser: How to proceed when you aren't in the same room.
tags: design,playbook
author: Lydia Damon
published_on: 2013-10-31
---

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](http://www.gotomeeting.com/).
  Other options include Fuzebox or Google Hangout.
* A phone and a call recording program. I used Skype and [Ecamm Call
  Recorder](http://www.ecamm.com/mac/callrecorder/).  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](http://evernote.com/) 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](http://evernote.com/business/).  And just like that,
  you've started your own searchable feedback database; you're on your way to
  [Connected UX.](http://alistapart.com/article/connected-ux)
* Sound editing software. I started out using Audacity, but turned to
  [Adobe Audition](http://www.adobe.com/products/audition.html). This will allow
  you to create sound bites 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](https://www.intercom.io/) 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](http://www.google.com/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.