How to Write Tasks for Usability Testing

Usability testing is one of the most rewarding parts of product discovery. It’s an activity that requires a lot of planning and potentially a bunch of overhead, but whilst it might seem like a lot of effort, the risks of not doing any usability testing before building a new feature or product far outweigh any short term pain.

What is a usability test task?

To get the most out of a usability testing session, it’s important to plan what it is that you’d like to test. This often includes figuring out broad hypotheses with a user researcher (if you have one) and the specific tasks that allow you to test those hypotheses with actions.

Here’s a basic example:

Specific tasks might span across multiple hypotheses. The idea is that you make it explicitly clear which tasks are important in proving or disproving a specific hypothesis. You may stop at a specific task and explore the behaviour of the participant in more detail to figure out a finer point or probe a little.

The tasks in a usability test should be realistic activities that the user might perform in real life when they’re using your product. They can be very specific or very open-ended, depending on the research questions and the type of usability testing.

Here’s some guidelines on how to write the most effective tasks to get the most out of your usability testing session.

1. Make sure the task is relevant to your research question.

The task should help you answer your question and test your hypothesis, so it’s a good idea to make it as focused as possible. There are a bunch of potential tasks your users could do, but you’re probably conducting user research and usability testing for a specific purpose, so limiting the tasks and making them hyper relevant is important.

Remember to link back to your research questions at all times before you write your tasks to ensure they are relevant.

2. Keep it simple.

Avoid long or complex instructions – participants will get overwhelmed and lost if the task is too complicated.

Remember that participants might be seeing your product for the first time – or they might be existing users and familiar with your product – but they’re definitely not as familiar as the teams who are working on it every day!

Keep tasks as simple and straightforward as possible so that users understand what they’re meant to do.

3. Be clear about what you want participants to do

A strong user researcher will guide participants in a way that helps them to understand what it is you want them to do but without prompting them so much that you’ve essentially negated the whole point of the usability test.

A good usability test doesn’t mean that users do exactly what you want them to do – but rather, they understand what you’re asking them to do. Whether they then complete the task successfully is a different matter. The important point is that users understand what you’d like them to do.

Task wording is very important in usability testing. Small errors in the phrasing of a task can cause the participant to misunderstand what they’re asked to do or can influence how participants perform the task (thanks to a psychological phenomenon called priming).

Avoiding task management confusion

Task instructions can be delivered verbally or in writing. One of the best ways to avoid any confusion is to ask your participants to read the task instructions out loud.

This helps to ensure that the participant understands the instructions completely, and helps the researchers or observers with their note taking, because they always know which task the user is performing.

Linking tasks to note taking

One of the most effective ways to note take was taught to me by a former colleague and now lead researcher at Instagram, Kostas Kononovas. He explained that the easiest way to link tasks to note taking is to create a vertical strip of post-its linked to one another where the first post-t is the task.

As participants proceed through each usability test task, a new post it is attached to the bottom, with a separate thread of post its for each task.

Chaining post-it notes together in this way means that observers notes are always linked back to the task and helps keep things well organised.

(As a side note: for other ways to use post it notes in product teams, check out our guide here).

4. Try to avoid leading questions that give away how users are “supposed” to complete the task

There are few things in life so unbearable as watching a user get completely lost when attempting to use a feature that you and your design team have spent weeks laboring over.

Some people find it virtually impossible to not say something, or get involved in some way.

You’ve probably experienced it yourself: you’ve asked a user to perform what you think is a simple task but they’re really struggling to find out where or how to do the task.

This is the beauty of usability testing; you have to be able to endure watching users in the real world interact with your product – even when users struggle with your UX.

Tasks play an important part in eliminating bias here. Leading questions can unknowingly give away how users are supposed to complete a task and so tasks should be carefully crafted to avoid this.

For example, if a task says ‘Visit the account management page and delete your account’, this is already telling users where they can delete their account (on the account management page).

Instead, a better task might read ‘You decide you no longer want this service. Close your account and explain how you might ensure this is done.’

5. Test your tasks before giving them to actual participants by performing a think aloud with a colleague

Before you give your tasks to your participants, it’s always a good idea to run through them with a colleague beforehand.

This helps you to figure out whether what you’ve written is understandable to someone who is not closely involved in the research.

A colleague should ideally be someone who doesn’t work in the product team or someone who isn’t too close to the product you’re building so that they are primed or influenced in any way.

You’ll often be surprised by how many assumptions we make – even for something as simple as writing tasks for usability testing.

Likewise, it’s also a good idea to run through the tasks once they’re written with your colleagues who will be observing the session. They will need to know what the tasks are beforehand so it’s important to ask observers to confirm they understand what the core objectives of the research session are beforehand.