Profile picture of Michael J. Fordham

5 min read

System Usability Scale: The most underrated usability technique?

While the System Usability Scale test is an effective and proven usability technique, it’s yet to be embraced in design circles.

A mobile app with different scores given to each of its features, and the total score of 9.1

Illustrations by {name}

Stay informed on all things design.

Thanks for submitting!

Shaping Design is created on Editor X, the advanced web design platform for professionals. Create your next project on Editor X. 

There are two key needs when it comes to testing the usability of a product or application:

  1. Getting results which are accurate and trustworthy, and,

  2. 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:

  1. I think that I would like to use this system frequently.

  2. I found the system unnecessarily complex.

  3. I thought the system was easy to use.

  4. I think that I would need the support of a technical person to be able to use this system.

  5. I found the various functions in this system were well integrated.

  6. I thought there was too much inconsistency in this system.

  7. I would imagine that most people would learn to use this system very quickly.

  8. I found the system very cumbersome to use.

  9. I felt very confident using the system.

  10. 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.

The System Usability Scale questionnaire form

SUS aims to assess three core pillars of usability:

  1. Effectiveness: Can users achieve their goal?

  2. Efficiency: How much effort is exerted to meet the goal?

  3. 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:

  1. For each task, ask your test subject the ten questions mentioned above.

  2. 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).

  3. Once you have created the set of ten questions for each task, you can share the test with your participants.

  4. When they have completed the tests, you can export the data from your Google Form into a Sheets or Excel format. Ideally, aim for at least five people to complete the tests (around twenty would be great for finding most usability issues).

  5. Grading a SUS test involves some minorly complex calculations, so I would recommend using an online template to feed your data into.

Analyzing the results

Once you have the final values for each participant calculated, you can begin to analyze the tasks and their usability.

Analyzing the System Usability Scale test on a scale of 0-100

Let’s imagine we had run our tests and these were the outcomes for the three tasks:

  1. Outcome 44/100 - Filtering the cars by make

  2. Outcome 81/100 - Sorting cars by price (low-to-high)

  3. Outcome 62/100 - Contacting the dealership to request a test-drive.

Using the grading system above, we know that:

  • Task #1 performed the worst and would be considered ‘not acceptable’ in the acceptability ranges, an ‘F’ in the grade scale and ‘poor’ in the adjective ranges.

  • Task #2 performed the best and would be considered ‘acceptable’ in the acceptability ranges, a ‘B’ in the grade scale and ‘good’ in the adjective ranges.

  • Task #3 performed alright and would be considered ‘marginally acceptable’ in the acceptability ranges, a ‘D’ in the grade scale and ‘OK’ in the adjective ranges.

These insights would indicate that we probably need to rethink how users can filter the cars by make. We could also take another look at how they can contact the dealership for their test-drive, as there appeared to be some problem with that flow too.

This was a pretty straightforward example, and you may have times where you’d want to add more tasks. However, I’d suggest you consider keeping the number of tasks below five. This is because each task requires the participant to answer ten questions, which can get tedious if they’re sat there for too long.

Sounds great, why haven’t I heard of this before?

This is the oddity of SUS. As effective of a technique as it is, unless you are a usability expert it is unlikely that you’ve probably ever come across it before. It’s not available as a template in most paid usability testing suites, and nobody in the inner-circles of design is talking about it.

In addition, due to its nature as a method created to test office systems, it has a reputation for being “quick and dirty." I would argue that it is in fact the complete opposite.

For one thing, it certainly isn’t too quick. Users are met with ten questions per task, which is going to become laborious if you ask for too much in one sitting. In addition, the calculations you have to compute before being able to analyze the results also take time.

SUS definitely isn’t “dirty” either. According to most research papers on the topic (SUS is mentioned in over 1300 articles) and from my own personal experience as a UX designer, the results always tend to be fairly close to reality.

This is why I’d say that SUS is, in fact, accurate and proven rather than “quick and dirty.” Hopefully, you will give it a try the next time you’re seeking insights from your users and will find this technique useful and valuable.

A woman sitting at a desk and filling out a questionnaire