Scenario Tasks

Scenario tasks were touched on briefly in my last post on scenarios, but here we get a chance to explore this aspect of usability testing in more detail. Scenario tasks are the thoughtfully crafted goal exercises that the user will be asked to perform during a usability test. The ideal task will be meaningful, in that it will involve parts or utilities of the software that are more in need of user input. Good tasks will also encourage the user to navigate and interact with the program in ways natural to them and demonstrative of their user behavior.

One practice for getting testers to engage genuinely with the program is to give them concise and realistic scenarios that include the task they are being asked to perform. There is a lot of playing around and research that goes into choosing reasonable scenarios and tasks.

“Ensure an appropriate level of details. [The task] should contain just enough information so that participants understand what they are supposed to do, but not too much that they are restricted from exploring naturally in their own way.” (1)

“Poorly written task often focus too much on forcing users to interact with a specific feature, rather than seeing if and how the user chooses to use the interface. A scenario puts the task into context, and, thus, hopefully motivates the participant.” (2)

Here are few other tips for choosing the right scenario tasks.

(1) Language that doesn’t just mimic that which is used in the program will help avoid leading the user in performing the tasks. Testing whether the user can achieve the goal without direct word association can make a usability test more fruitful. For example, instead of saying “Subscribe to the mailing list” a good task might read, “find a way to keep up to date with X product or company.”

(2) Make sure that the tasks are realistic for the people you are testing. It doesn’t make much sense to observe how a person edits and saves a text file if they only write documents by hand.

(3) Don’t use technical jargon or company lingo in the scenarios and tasks. You want the test to be accessible and relatable to a variety of users.

(4) Don’t be more specific than necessary. The user may lose focus or get confused with extra details.

(5) In general avoid using tasks that build on one another. The tester should be able to skip around the various tasks.

“In general, the tasks are designed to be independent from each other for two reasons: to grant flexibility in terms of changing the orders of the tasks for different participants; and to allow participants to continue to the next task, even if they failed the previous one.” (1)

As should be clear by now, making scenario tasks isn’t as simple as it may sound. Knowing the goals of the usability test and keeping them in mind is paramount. Then it’s all about finding the activities that best represent those goals, and translating them into tasks that seem accessible to the body of tester who will be working on them. This will involve a number of iterations and attempts at using the software while thinking about the experience of other users. Keep in mind the checklist of what to include/avoid in tasks, and you have all of the pieces for a good set of scenario tasks.

Resources:

(1) design.canonical.com

(2) www.nngroup.com

(3) blog.usabilitytools.com

(4) userbrain.net

usability-hate

2 thoughts on “Scenario Tasks

  1. This is a great summary of scenario tasks. There is certainly an art to writing a good scenario task. You identified a good point with this:

    >>>
    (1) Language that doesn’t just mimic that which is used in the program will help avoid leading the user in performing the tasks. Testing whether the user can achieve the goal without direct word association can make a usability test more fruitful. For example, instead of saying “Subscribe to the mailing list” a good task might read, “find a way to keep up to date with X product or company.”
    <<<

    You want to avoid using the same terminology as you might find in a menu, for example. That would give the tester an unintended hint for how to complete the task.

    Here's an example: When testing the gedit editor in GNOME, I used this scenario task:

    "3. Some of the names are incorrect in the file. Please change every occurrence of Applejack with Fluttershy, and all instances of Rainbow Dash with Twilight Sparkle."

    That scenario task challenges the tester to find the "Find and Replace" function, but doesn't use either any terms of "Find" or "Search" or "Replace." The tester has to figure out WHAT to do, then has to figure out HOW to do it. But I think that example is well worded to set a brief example (additional context was set in tasks 1 and 2) then ask the tester to do something specific. And the goal is clear enough that the tester will be able to say when they have completed the task.

  2. I’m also curious: what did you learn from the scenario tasks you used in your first contribution? It’s good to learn from that exercise.

    In your first contribution, you used ten scenario tasks from another usability test. Which of these seemed to work well for you? Which would you re-write, now that you know more about scenario tasks?

Leave a Reply

Your email address will not be published. Required fields are marked *