A usability test is something you do at the later stages of a product development cycle. After we learned about the target users’ needs, designed and developed a concept, we now need to make sure the product is bug-free and easy to use.
A usability test measures how easy and efficient a product is for a user by asking them to complete specific tasks. Something that delivers a realistic interaction experience, such as a high-fidelity prototype, or a (near-complete) product is required for usability testing. If there are many areas you’d like to test, it is better to break it down into a series of tests, so the engineer team can fix the usability issues in waves.
3 Main Elements of a Usability Test
A moderator facilitates the usability sessions by presenting tasks to the participant, observing, recording everything the participants do and say, and asking probing questions. Traditionally, a moderator needs to be present during each test, which is called moderated usability tests. Conversely, there are many remote user testing tools that automates the process, so a moderator is not needed to be present during the testing sessions, which is called unmoderated usability tests.
For a moderated usability test, there are several things for the moderators to keep in mind during a test session:
The goal of these principles is to minimize the experimenter effect, which is the error and bias that the moderator/experimenter/observer introduce into the data. For example, an experimenter may unknowingly provide verbal and physical cues to the participants so that they can complete the task successfully, while they would not be able to complete the task in real life, and the usability issues will go undetected.
For unmoderated usability tests, the experimenter effect is greatly reduced, which is why I would recommend using unmoderated tests over moderated. Note, in order to make sure the test is designed well for an unmoderated test, conducting pilot tests is essential.
At this stage of product development, the goals and needs of the target users should have been defined, and tasks should be designed accordingly.
There are two types of tasks: open-ended tasks and specific tasks. An open-ended task lets the participants roam free in a more explorative way. For example: Explore the app as you normally would and tell us about your first impressions. Don’t spend more than 3 minutes. However, the open-ended tasks usually means more analysis time and fewer insights. I would only recommend open-ended tasks to projects of no or very few previous research. Specific tasks are what I would recommend in most situations.
Tasks represent steps that users would take to reach their goals. It is not necessary to include every task a user would take; instead, focus on the tasks you are most uncertain about and consider your project team's capacity.
Before jumping into the tasks, a scenario should be provided to orient the participant, followed by one task at a time, and concluding with a final survey. The structure is as follows:
A good scenario lets the participants know what is expected of them. It conveys the who, what, and where of the goal. For example: