Seven Tips For Writing Usability Test Scenarios
The primary goal of usability testing is to have real people complete real-world tasks on websites, cell phones, hardware, and software, among other things.
Of course, the first and most important step is to determine what the users are attempting to accomplish. Following that, you can choose the tasks that you want to put to the test. Users must be able to test or attempt a genuine test scenario, which you must create in order to accomplish this goal.
A task is made up of a series of steps that a user must complete in order to achieve a specific result. When a test scenario is created, it depicts the activities that the test user is attempting to complete by providing the necessary details and context in order to achieve the goal.
It is necessary to strike a balance between providing the user with enough information so that they are not left guessing about what they are supposed to do and not providing enough information so that the user has nothing to simulate when creating an ideal test scenario. Keep in mind that the user must simulate the nonlinearity and discovery that occurs during real-time application usage.
So, how do you make sure that your test scenario is well-balanced in terms of complexity? Here are seven pointers to help you along the way:
1) Be specific in your description.
Keep your tasks from becoming too generalised. Take, for example, instead of telling your users to look for house appliances, be more specific and tell them to look for a dishwasher under $800 that has received positive customer feedback. In a nutshell, provide your participants with a clear reason or purpose for performing the task you have assigned them.
Users will quickly narrow their search based on product attributes, recommendations, and indicators of quality if they have a clear purpose in mind when conducting their search. Giving them broad ideas about what they are expected to do will only broaden their scope and increase the likelihood that they will make educated guesses, which will not produce the desired results.
In the imaginative world of usability testing, giving users a vague purpose will cause them to encounter problems, and they will begin looking for a moderator who can direct them to the information you want them to discover. Avoid being overly vague because this will lead to users making educated guesses about what they are supposed to do as a result of your instructions. For example, “you require that they come to the finance department on August 10 between the hours of 10 a.m. and 1 p.m.”
2) Don’t tell the user what to do; instead, let them figure it out for themselves.
While it is important to provide users with specific instructions and a clear understanding of the purpose, providing detailed instructions on how to complete the task will have a negative impact on the results. If you lead the users too much, they will be less helpful, and the results may be skewed as a result. For example, instead of telling them to “click on the drop-down menu at the top right corner of the site to submit your report,” simply tell them to “Submit your report through the site.”
3) Communicate in a language that users can understand.
When explaining to users what they are expected to do, it is possible that they will become confused if company jargon or terms are used. If the users are not familiar with the terms used in the test scenario, this can result in outright confusion or false test results because they will be working with their imaginations and guesswork, which can lead to outright confusion or false test results.
It will only cause confusion when they use terms such as “liability” when referring to their loans and “assets” when referring to their children’s college funds because the average user is not familiar with such terminology. How well does the user in your test scenario understand the terms “mega menu” and “item page,” let alone “configurator” and “configurator”?
As a result, you must be aware of the implications of such terms.
4) Make sure you have the correct instructions.
If the users are required to visit the finance department of a specific organisation, they must be provided with the correct office number in order to do so. This makes the test more straightforward for the user and allows you to determine whether or not the task was completed successfully or unsuccessfully in the first place.
The problem with the task “visit a finance office of the nearest organisation” is that the users will be in the mindset of looking for information to solve the problem when they perform the action. It’s possible that the nearest organisation is closed at the time, and they’ll be more concerned with getting the test completed and collecting their dues than with anything else. This could lead to incorrect conclusions, and you could end up inflating fundamental metrics such as task completion rates as a result of this.
To avoid this, do not make the tasks dependent on one another.
Separate tasks that are not dependent on one another are essential for effective teamwork. For example, instructing the user to create a document in one task and then delete the same document in another task may result in the user becoming entangled in a tangle if they fail to remember to complete this step. As a result, it is critical to have tasks that alternate in order to reduce the occurrence of such incidents. Make every effort to avoid tasks that are dependent on you.
Although this may not be possible if you are testing the installation process, it is possible that it will not be. You must be aware of the biases and complications that may arise as a result of these dependencies when performing the test in that scenario.
6) Provide Context While Keeping Your Test Scenario Short
The goal of a test scenario is to provide enough context for the user to feel as if they were actually responsible for carrying out the task at hand. You should avoid going overboard with your explanations, however. Example: “You will be visiting the finance office of the ABC Company in August, during which you will be required to write a report on the financial activities of the company.”
When it comes to moderated and immoderate testing, the test scenarios are different.
The concept of test-scenario writing has evolved over time as a result of the moderated lab-based testing that has occurred. However, if you are conducting an excessive usability test, you will need to refine your approach. One cannot rely on the moderator to guide users through a test and inquire as to what they would expect from the test results.
You need to be more explicit without being overly explanatory in your writing. You’ll need to provide the names, price ranges, and brands of the items that will be tested, as well as the quantities of each. However, while many people believe that this provides users with specific direction, there have only been a few instances of task completion rates greater than 90 percent in immoderate benchmark studies.
The checkout procedures, navigation, and even simple things such as organisation terms on complex organisation websites can cause users to become perplexed, despite the fact that the specific details have been explicitly explained.
THE VERDICT IN THE END
Getting the right balance between not leading users astray and making their tasks too difficult takes a significant amount of time to master. You shouldn’t be afraid to change details to suit the different tests (moderated versus unmoderated) or goals (findability versus checkout) that you may be running. There are no “ideal” or “perfect” tests, so don’t be afraid to experiment with different approaches. You can even read the test scenarios aloud instead of having them displayed on a screen or printed out for your convenience.
