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.