Guided: Usability Testing

In this lab, you will imagine that you are testing the usability of PluralSearch, a mockup of a Google-like search engine. You will write usability tests designed to be used by a usability test facilitator.

You won't be coding in this lab, but instead you will be practicing to write instructions that accomplish the following goals:

1. Provide the usability test facilitator with a clear and accurate test.
2. Maximize the chances of getting detailed, actionable results by putting the usability test participant at ease.
3. Ensure you get reliable, accurate test results by avoiding biasing the user.

Whether you are running the usability test as the facilitator, or passing that responsibility to someone else, the above goals are vital to a successful run of tests.

info> Note: The term "participant" describes the user that you are observing to use the site or software.

You will write a script to be read, word-for-word, at the beginning of every test. You will then write two tests, as well as the correct sequence of actions to accomplish both test tasks, using the provided text files:

1. 1_Script.txt
2. 2_SearchTask.txt
3. 3_SearchCorrectSequence.txt
4. 4_VideosTask.txt
5. 5_VideosCorrectSequence.txt

info> If at any point you feel stuck, please consult the solution directory in the Filetree.

Click the arrow icon to move on to the next step!

First, you will need to write a portion of the usability testing script. This script is read word-for-word at the beginning of every usability test. In this way, a variable is removed from testing, helping test result reliability.

The 1_Script.txt file has been prepared for you. It already contains part of a script, with some placeholders for areas you will be asked to write yourself.

One thing you should consider when preparing for usability testing is that people may become stressed at the idea of taking a test. A stressed participant may not give realistic results.

You should often use somewhat informal wording, instead of a more formal grammar, to help reduce participant stress. A slightly informal, but not disrespectful, word choice can put a participant at ease. Another thing to consider is that the participants may become focused on the task and forget to speak. The more details the participant gives, the more information you will have to act upon. Giving feedback to someone that is close to the site or software may be hard. Some participants may refrain from giving frank feedback out of such concern. After completing the above three tasks, you now have a usability script that you or a facilitator can use at the start of each test! Reading this script to the participant will ensure every participant gets the exact same instructions and reminders, removing possible variables from each test, and therefore improving the reliability and accuracy of the results! Great job!

In this step, you will write your first usability test task. You will use PluralSearch in the Web Browser tab of this environment.

A task is something you are asking the participant to accomplish in the site or software.

There are two key aspects of writing a good task that you will practice:

1. Be polite by saying 'please'. You aren't commanding the participant, but instead you are asking for their help. Treating them in this way can help put them at ease, rather than feel under pressure or as if they are being tested.

   
   

2. Avoid biasing the user. When you describe the task, you don't want to accidentally give them hints about how to accomplish it. One way is to avoid using too many words that match the things they will click on, but instead use synonyms.

   
   

   For example, if a primary button on a job creation screen says 'Start', you wouldn't want to say 'How would you start this job?'. Instead you should ask 'How would you run this job?'.

In this step, you will write the exact correct sequence of actions needed to perform the task you described earlier, which is to search for information on zebras.

Documenting the correct sequence helps the facilitator give their insights after a test and provides points of comparison to assess what the participant does versus what they should have done. It also helps you to think in terms of the user flow, information architecture, and usability. When documenting, you should write steps that are reasonably minimal. For example, if a correct sequence was to type a value then hit a button, both typing and hitting the button should be separate steps.

You also want each step to be precise and specific. For example, if the text of a button is Run Job you would want to say "Click the Run Job button", and not "Click Run" or "Click the Job button".

Now you will write another task similar to the previous one. This task will be to find zebra videos. In some cases, you cannot avoid using words that appear on the screen, like "videos", which appears as a tab after searching. In this case, it is okay and necessary to use the word "videos" in writing the task.

You will again start the participant from the PluralSearch homepage.

In this last step, you will write the exact correct sequence of actions to perform the task you described earlier, which was to find zebra videos.

This task is more complex, as there are multiple correct paths. Once you complete the above task, you are ready to hand your script, tasks, and correct sequences to a facilitator. By prepping the facilitator well and not biasing the user, you should have a great usability test results.

Congratulations!