What’s the System Usability Scale (SUS) & How Can You Use It?

Note: This article synthesizes established usability research and practical UX testing guidance; source links are intentionally not embedded in the publishable HTML as requested.

The System Usability Scale, usually shortened to SUS, is one of those UX tools that looks suspiciously simple until it quietly saves your product roadmap from becoming a bonfire. It is a 10-question survey that helps teams measure how usable a product feels to real users after they interact with it. Not how beautiful the homepage is. Not how much the founder loves the dashboard. Not how loudly the sales team says, “Customers get it.” SUS asks users directly, then turns their answers into a score from 0 to 100.

That score gives product managers, UX designers, researchers, marketers, SaaS teams, app developers, and website owners a fast way to understand perceived usability. In plain English: does this thing feel easy enough to use, or are users mentally filing a complaint while clicking around?

The beauty of SUS is that it works across many types of systems: websites, mobile apps, software platforms, checkout flows, admin dashboards, internal tools, medical portals, learning systems, kiosks, hardware interfaces, and almost anything else where humans must interact with technology without muttering into their coffee.

What Is the System Usability Scale?

The System Usability Scale is a standardized usability questionnaire developed by John Brooke in 1986. It was designed as a quick, low-cost way to capture users’ overall perception of a system’s usability. The word “system” is broad on purpose. A system can be a website, an app, a software tool, a digital service, or even a piece of equipment with an interface.

SUS consists of 10 statements. Users respond to each statement using a 5-point Likert scale, typically ranging from “strongly disagree” to “strongly agree.” The statements alternate between positive and negative wording, which helps reduce the chance that people will simply click the same answer repeatedly without thinking. Yes, survey autopilot is real. Anyone who has filled out a “quick two-minute feedback form” knows the danger.

The 10 SUS Questions

The traditional SUS questionnaire includes statements like these:

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.

For best results, do not casually rewrite these statements. The standard wording matters because SUS scores are useful partly because they can be compared against historical benchmarks. Changing the wording may make the survey feel “more on brand,” but it can also make the score less comparable. Your brand voice can have a party elsewhere; the SUS questionnaire prefers to wear a lab coat.

Why SUS Is Still Popular

SUS has survived decades of changing UX trends because it is practical. It does not require a PhD, a giant budget, or a research lab with a glass wall and dramatic lighting. Teams like it because it is short, flexible, and easy to repeat across product versions.

Here are the main reasons SUS remains useful:

It Is Quick

Users can usually complete the SUS questionnaire in a minute or two. That makes it easy to add after a usability test, prototype review, beta test, onboarding flow, or product trial. Since the survey is short, completion rates tend to be better than long questionnaires that make people feel like they accidentally signed up for jury duty.

It Produces a Simple Score

A SUS score ranges from 0 to 100. While it is not technically a percentage, it is easy for stakeholders to understand. A score of 82 sounds better than a score of 54, and nobody needs a 42-slide explanation to understand that something has improved or declined.

It Works Across Product Types

SUS is technology-neutral. You can use it for a mobile banking app, a SaaS dashboard, an e-commerce checkout, an employee portal, a healthcare form, a booking system, or a smart device interface. This makes it especially useful for teams managing multiple products or comparing different design options.

It Helps Track Progress Over Time

If you measure SUS after each major design iteration, you can see whether usability is improving. This is useful for showing the business value of UX work. “We redesigned the checkout” is nice. “We redesigned the checkout, reduced task confusion, and raised SUS from 61 to 78” is much harder to ignore.

How to Score the System Usability Scale

Scoring SUS sounds strange the first time, but it becomes simple once you understand the pattern. Each item is scored from 0 to 4, then the total is multiplied by 2.5 to create a final score from 0 to 100.

Step-by-Step SUS Scoring

For odd-numbered items, which are positively worded, subtract 1 from the user’s response.

For even-numbered items, which are negatively worded, subtract the user’s response from 5.

