There are two key needs when it comes to testing the usability of a product or application:
Getting results which are accurate and trustworthy, and,
Getting useful insights, even from small sample sizes.
Accuracy and trust in results are key for any usability professional. We have to be sure the recommendations we make are solving the problems and meeting the needs of the end-user.
The way we’d typically gain confidence in our findings would be to increase the sample size - that is, the number of people who take part in the research. However, for teams that are on a small budget or are under pressure to deliver results fast, scaling the testing to lots of people sometimes isn’t possible.
In search of a usability technique which would cover both these needs, I came across System Usability Scale (SUS). Created by John Brooke in 1986 as a “quick and dirty” way to administer usability tests on systems, it is essentially a ten-question survey with five possible answers for each question, ranging from ‘strongly agree’ to ‘strongly disagree’.
This method can be a very beneficial part of the usability process, here’s why it works well and how you can use it too:
The System Usability Scale test
The SUS is composed of ten questions:
I think that I would like to use this system frequently.
I found the system unnecessarily complex.
I thought the system was easy to use.
I think that I would need the support of a technical person to be able to use this system.
I found the various functions in this system were well integrated.
I thought there was too much inconsistency in this system.
I would imagine that most people would learn to use this system very quickly.
I found the system very cumbersome to use.
I felt very confident using the system.
I needed to learn a lot of things before I could get going with this system.
While these questions do not change, the usability specialist would choose the task they refer to. For example, we may want to check how easy it is for a person to find a book by a specific author, or how simple it is for a person to open a new savings account.
SUS aims to assess three core pillars of usability:
Effectiveness: Can users achieve their goal?
Efficiency: How much effort is exerted to meet the goal?
Satisfaction: Was the system pleasurable to use while attempting to meet the goal?
While there’s a range of other techniques for deciphering this - from heuristic evaluations, to think-aloud sessions, to in-situ observation - SUS provides a lot of the benefits of those in a neat package and ascertains reliable results.
A person’s preference is closely represented by their performance during SUS testing - something which is not common in other forms of usability enquiry, which means you can trust the resulting trends in the data to highlight good and bad areas of your product.
It’s all too common that someone would play around with a static prototype which gives little indication of whether their performance would match their actions in the real world. However, SUS outcomes tend to match the expectations when watching a person use an application, as I’ve witnessed myself in my own usability research.
Running an example test
Let’s say we are designing a car dealership website.
There are a few features represented in our designs that we need to test by looking at different tasks:
Allowing people to filter the cars by make (e.g. Nissan, Toyota etc.).
Sorting cars by price (low-to-high).
Contacting the dealership to request a test-drive.
Next, we’ll need to get our users to fill in a SUS sheet and calculate their scores. So let’s break this down:
For each task, ask your test subject the ten questions mentioned above.
Get them to fill in their answers. You can supercharge your workflow with this Google Form which already has all the questions available (clicking this will create a copy of the Form for you to use).