“Users seem happier” isn’t a number you can defend in a stakeholder review.
Picture the moment right after a stakeholder review. Someone asks, “We rebuilt the whole purchase experience – is it actually better than what we had?” You have qualitative notes, a few strong quotes, maybe a gut feeling. What you don’t have is a number you can put on a slide and defend.
That’s the exact problem the System Usability Scale (SUS) was designed to solve, and why it’s stayed relevant over the years. Created in 1986, SUS turns subjective impressions into a single, benchmarkable score. It won’t tell you exactly what’s wrong with your product, but it will tell you, reliably and quickly, whether you have a problem worth investigating.
This guide covers what SUS is, how it’s structured, how to score and interpret it, when it’s the right tool (and when it isn’t), and the mistakes that most often undermine it.
- The System Usability Scale (SUS) is a standardized 10-item questionnaire used to measure users’ perceived usability of a product, website, app, or other system.
- Participants respond to 10 statements on a five-point Likert scale, ranging from strongly disagree to strongly agree.
- SUS produces a score from 0 to 100. The score is not a percentage, and a score of 68 is commonly used as a benchmark representing the average across established SUS datasets.
- SUS is useful for benchmarking perceived usability, comparing designs, and tracking changes over time, but it does not identify specific usability problems or explain user behavior.
- A SUS score doesn’t come with an action attached. It tells you where you stand, not what to change next, so pair it with behavioral methods like task success rate or error rate that can explain the “why.”
- Administer it immediately after a task-based session, not as a standalone survey, and track it over time rather than reacting to any single result.
- Running SUS inside a research platform keeps the score attached to the tasks and session data behind it, rather than leaving it as a standalone survey result.
What is the System Usability Scale (SUS)?
In 1986, John Brooke was working at Digital Equipment Corporation and needed a fast, reliable way to gauge how usable the systems his teams were building actually were. He created a 10-question survey that took most users under two minutes to complete. Nearly 40 years later, that same questionnaire is still the most widely used tool of its kind, largely because it hasn’t needed to change: the wording is fixed, which is exactly what makes scores comparable across products and over time.
SUS is administered at the end of a usability test, after a participant has completed one or more realistic tasks, not as a cold survey with no task context behind it. Because it captures an overall impression of a system rather than feedback on a single feature, it’s most useful in quantitative usability testing, where the goal is a comparable score rather than a list of specific problems. Enough SUS data has been collected across products and industries over time that a single score can be judged not just against your own baseline, but against a global distribution of results.
The questionnaire itself consists of 10 statements, rated on a 5-point scale from Strongly Disagree to Strongly Agree. The statements alternate between positive and negative wording on purpose: the odd-numbered ones are positive, the even-numbered ones are negative. This does two things. It stops respondents from picking the same answer for every item without actually reading them, and it counters people’s natural tendency to agree with a statement just because it’s put in front of them.
💡Pro Tip: Think of SUS less as a diagnostic tool and more as a thermometer. It tells you something is worth investigating, not what that something is.
How Is System Usability Scale Measured?
SUS is made up of 10 fixed statements. Changing the wording, adding items, or removing items breaks the standardization that makes scores comparable across studies and products, so the statements below should be used exactly as written.
| # | Statement |
|---|---|
| 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. |
Each statement is rated on a 5-point scale, from Strongly Disagree (1) to Strongly Agree (5).
Notice that every statement asks about the “system” – never a specific screen or feature.
A system here can be anything a person interacts with: a website, an app, a piece of hardware, an internal tool. Whatever the participant takes it to mean is what you’ve measured, so define the scope before the session and keep it consistent across studies you plan to compare.
How to Calculate the SUS Score
- Convert each response to its numeric value (1 for ‘Strongly Disagree’ through 5 for ‘Strongly Agree’).
- For odd-numbered statements, subtract 1 from the response.
- For even-numbered statements, subtract the response from 5.
- Add up all 10 adjusted scores.
- Multiply the total by 2.5 to convert it to a 0-100 scale.
The odd and even items are adjusted differently because of the alternating wording covered earlier: flipping the “negative” items the same direction as the “positive” ones is what makes them addable in the first place.
How to Interpret the SUS Score
The 68-point average comes from Jeff Sauro’s analysis of more than 500 usability studies. It’s a median, not a target: half of all measured products score above it, half below. That makes 68 a reference point rather than a pass mark, and it’s the single most misread number in SUS.
| SUS Score | Interpretation |
|---|---|
| Below 68 | Below average |
| 68 – 80.2 | Above average |
| Above 80.3 | Excellent (Top ~10-15% of products tested) |
Sauro and Lewis later built a finer curved grading scale on top of that distribution, converting a raw score into a percentile rank: a 75 lands at roughly the 73rd percentile, a 52 at the 15th. If you need to report SUS to stakeholders who will ask “compared to what,” the percentile is the more defensible figure.
SUS is not a percentage. A score of 70 is not “70% usable.” It’s a position relative to other products, and it only carries meaning next to a comparison — your own score from last quarter, a competitor’s, or a target set before the study.
One caveat the benchmark bands don’t make obvious: the reference dataset is an average of what has been built, not of what’s achievable. It includes plenty of products with genuinely poor usability, which pulls the midpoint down. Beating 68 means you’ve beaten the typical product. It doesn’t yet mean the experience is good.
Scoring a SUS Test, Step by Step
Let’s use this illustrative example to understand how to interpret a system usability score.
Say a team tests a redesigned onboarding flow with one participant, who gives the following responses:
| Question | Response | Adjusted Score |
|---|---|---|
| 1. I think that I would like to use this system frequently | 4 | 4 – 1 = 3 |
| 2. I found the system unnecessarily complex | 2 | 5 – 2 = 3 |
| 3. I thought the system was easy to use. | 4 | 4 – 1 = 3 |
| 4. I think that I would need the support of a technical person to be able to use this system. | 1 | 5 – 1 = 4 |
| 5. I found the various functions in this system were well integrated. | 4 | 4 – 1 = 3 |
| 6. I thought there was too much inconsistency in this system. | 2 | 5 – 2 = 3 |
| 7. I would imagine that most people would learn to use this system very quickly. | 5 | 5 – 1 = 4 |
| 8. I found the system very cumbersome to use. | 2 | 5 – 2 = 3 |
| 9. I felt very confident using the system. | 4 | 4 – 1 = 3 |
| 10. I needed to learn a lot of things before I could get going with this system. | 2 | 5 – 2 = 3 |
Total adjusted score: 32
Final SUS score: 32 x 2.5 = 80
80 out of 100 might look like a percentage, but it isn’t one. SUS scores are calculated on a 0-100 scale but interpreted against the benchmark bands above, not read as a grade out of 100. In this case, 80 sits at the top edge of the “OK” band, just short of the 80.3 cutoff for “Excellent,” not at “80% of the way to perfect usability.”
💡Reminder: In a real study, this calculation runs across every participant and gets averaged. It’s not taken from a single response.
When Should You Use a System Usability Scale?
SUS is most useful when you need a standardized measure of perceived usability that you can compare across designs, products, or points in time.
Consider using it when you want to:
- Establish a usability baseline: Measure how users perceive the usability of an existing product before making changes.
- Evaluate a redesign: Compare SUS scores before and after a significant design change to see whether perceived usability has improved.
- Compare different versions: Use the same questionnaire to compare two designs or product experiences.
- Track usability over time: Repeat SUS at different stages of product development to identify changes in perceived usability.
- Benchmark against other products: Compare your score with established SUS datasets to understand how the experience performs relative to a broader reference population.
When is SUS not enough?
SUS tells you how a system is perceived, not why. A dropping score is a signal to investigate, not a diagnosis. On its own, SUS can’t tell you which screen is confusing, where users are dropping off, or how long a task actually takes.
That’s why SUS is typically paired with methods that explain behavior rather than just capture opinion: task success rate, time on task, error rate, or a structured usability test with think-aloud observation. For a broader look at these methods, see our guides on quantitative usability testing methods and how to measure UX performance.
How Different Roles May Use SUS Results
| Role | What they track with SUS | How they use it |
|---|---|---|
| Designer | Score trend before/after a specific design change | Validates whether a redesign improved perceived usability, flags when it didn’t |
| Researcher | Score alongside qualitative and behavioral data | Uses SUS as one input among several, not a standalone verdict |
| Product Manager | Score relative to product metrics, benchmark and competitor products | Understand whether usability is improving as a product evolves and in prioritizing roadmap items where it is lagging |
The important distinction is that SUS gives each role a measure of perceived usability, not a diagnosis or a business outcome. The meaning of the score still depends on the research question and the other evidence collected.
That distinction matters most when the score gets reported upward. Leadership rarely engages with SUS directly. They see it when a researcher puts it in front of them. Present a single number and you invite the wrong question (“is 74 good?”). Present the same measure across three releases and you answer the question they actually have: is this getting better? Reporting SUS as a trend, with the studies behind it still attached, is what keeps it a health check rather than a score to be argued about.
How Many Participants Do You Need for a SUS Test?
The right number depends on what you’re using the score for. If SUS is riding along in a smaller, exploratory usability test aimed at surfacing directional problems, a handful of participants can still be informative, similar to how a small qualitative test can surface most major usability issues early. But a SUS score used as a defensible benchmark, one you’ll compare against established datasets or track over time, is a quantitative measurement, and quantitative measurements need a quantitative sample size.
Nielsen Norman Group’s current guidance for quantitative UX studies recommends 40 participants as an appropriate baseline for most studies, with tighter confidence intervals requiring even more. Below that, treat a SUS score as an early signal rather than a stable, comparable figure.
Most teams don’t have the budget or timeline to recruit 40 participants for every study, and that’s fine as long as the tradeoff is explicit. A smaller sample can still tell you whether perceived usability is trending up or down. It just shouldn’t be presented as a precise benchmark figure the way a 40-participant study can be.
💡Pro Tip: Don’t add participants simply to make a SUS score look more authoritative. Start with the research decision you need to support, then determine the sample size needed to answer it.
What are the Pros and Cons of using a System Usability Scale?
SUS has remained popular because it offers something relatively rare in UX research: a standardized measure that is quick to administer and has a large body of historical data behind it. At the same time, its simplicity can make it easy to overinterpret. SUS measures perceived usability, not the complete usability of a product.
| Pros | Cons |
|---|---|
| Quick to administer, typically under two minutes per participant | Measures perception, not performance: SUS captures how usable a system felt, not how well someone actually completed a task |
| Standardized and benchmarkable: the same 10 statements have been used across decades of studies, producing a large reference dataset to compare against | Not diagnostic: a score tells you something is wrong, not what or where |
| Works for any system, not just software or websites: apps, physical products, internal tools | Opinion-based: as Jakob Nielsen has put it, opinion is one of the weakest forms of user data, since people are far better at showing you what’s difficult than explaining why |
| Repeatable across iterations, useful for tracking whether perceived usability is improving or declining over time | Consumes participant time that could otherwise go toward observing behavior or exploring specific problems |
| Simple to communicate: a single score is easier to put in front of stakeholders than a list of qualitative findings | Context-sensitive and easy to misread: scores shift with the product, tasks, participants, and study conditions, and a 0-100 number gets mistaken for a percentage or an absolute quality grade when it’s neither |
Things to Remember When Creating SUS Tests
- Use the standard wording exactly as written. Rewording, reordering, or “simplifying” the statements breaks the standardization that makes scores comparable across studies.
- Administer it immediately after the participant finishes a realistic task, not as a cold survey with no task context behind it.
- Aim for a reasonable sample size before drawing conclusions from the average. A single participant’s score isn’t representative on its own.
- Keep testing conditions consistent if you’re comparing scores over time. Different tasks, devices, or participant groups make the comparison unreliable.
- Pair the score with a behavioral method to explain the “why” behind it, rather than treating the SUS score alone as a complete usability evaluation.
Frequently asked questions
What is a good System Usability Scale (SUS) score?
A score above 80.3 is generally considered excellent, 68 to 80.2 is OK, and below 68 is considered poor relative to the broader benchmark of SUS studies.
Is a System Usability Score (SUS) score out of 100?
Yes. SUS scores range from 0 to 100, but the score is not a percentage. A score of 80 does not mean that 80% of the product is usable.
Can I use SUS during prototype testing?
Yes. SUS works with any interactive system, including prototypes, as long as participants can complete realistic tasks before answering the questionnaire.
Is SUS only for websites and software?
No. SUS was designed to be system-agnostic and works for physical products, internal tools, and hardware interfaces as well as digital products.
How many participants do I need for a reliable SUS score?
For a benchmarkable score, treat it as a quantitative study: Nielsen Norman Group recommends 40 participants as a general baseline. Smaller samples can still show a directional trend but shouldn’t be read as a precise benchmark figure.
Can I change or translate the SUS questions?
The standard wording should be preserved to keep results comparable to established benchmarks. Validated translations exist for many languages; ad hoc rewording or translation risks breaking that comparability.
How often should I run SUS tests?
There’s no fixed cadence. Many teams run it after major releases or redesigns, and some also run it periodically to track usability trends over time.
Is SUS the same as usability testing?
No. SUS is a standardized questionnaire, typically used at the end of a usability test to produce a single comparable score. Usability testing itself is the broader research method that SUS is often attached to.
Is SUS qualitative or quantitative?
SUS is a quantitative measure because participant responses are converted into a numerical score. It is often used alongside qualitative usability research to provide both a measurable result and insight into why users experienced the product as they did.
