How to Write Effective Usability Tasks (5 Key Strategies)
Great tasks are the crux of any usability test – if you don’t have those right, no sample size or amount of analysis will save your study. Poor usability tasks make it extremely difficult to trust the data you collect, because you will be constantly wondering if feedback was related to the product or the instructions. (Or worse – your team will be wondering this!)
Yet writing effective usability tasks is deceptively tricky. While they seem obvious and simple, they must be crafted very carefully and intentionally to test the interface without giving away too much information or being confusing. The tips below describe specific strategies to master the art and science of writing usability task instructions you can trust.
As with any research project, make sure you understand your study goals before drafting up the specific scripts and guides for your sessions. There is no point in perfecting the wording of a task that you will ultimately scrap!
After you have your goals in line and have followed the techniques below to craft your task instructions, make sure to test them out on a few folks before you go live with real participants. Pilot runs will be extremely helpful in ensuring you get the best quality data possible once you start your study proper!
Want a free usability test plan template to help you define your study goals and organize all your tasks and questions? Enter your info below to have it sent to your inbox!
Summary:
Give the user a real and meaningful goal.
Write in user-centered language, not engineering or design-centered language.
Ask the user to do something, not tell you something.
Tell your users what their goal is, not the steps to complete it.
Don’t make tasks dependent on other tasks.
1. Give the user a real and meaningful goal.
Your tasks should be things that users would realistically and naturally do on your site or with your product. While you may have a simple warm-up task that is only one step, most tasks should be a few steps that guide the user to complete an activity that your real users actually care about. Ideal usability tasks are connected to specific user needs of your product – the core activities that drive users to your product because they provide value to them. Examples are things like, “Turn on email reminders for new properties in a specific neighborhood,” or, “Find out how much money you made last month.”
A task that is not real or meaningful would be, “Open your account settings,” or “View your budget dashboard.” It is possible that a user might want to just view a dashboard or (less likely) view their settings, but it is not very meaningful. Great usability tasks are both important and realistic.
A good way to test this is to imagine a user telling you, “I’m using your product today to (fll in your task here).” It wouldn’t sound natural to say, “I’m using your product today to view my settings,” but a user might say, “I’m using your product today so I update my settings to get an email and text when someone buys something from my store.” Unrealistic or arbitrary tasks can be rehabbed by connecting them back to user needs. If you need to rewrite as task like, “Open the refrigerator,” ask yourself why a user might be opening the fridge – what need is this filling for them? By connecting this back to a user need, you may update this task to be, “Take a look at what is in your refrigerator to decide what you want to eat for dinner.”
If you need help figuring out what users really do on your site, you can look through usage data, conduct user research interviews, or observe users through contextual inquiry. Alternatively, you could talk to the people on your team who interface with customers often, like tech support or sales agents. If nothing else, try searching through forums, FAQs, testing the site out yourself, or learning about similar/competitor products.
A note about task scenarios – many researchers include some scenario information for each task. This can be helpful if you need to get users into the mindset of why they would want to complete these specific activities. This could be something like, “You have friends visiting and decided to order a few pizzas... (this would continue to reveal the task instructions).” If you select your participants appropriately, you shouldn’t need much context to help them get into the right mindset. I generally prefer a sentence or two at the start of the test rather than at the start of each task, so users are not bouncing around through different personas. Just make sure you only include only the critical information in the scenario and not extra info just for the sake of storytelling!
2. Write in user-centered language, not engineering or design-centered language.
Great usability tasks sound like things that a real user would say. They also avoid unnecessarily using language that refers specifically to elements in the interface, like buttons or headers. If your task involves clicking a button that says, “View History,” you would not want to tell users to: “Click to view history and find all transactions in the last 6 months,” because you would not be able to determine if that button was intuitive and discoverable – you would only be testing the participant’s ability to scan the page for the keywords you’ve given them. Instead, you could just say, “Now you want to see all the transactions that have taken place over the past 6 months.” In this case, if users easily find the “View History” button, you can be more confident that it makes sense to them.
Writing in user-centered language will also help participants connect more with the task, as it will be something they can imagine themselves wanting to do. No one goes to a website thinking, I need to click the sign up button, but they might think, I want to receive their weekly newsletter.
There are two things you can do to make sure you are writing usability tasks in user-centered language. One is to scan your tasks for any wording that mirrors the specific language used in the interface – things like button labels, form labels, section headers, or even the actions users might take like clicking, tapping, searching, etc. If you find any, try to come up with ways to avoid using those words while still sounding natural.
Just note that sometimes users’ language overlaps so much with the language used in the interface that it can be too awkward to avoid certain words. This can be because your design is really intuitive (great job!) or because certain technical words have become ubiquitous – such as “log in” or “edit.” In cases like this, it wouldn’t make sense to try to avoid those keywords, because it would sound too awkward.
The second thing you can do to check your tasks for user-centered language is to imagine a user telling their friend about what they are doing. Users say things like, “I want to find a laptop bag that fits my 16-inch graphics tablet in it,” not “I want to search for a 16-inch-long laptop bag.”
3. Ask the user to do something, not tell you something.
Use action verbs in the instructions – don’t ask a question, instead give a prompt. The point of a usability test is to watch users attempt certain tasks so you can see if your design is easy to use or not. If you ask users questions, they will respond by speaking and explaining, and you will miss out on that sweet, sweet behavioral data!
This can often arise from researchers wanting to sound polite and not like they are bossing users around, but in reality, asking a question will probably do more harm than good. That’s because the human brain processes the task and your product differently when you ask users to perform a language task (i.e. speaking) vs a doing task. It takes a different kind of cognitive effort to convert thoughts and impulses into language on the front end. (Ever fumbled over your words trying to describe something that is easy for you to just do?) Asking users to speak and describe something (before they actually do it) could cause them to analyze an interface much more deeply than they might have otherwise, meaning they could pick out fields and functions that a user sitting at home alone wouldn’t.
This is not the same thing as “thinking out loud,” which you should still have users do in most cases. This just means you should avoid wording your tasks as questions – and instead use actionable prompts. A common example of a speaking task is when facilitators say, “How would you …?” This asks the user to explain and describe. An easy way to improve this task would be, “Show me how would…” This will prompt the user to act first, and describe second. As researchers, we gather both behavioral and attitudinal data for a reason – make sure you aren’t skimping out on the behavioral side!
4. Tell your users what their goal is, not the steps to complete it.
It sounds obvious to say that you shouldn’t tell users how to complete a task, but in practice, it can creep in subtly. Even something simple, like, “Find your most recently edited document and update the header,” technically gives away the step of finding before updating. You could say instead, “Update the header of your most recently edited document,” but admittedly, this is probably a low-risk issue to start with.
But what about a task like, “Go to the History tab and export all the transactions”? This is a much higher risk mistake because you are giving users a very specific clue to look in the History tab. When you read this task out loud, it does sound natural, but it can still be improved! In this case, you could instead say, “Export a file that shows you all your past transactions,” which still sounds natural but avoids telling them the steps to take.
The key here is to give users an end goal to achieve, and don’t describe the steps they need to take to achieve it. Think about the outcome or end-state and describe that in your instructions. Some tasks may be more complicated than others, but there will always be critical information that users need to know to complete the task properly, as well as superfluous information that isn’t helpful and only either confuses them or clues them into the answer prematurely.
5. Don’t make tasks dependent on other tasks.
Imagine facilitating a usability test in which your second task can only be completed if users also completed the first task successfully. But your user doesn’t complete the first task all the way and only thinks that they did. Do you explain they didn’t do it properly and have them fix it before moving on? (That might be biasing them for later tasks.) Do you skip the second task entirely and miss out on that precious data? (After spending all the time preparing and recruiting for this user test??) Do you panic because you assumed everyone would complete this easy task without issues? This is the conundrum you enter when you make your tasks dependent on each other.
Some examples of related tasks could be, 1) Open a new account, and 2) Change the name of your new account. Or, 1) Save a list of all the current homeowners in your database, and 2) Send an email to your entire current homeowners list.
Making your tasks related to each other and having them occur in a logical order can help make the test feel more natural to users, as it would mirror the real experience of using the product. But in most cases, you don’t need to make your tasks dependent on each other to make this work – you can imitate a dependency.
Instead of making tasks dependent, you can have users complete the next logical step (the second task), but on a different object or in a different space in case they weren’t able to create the first object successfully in the previous task. For the example above, if the first task was to, “Open a new account,” the next task could be, “Change the name of one of your accounts.” As long as they have at least one account, they should be able to complete either task independently.
You can also use this strategy as a backup, meaning users would complete their tasks dependently unless the first task was a failure, in which case you have them complete that task on another object. So for the example of creating a new account, the second task could default to, “Change the name of your new account,” unless they didn’t create the new one, in which case you could ask them to, “Change the name of one of your accounts.” This flexibility allows you to create a series of tasks that flow together well, while preparing for the inevitability of a failed task breaking the chain.
After you follow these strategies to write your usability task instructions, the next step is to test them out! Find a friend or colleague to run through your tasks with you to make sure they are clear and will produce valid and reliable data. Once you are live with your real participants, you will feel confident from the practice as well as knowing you are using a high-quality research script.
Happy testing!