Then add all 10 adjusted values together and multiply the total by 2.5.

For example, imagine a participant gives responses that produce an adjusted total of 30. Multiply 30 by 2.5, and the SUS score is 75.

That score represents the user’s perceived usability of the system after the test. If you collect scores from multiple participants, calculate the average SUS score for the group.

What Is a Good SUS Score?

A commonly used benchmark is 68, which is often treated as average. A SUS score above 68 generally suggests better-than-average perceived usability. A score below 68 suggests the experience may need improvement.

However, context matters. A score of 70 might be acceptable for a complex enterprise analytics platform used by trained professionals. The same score might be disappointing for a consumer food delivery app where users expect instant clarity, friendly buttons, and zero detective work.

Basic SUS Score Interpretation

• Below 50: Serious usability problems are likely.
• 50–67: Marginal usability; users may complete tasks but with friction.
• 68: Around average.
• 70–79: Generally good usability.
• 80 or above: Strong usability and a more satisfying user experience.
• 90 or above: Excellent usability, though still worth validating with real behavior.

Do not treat the score as a magic wand. SUS tells you how usable the experience feels overall. It does not tell you exactly which button ruined someone’s afternoon. To find that out, combine SUS with task success rates, observation notes, session recordings, interviews, error counts, time-on-task data, and open-ended feedback.

When Should You Use SUS?

SUS is best used after users have interacted with the product or completed a meaningful set of tasks. Asking someone to rate usability before they use the product is like asking them to review a restaurant after staring at the menu through the window. It might be interesting, but it is not the meal.

Use SUS After Usability Testing

The most common use case is after moderated or unmoderated usability testing. Participants complete tasks, then fill out the SUS questionnaire. This gives you both behavioral data and perception data. Sometimes users succeed at tasks but still feel the system is clunky. Other times they struggle but blame themselves instead of the interface. SUS helps reveal that emotional layer.

Use SUS to Compare Design Versions

If your team is choosing between two prototypes, SUS can help compare perceived usability. For example, Prototype A may look modern but score 59 because users cannot find the primary action. Prototype B may look less glamorous but score 77 because people actually know what to do. Usability has a funny way of embarrassing visual ego.

Use SUS Before and After a Redesign

Measure the current product before redesigning it, then measure again after the new version is tested. This creates a before-and-after benchmark. It also protects the team from redesign theater, where everything looks cleaner but users are still lost in the same forest, now with prettier trees.

Use SUS for Competitive Benchmarking

You can ask participants to complete similar tasks across your product and a competitor’s product, then collect SUS scores for each. This helps identify whether your experience feels easier or harder than alternatives. It is especially useful in SaaS, fintech, e-commerce, healthcare, education technology, and digital services where switching costs and first impressions matter.

How Many Participants Do You Need?

You can use SUS with small samples, but you should be careful when interpreting the results. Five participants can uncover many usability issues in a formative test, but a SUS average from five people can swing dramatically. One frustrated participant who got stuck on a broken filter can pull the score down like an anchor.

For directional learning, small samples can be useful. For confident benchmarking, larger samples are better. Many teams aim for at least 12 to 20 participants when they want a more stable SUS estimate, and more when the result will influence major business decisions. The more diverse your user base, the more thoughtful you need to be about sampling.

Common Mistakes When Using SUS

Mistake 1: Treating SUS as a Diagnostic Tool

SUS tells you whether the system feels usable overall, not exactly why it feels that way. A low score should trigger investigation. It should not cause the team to randomly change colors, move buttons, or hold a meeting called “Make It More Intuitive,” which is usually where clarity goes to hide.

Mistake 2: Asking SUS Too Early

Users need enough exposure to judge the system. If they only saw a homepage screenshot, SUS is not the right tool. Use it after realistic tasks, flows, or product interaction.

Mistake 3: Changing the Questions

