Heart shape

At the heart of a good usability test sits the task scenarios. I’ve written about the different kinds of task scenario in the past. But how do you come up with task scenarios in the first place?

This article describes the approach I use. First, I’ll identify short, one sentence, test tasks. Second, I’ll expand these into task scenarios. Third, I'll assess each scenario using a checklist. Finally, I’ll pilot test the scenarios with users.

Test tasks

Test tasks are where we start. These are short, one-sentence descriptions of an activity that real users will want to carry out with the system. You can think of these as red routes. Here are some examples for various services:

  • See if I’m eligible for a student bursary.
  • Find a holiday apartment in Rome.
  • Apply for a provisional driving license.
  • Book a train ticket.
  • Rent a car for the week-end.
  • Tell my insurance company that I’ve moved house.

Note how these short descriptions are phrased as if a real user is saying them. In contrast, these are not test tasks because they are not activities that people usually carry out:

  • Look at the home page and see if you like the design.
  • Compare the product with [some alternative] and decide if it’s easier to use.
  • Browse the web site to see if there’s anything interesting.
  • Decide if this app belongs to a brand you want to be associated with.

When writing your test tasks, think of it in terms of outcomes. What are people trying to achieve with the product?

Imagine your product was live and you could interrupt someone who was using it and ask, “Why are you using this product?” Your test task should provide a valid answer.

For example, a user might say: “I’m using this product… because I want to see if I’m eligible for a student bursary” or “I’m using this product… because I want to find a holiday apartment in Rome.”

In contrast, a user would never say “I’m using this product… because I want to decide if this app belongs to a brand I want to be associated with”.

Task scenarios

Test tasks are where we start, but we can’t give them to a participant as written. That’s because they don’t include the additional contextual information that motivates the test participant to complete the task. This is where task scenarios come in.

A task scenario is a longer, narrative, description of the test task that motivates the participant to complete it. One way of thinking of a task scenario is as a problem that the participant needs to complete with our product or service. Here is an example:

Test task: Buy a digital camera

Task scenario: You’re going scuba diving in Australia. You want to buy a camera that you can use to take pictures of fish around the coral reef. Your budget is £150 (maximum). You’re open minded about the brand but you’ve heard megapixels are important for image quality so you want as many of those as you can get. Use the Argos web site (www.argos.co.uk) to find a suitable camera.

Note that the test task is insufficient here. If this is all we give to participants, they could easily “game” the usability test by looking for a digital camera on the home page, adding it to their basket and then heading to checkout. That’s not the way people usually go about this kind of purchase. In contrast, the task scenario makes the user behave more authentically: for example, by needing to look for a particular feature (in this case, a waterproof camera) and needing to compare different cameras to choose one that’s best.

Here’s a second example:

Test task: Book an AirBnB for a week-end away

Task scenario: You’re planning a long week-end away in the Lake District with some friends. You plan to arrive on a Friday night and leave on the following Monday. There will be 5 of you plus a small dog. Your friends have asked you to identify three suitable places that they can choose from, preferably close to Ambleside or Windermere. The main constraints are that it must be a week-end in September and it shouldn’t cost more than £200 per person (i.e. £1000 in total). Identify three suitable places you can share with your friends.

Again, the test task lacks detail that will motivate the participant to complete the task authentically. The task scenario includes that detail in a way that’s realistic for participants.

A task scenario checklist

Writing a good usability task scenario isn’t easy. A poorly worded scenario leads the participant to the correct answer. If the scenario is too complex, participants may feel they are in a school examination.

Here’s a checklist that will help. These are the questions I use to check my usability task scenarios are fit for purpose.

Is it really a key task?

You almost always should be testing the critical tasks, the ones that underlie the key user need. This avoids vanity tasks such as, “Download a photograph of the chief executive.”

Does it include enough information to complete the task, yet avoid hidden clues?

A good usability task scenario will contain context and details. This motivates the participant to really carry the task. Consider the earlier example: “Buy a digital camera”. This isn’t specific enough. To really motivate the participant we need to include details such as the budget and whether it is for travel or for professional studio work.

Does it describe what the user wants to do (not how the user should do it)?

A usability test is not a user acceptance test. With a user acceptance test, researchers tell people where to click and what step to do next because they are checking that the functions in the system work. But a usability test isn’t functional testing. Instead, you’re discovering if the process for completing the task is intuitive. Providing test participants with a play-by-play will make the task easy and artificially boost success rates.

Is it expressed in the user’s language?

Just because your product or service contains jargon, it doesn’t mean that the same jargon should find its way into the task scenario. Your task scenario should contain only the words and phrases that participants use. For example, on your intranet, when people want to reserve a room for a meeting, do they think of themselves as using a “resource scheduler” or as booking a room? Make sure your own task scenarios use the words that your users use.

Is there a correct solution?

Participants should be able to complete the task successfully: that is, the system should allow people to complete the task so long as the participant follows all the correct steps. There’s rarely a situation where you will ask the participant to complete a task that the system doesn’t support. By having a correct solution, you can then say if the participant has completed the task successfully and gain a measure of success rate. Although this sounds obvious, you should always pilot test your scenarios (you can use yourself or a colleague for this) to check that the task scenarios can be completed as written.

Is the task scenario clear and unambiguous?

Use short sentences, bulleted lists and write in the active voice. Avoid words like “please” (for example, “Please use the product to…”). Follow best practice in writing content.

Pilot test your scenarios

Once the scenarios pass this checklist, pilot test them with 2–3 people to check that the task requirements are clear.

For most systems, the simplest way to do this is to involve colleagues who aren’t involved in the design of the product. Ask them to read over the task scenarios and explain in their own words what the scenario is asking. If the task scenario includes technical words, ask them to explain their understanding: for example, “What does ‘megapixel’ mean to you?”

This approach works when you’re testing a mass market product but if your system is aimed at a specialised audience, especially one that has a fair degree of domain knowledge, you may need to pilot test with real users.

Usability testing seems easy but there are several gotchas to look out for. Writing effective task scenarios is the critical first step to ending up with unbiassed data that will allow the product team to move forward with the design.

-oOo-

About the author

David Travis

Dr. David Travis (@userfocus) has been carrying out ethnographic field research and running product usability tests since 1989. He has published three books on user experience including Think Like a UX Researcher. If you like his articles, you might enjoy his free online user experience course.



Foundation Certificate in UX

Gain hands-on practice in all the key areas of UX while you prepare for the BCS Foundation Certificate in User Experience. More details

Download the best of Userfocus. For free.

100s of pages of practical advice on user experience, in handy portable form. 'Bright Ideas' eBooks.

UX newsletter

Every month, we share an in-depth article on user experience with over 10,000 newsletter readers. Want in? Sign up now and get free, exclusive access to our reports and eBooks.

Related articles & resources

This article is tagged task scenarios, usability testing.


Our services

Let us help you create great customer experiences.

Get free email updates

Join our community of UX professionals who get their monthly fix of user experience insights from Userfocus and get free, exclusive access to our reports and eBooks.

David Travis Dr. David Travis (@userfocus) has been carrying out ethnographic field research and running product usability tests since 1989. He has published three books on user experience including Think Like a UX Researcher.

Get help with…

If you liked this, try…

Get our newsletter (And a free guide to usability test moderation)
No thanks