
SUS (System Usability Scale): how to apply and read it
The System Usability Scale is a ten-item questionnaire that rates perceived usability from 0 to 100. How to calculate it, what 68 means and what its limits are.
What is it and where does it come from?
John Brooke published it in 1996 as a chapter titled “SUS-A Quick and Dirty Usability Scale”, in the book Usability Evaluation in Industry. Its name explains its intent: a low-cost scale for global evaluations. According to the UCL page that records it, the scale uses five response points, from “Strongly disagree” to “Strongly agree”.
The ten statements alternate between positive and negative. MeasuringU lists them, in English, as: “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”; and “I needed to learn a lot of things before I could get going with this system”.
How is it calculated?
The calculation is simple, and worth understanding before you use it:
- For the odd items (1, 3, 5, 7 and 9), which are positive, subtract 1 from the response.
- For the even items (2, 4, 6, 8 and 10), which are negative, subtract the response from 5.
- Sum the ten results and multiply by 2.5.
The result runs from 0 to 100. MeasuringU warns that this number is not a percentage. A 70 does not mean the system is 70% usable; it means its perceived usability is above the average of other systems evaluated.
Brooke cautioned that scores for individual items are not meaningful on their own, a line MeasuringU quotes in its analysis of single items. What matters is the total.
How do you read the result?
Based on about 500 studies, MeasuringU places the average at 68. Above that value a system is above average; below it, below average. MeasuringU recommends reading it as a percentile: a 74 is above 70% of the products evaluated, and for an A grade you need to exceed 80.3, which corresponds to the top 10%.
NN/g also cites the average of 68 from 500 studies, and notes that a 73 sits in the top 30%. That confirms the number is better read comparatively than in absolute terms. A team that moves from 61 to 74 has a clear signal of improvement, even though a 74 on its own says little.
How many users do you need?
The sources do not fully agree. MeasuringU argues that reliability does not depend on sample size and that the scale can be used even with two users, but warns that small samples give imprecise estimates, so a confidence interval is worth calculating. NN/g is more cautious: it notes that quantitative questionnaires typically need at least 20 to 30 users, and that with five the results are not significant.
A practical reading: if you need to compare two versions with a small difference, aim for a sample that gives you a reasonable confidence interval. If you only want a signal that something got much better or worse, a smaller sample may be enough.
When should you use it?
NN/g recommends applying it after the test, in summative studies, to compare with earlier iterations or with competitors. Qualitative formative tests do not need it: to discover problems, observation is more useful. Its greatest value comes when it is repeated with the same questionnaire over time.
One point is often overlooked: do not change the order or wording of the items if you want to compare with other designs. A modified questionnaire is no longer the SUS, and its results cannot be compared with the average of 68.
Relation to other metrics
The SUS measures how users feel, not how they behave. MeasuringU notes that its correlation with task performance is modest (r ≈ .24, meaning it explains about 6% of what happens in a test), so someone can struggle with a product and still give it a high SUS score. So combine it with behavioural measures such as task success and time on task, and with the indicators the team uses, such as KPIs or the North Star Metric.
For the difference between measuring how something works and measuring what changes, the note on generative versus evaluative research helps place the SUS in the right phase.
Example
Illustrative example: a team at a small-bank app administers the SUS to 30 people before and after redesigning the transfer flow. The previous version scores 58 and the new one 74. The team does not stop at the number: it reviews which items improved most, and notices that the item about needing technical help drops noticeably. It also measures the share of transfers completed without calling support, because the SUS alone does not say whether people finished the task. Both signals point in the same direction, and the team presents the change with both data points.
For your next test: if you use the SUS, record the score for the previous and the new version, and also measure one task. The comparison then has two legs.
When should you NOT use it?
- When the question is which problem exists. The SUS does not identify specific problems.
- When there are very few users and the result will be presented as definitive.
- When the questionnaire has been changed. It is no longer comparable with the average.
- When it is used as a grade to evaluate people or teams.
Common mistakes
- Reading the score as a percentage of usability.
- Comparing with a grading table from another source without checking its cut-offs.
- Forgetting to reverse the even items when calculating by hand.
- Presenting a small difference as an improvement without a confidence interval.
- Using the SUS alone, without measuring behaviour in tasks.
- Changing the questions and still comparing with the average.
Sources
- SUS-A Quick and Dirty Usability Scale, John Brooke (1996), UCL ConstructDB
- Measuring Usability with the System Usability Scale (SUS), MeasuringU (Jeff Sauro, 2011)
- The SUS items, MeasuringU
- Interpreting Single Items from the SUS, MeasuringU (Jeff Sauro, 2018)
- Beyond the NPS: Measure Perceived Usability with the SUS, NASA-TLX, and the Single Ease Question, Nielsen Norman Group (Page Laubheimer, 2018)