Small edits can affect comparability. If you need benchmarkable results, keep the standard SUS wording and order. You can add custom follow-up questions after SUS, but do not casually remix the original scale.

Mistake 4: Confusing SUS With Customer Loyalty

SUS measures perceived usability, not brand love, product-market fit, customer support quality, pricing fairness, or whether users would recommend you at dinner. It can complement metrics like Net Promoter Score, Customer Satisfaction Score, and Customer Effort Score, but it should not be forced to do every job in the analytics toolbox.

Mistake 5: Ignoring User Segments

An average score can hide important differences. New users may score the product at 55 while experienced users score it at 82. That does not mean the product is “fine.” It may mean onboarding is a swamp and power users have simply learned where the alligators are.

A Practical Example of SUS in Action

Imagine a SaaS company has redesigned its reporting dashboard. The old dashboard had a SUS score of 62. Users could generate reports, but they complained about confusing filters, unclear labels, and a layout that felt like a spreadsheet had swallowed a maze.

The team builds a new prototype and runs a usability test with 18 target users. Each participant completes four tasks: create a report, filter by date, export the results, and share the report with a teammate. Afterward, each person completes the SUS questionnaire.

The new design receives an average SUS score of 78. Task success also improves, and interview comments show that users find the new filter structure easier to understand. This does not mean the product is perfect. But it gives the team evidence that the redesign improved perceived usability and reduced friction in important workflows.

Now the product manager can walk into the roadmap meeting with something stronger than “people liked it.” They can say, “The redesign improved our SUS score from 62 to 78, increased task success, and reduced confusion around filters.” That is the sound of UX research wearing a tiny business suit.

How to Use SUS Results to Improve UX

1. Pair Scores With Observations

Watch what users do before asking what they think. If someone says the system was easy but spent eight minutes looking for the save button, believe the behavior too. SUS is strongest when paired with usability test observations.

2. Look for Patterns in Low-Scoring Sessions

Review sessions from participants who gave low SUS scores. Did they fail the same task? Did they hesitate at the same screen? Did they misunderstand the same label? Patterns reveal where design changes may have the biggest impact.

3. Segment by User Type

Compare new users, returning users, power users, administrators, mobile users, desktop users, or any group that matters to your product. This can expose usability gaps that an overall average would hide.

4. Track SUS Over Time

One SUS score is a snapshot. Repeated SUS measurement is a trend. Track scores after major releases, redesigns, onboarding changes, and feature launches. Over time, the trend can show whether usability is getting better, worse, or simply wearing a fake mustache.

5. Share the Score in Plain Language

Stakeholders do not always need a statistical lecture. Translate SUS into meaning: “Our score is below average,” “The new design performs better than the old one,” or “Experienced users are satisfied, but first-time users struggle.” Clear interpretation helps teams act.

SUS vs. Other UX Metrics

SUS is useful, but it should not be your only usability metric. A complete UX measurement plan often includes both qualitative and quantitative data.

• Task success rate: Did users complete the task?
• Time on task: How long did it take?
• Error rate: How often did users make mistakes?
• Single Ease Question: How easy was one specific task?
• Customer Satisfaction Score: How satisfied are users?
• Net Promoter Score: How likely are users to recommend the product?
• SUS: How usable does the system feel overall?

Think of SUS as a thermometer. It can tell you whether the product has a usability fever. But you still need diagnosis, treatment, and possibly someone brave enough to delete that confusing settings page.

Best Practices for Running a SUS Study

Recruit Realistic Users

SUS is only as useful as the people answering it. Recruit participants who resemble your actual users. If your product is for hospital administrators, do not test only with your cousin who “uses apps a lot.” Helpful person, wrong sample.

Give Users Realistic Tasks

Ask participants to complete tasks that reflect real goals. “Click around and tell us what you think” produces vague feedback. “Create a monthly sales report and share it with your manager” produces meaningful behavior.

Administer SUS Immediately After the Test

