Welcome to second part of our Usability series of articles. In the first part we talked about getting started and gave you an overview.
Starting with user goals
Think about the activities users carry out on your website that you would like to test. Put each one in words, in a way that is specific and measurable. Describe the entire activity, telling users what you want done but not how to do it.
Remember, throughout the rest of this series of articles, we will be talking about testing websites, as an example of user tests. Nevertheless, all principles described here can be equally applied to web and mobile apps – or any product for that matter.
Let’s begin. The first step is to figure out which scenarios on the website do we want to test. A scenario should be defined as:
- something that describes a complete activity;
- something specific and measurable; and
- something that describes what users want to do, not how they should do that.
A ‘complete activity’
An activity is complete if the user has fully attained their set goals. For example, a well-described scenario is: “Find a direct flight from London to New York next Wednesday and buy yourself a ticket.” This is a complete activity because most users will feel they have achieved their goal if they complete this task.
An incomplete activity would be: “Find a direct flight from London to New York.” Although this task will cause certain usability issues to surface, its value to our overall knowledge of a website’s usability is reduced because we didn’t learn as much as we could have.
‘Specific’ and ‘measurable’
Simply put, a scenario should be created in such a way that it’s easily understood and we can tell when it’s completed. The goal should be clear and specific (like “Find a direct flight from …”), not ambiguous and general (like “Find some flights”).
Specificity is closely related to being able to measure. If you can’t tell if a task is done or not, it’s hard to tell if it was even correct and if its goal was achieved.
What users do
When the test session begins, the interviewer reads the scenario to the user. It should describe the end goal, but not give instructions on how to get there. It would be wrong to say “Find a direct flight from London … by clicking this link and selecting an option to …”
The feedback from the latter kind of test would be far less valuable because we wouldn’t be able to see if the user could figure this out on their own. Of course, you can say “On the Lufthansa website, find a direct flight …” if we’re only concerned with the Lufthansa website. That doesn’t mean we’re telling the user how to complete the task.
It’s important to know which scenarios you’re testing so that you can know who your intended users are.
Missed the previous part?
No worries, you can catch-up and see our previous article in the series: “Usability: Getting started and overview“.