A template for Usability Testing

March 12, 2020

I’m always surprised by the number of designers who don’t test their products with real users. Most of the time is they don’t know where or how to start testing. Running user testing sessions is easy to do once you know how to do it. There are plenty of resources online that will help you become better at running them — I even link to a few at the bottom of this article. I’m not going to explain how to perform user testing, but I want to share a template that we use for performing user testing sessions. And also an example of the template being used in a project. TLDR; both links are at the bottom.

We run quite a few user testing sessions; in fact, we love running them, we’re addicted to running them. We try to run them as much as we can, and I created a template to help us become more efficient at performing user testing. And that is the template I’m going to share with you today.

This simple template has really upped our game in terms of running user testing.

The template in its raw form. Click here to view the live version.

The benefits we’ve experienced are:

It helps us prepare by stopping us from procrastinating when we’re getting ready for a user testing session. You know that feeling of “oh shit, where do I start?”, well it helps us say goodbye to that.
It helps us be more consistent in how we perform user testing. It is a process after all, and processes should be repeatable.
It dramatically speeds up the time it takes for us to review results. No more, “I need a few hours to transfer my notes that I wrote down into an online version”.
And if we’ve got the results quicker, we can make decisions faster.
Lastly, it is a source, a record of what we did, and what the outcome was. This allows us to share findings with teams for future projects. And we can even share these docs with stakeholders, and because we keep them brief, people actually read them.

Ok so enough nonsense about how bloody great it is, and more about how to do I use it.

‍

How we use it

The best thing about the template is how easy it is for our team to use to run user testing sessions efficiently. Before I’m But first, let me explain how we run moderated user testing sessions.

For all user testing sessions, we require two rooms:

The interview room: is where a member of our team will perform the user testing with an interviewee, we set up the room so that we record not only the interviewee’s device but also a video with audio of their reactions.

The “control centre” room: is where the rest of the team will watch the interview on a big screen, but we can also use our Macs. This set up allows us to observe and takes notes without distracting the user.

Most of the time, our user testing sessions last roughly 30 minutes, we believe that you can learn a lot in that short period and not fatigue the interviewee too much. Plus people have busy lives, and we respect that they want to get back to living their lives.

Ok so now you know how we run them, I’ll explain how this template helps us prepare and perform better user tests.

‍

Before the test

You must spend a bit of time preparing your user test. This doesn’t have to be days or weeks, but you need to do some if you don’t want to waste everybody’s time. By preparing you’re showing respect for people’s time, not preparing is the opposite, you’re just taking the piss.

By failing to prepare, you are preparing to fail — Benjamin Franklin

When we prepare for user testing by adding the following details to our template:

Goals: We always start with a concise high-level goal that we want to achieve during our user testing. Just saying that “we want to perform user testing” is not a goal, the goal should be what you want to learn from the user testing session. The goal should be easy to understand and easy to communicate to the broader team.

Questions: Next, we define the questions that we would like answered, answering these questions should help us achieve our goal. These might be sprint questions if you’re performing a design sprint or they might be questions related to a prototype.

Method: We briefly define how we will perform our user testing session. Is it moderated or unmoderated, in-person or remote, performing tasks or just a chat, whatever it is, we define it.

Participants: We define the users who’ll be performing the session. For each participant, we try to get a little bit of information about them that will help us make the session more natural. Just enough is better than too much.

And lastly, the nitty-gritty details:

Date performed: The date and time of the user testing.

Researchers: Who will be performing the user testing and what their role will be during it.

Project: A link to the project docs, this could be a confluence folder, google doc, or whatever. This if someone wants it at a later date.

Prototype: A link to the prototype for easy access.

Meeting: A video link to the conference call, again for easy access.

Script: A link to the user testing script. The interviewer generally has a printed version of this.

Filling in the above information shouldn’t take too long, and after some practice, you’ll be surprised with how quickly you get prepared for a user testing session.

Once we have all this information prepared, we are ready to run the user testing session. It is worth noting that we also perform a dry run session (or two) before the real sessions. It is always worth it as we also find out that something is not working as expected.

‍

During the test

The team in “control centre” use this doc during the test to fill in the observations. As the user testing session, we are adding anything we observed from a participant and either inputting a new line into the “Observations” table or if we see a repeated observation we put a checkmark beside the participant. Recording observations this way is something that Tomer Sharon recommended in his “Rainbow Spreadsheet”, and we love doing it. Thank you, Tomer!

As a user performs a task, we update the results table by putting either a ✅, ❌ or ?? after the question so we can keep track of what that user did.

What the observations and results will look like.

At the end of each test, we regroup with the interviewer and quickly run through the observations, and results just in case we missed anything.

‍

After the test

Once we’ve finished testing, we regroup as a team in the “control centre” and go through the observations and results. At this point, we put percentages beside each observation and result. We now have a holistic view of how the user testing session went, and we can answer the question, did we achieve our goal?

The last thing we do is to declare our findings from the user testing. For this, the team discusses the results and observations so that we can correctly interpret them, and share our findings with the rest of the company.

What our findings look like at the end of a user testing session. Brevity!

Since we record most of our sessions, we can go back rewatch parts that we were unsure about or share exciting clips to stakeholders. It is important to note that exciting clips can be when your prototype completely missed the mark or something that proves you to be wrong. User testing is about learning, not about showing you were right.

If you’re only doing it to confirm you were right, you’re in the wrong game dude!

‍

Feel free to grab a copy of the template

Please feel free to grab a copy of the template and use it as you will. So feel free to change it and make it your own. The only thing I’d asked for is that you share this article with your friends, family, and colleagues. ✌️

‍

Get the user testing template and script for free on Gumroad

‍