Ask users to complete SUS while the experience is fresh. Waiting too long can blur details and weaken the connection between the interaction and the rating.

Keep the Survey Neutral

Do not coach users before they answer. Avoid saying things like, “Most people found this easy.” That is not research; that is peer pressure with a clipboard.

Analyze Comments Alongside Scores

Add one or two open-ended questions after SUS, such as “What was most frustrating?” or “What would make this easier?” These comments can explain the score and guide design improvements.

Real-World Experience: What Teams Learn When They Actually Use SUS

In practice, SUS often becomes most valuable when teams stop treating it as a vanity number and start treating it as a conversation starter. A score by itself can feel tidy, but the real value comes from asking what caused that score and what should happen next.

Consider a product team working on a customer support portal. Before testing, everyone assumes the biggest usability issue is the search bar. It looks old, the results page is crowded, and one executive has described it as “visually tragic,” which is harsh but memorable. The team runs a usability test and collects SUS responses. The score comes back at 64, slightly below average. The obvious conclusion might be, “Fix search.” But session recordings show something more interesting: users are not failing because of search results. They are failing because the portal uses internal company language instead of customer language. People search for “refund,” but the interface says “payment reversal.” People look for “cancel plan,” but the menu says “subscription lifecycle actions.” Somewhere, a jargon goblin is smiling.

In that situation, SUS helps confirm that users feel friction, but the observational data explains why. The team updates labels, simplifies navigation, and reruns the test. The SUS score rises to 76. The lesson is simple: the number pointed to the smoke, but the research found the fire.

Another common experience happens after redesigns. A team may launch a cleaner interface and expect SUS to skyrocket. Instead, the score barely moves. This can feel disappointing until researchers examine user comments. Sometimes the new design is prettier but does not solve the primary workflow problem. Users may still need six clicks to complete a common task. They may still be unsure whether their changes were saved. They may still need to open three tabs, whisper a small prayer, and hope the export button works. SUS prevents the team from confusing aesthetic improvement with usability improvement.

SUS can also help calm internal debates. Without user data, design meetings can become opinion wrestling. One person says the sidebar is obvious. Another says it is invisible. A third person suggests adding a tooltip, because tooltips are where unresolved decisions go to retire. With SUS and usability observations, the team can shift from “I think” to “Users experienced.” That change alone can improve product decisions.

The best teams use SUS repeatedly. They establish a baseline, improve the product, test again, and watch the trend. A single score of 72 is useful. A pattern showing 61, 68, 75, and 81 across four releases is much more powerful. It tells a story of usability maturity. It also gives UX teams credible evidence when asking for more research time, design resources, or engineering support.

One practical tip from real-world use: always explain SUS scores carefully to stakeholders. Because the score is out of 100, people often assume it is a percentage. It is not. A SUS of 80 does not mean users completed 80% of tasks. It means the perceived usability score, calculated from the standardized questionnaire, is strong relative to common benchmarks. Clear explanation prevents confusion and keeps the metric honest.

Finally, SUS teaches humility. A product team can spend months polishing features only to watch users stumble on the first screen. That is not failure; it is information. SUS gives teams a structured way to listen. And in UX, listening is often the difference between a product that users tolerate and a product they trust.

Conclusion

The System Usability Scale is popular because it does something rare: it makes usability measurable without making the process painfully complicated. With 10 questions, a simple scoring method, and decades of practical use behind it, SUS gives teams a reliable way to understand how usable a product feels to real people.

Use SUS after meaningful product interaction, score it consistently, compare it against benchmarks, and combine it with behavioral research. Do not worship the number, but do not ignore it either. A good SUS process can reveal whether your website, app, or software is helping users move smoothly toward their goals or quietly making them consider a career change just to avoid using your interface again.

In a digital world where users have limited patience and endless alternatives, usability is not decoration. It is business infrastructure. SUS helps you measure it, discuss it, and improve it before your users start improving their lives by switching to a competitor.