How to Run a SUS Survey: A Step-by-Step Guide
You've read about the System Usability Scale. You know what a good score looks like. Now you want to actually run one.
This is the practical guide. By the end of it, you'll know who to survey, when to send it, how many responses you need, and what to do with the results when they come back.
Step 1: Decide what you're measuring
Before you send anything, be clear about what you're evaluating. SUS is technology-independent — it works equally well on a web app, a mobile app, a desktop tool, or a physical device — but it works best when the scope is specific.
Are you measuring your entire product? A specific flow, like onboarding or checkout? A new feature you've just shipped?
The narrower the scope, the more useful the signal. If you ask users to rate the whole product, you'll get a broad usability picture. If you ask them to rate the onboarding experience specifically, you'll get a more precise reading on that part of the journey.
For most teams running SUS for the first time, measuring the whole product is the right starting point. It gives you a baseline. You can get more specific once you know where to look.
Step 2: Choose your participants
SUS should be completed by people who represent your actual users — not colleagues, not friends, not people who happen to be nearby.
This matters more than sample size. Ten responses from the right people will tell you more than fifty responses from the wrong ones.
A few principles:
They should have used the product. SUS measures perceived usability, which requires actual experience. Don't ask people who've only seen a demo or watched a walkthrough.
They should match your target audience. If your product is for small business owners, survey small business owners — not developers or designers who will approach it with a completely different mental model.
They don't need to be power users. In fact, newer users often give you the most useful signal. Experienced users adapt to friction over time and stop noticing it.
Step 3: Decide on sample size
The good news about SUS is that it's statistically reliable at small sample sizes. You don't need hundreds of responses.
As a practical guide:
- 5 responses — gives you a rough directional signal, useful for very quick checks
- 12–15 responses — reliable enough for most product decisions
- 20+ responses — high confidence, suitable for reporting to stakeholders or benchmarking against previous scores
If you're running SUS regularly across releases, consistency matters more than perfection. Twelve responses per run, from comparable users each time, will give you a trend line you can trust.
Step 4: Time it correctly
When you ask users to complete the survey matters almost as much as who you ask.
SUS should be administered after users have had a genuine interaction with the product — not before, and not so long after that the experience has faded.
The two most common approaches:
Post-session — immediately after a usability test or a specific task. This gives you the freshest possible impression and is the approach SUS was originally designed for.
Post-onboarding — sent a few days after a user first signs up and has had time to explore. This is more practical for teams without a formal research process and gives a more representative view of the real-world experience.
Avoid sending SUS surveys to users who signed up months ago and have been using the product heavily. Long-term familiarity masks usability problems — experienced users adapt to friction and stop noticing it.
Step 5: Write your survey introduction
The ten SUS questions are fixed — you don't change them. But the introduction you write before the questions sets the context and affects response quality.
Keep it short. Tell users:
- What you're asking them to evaluate (the specific product or feature)
- That there are no right or wrong answers — you want their honest impression
- That it will take less than two minutes
A simple example:
"We'd love to know how easy [product name] is to use. Please answer the following ten questions based on your experience so far. There are no right or wrong answers — we're looking for your honest first impression. It should take less than two minutes."
Don't prime them with positive language ("we hope you're enjoying the product") or negative framing ("we know there are some issues"). Keep it neutral.
Step 6: Send the ten questions
The SUS questionnaire is standardised. The exact wording matters — don't paraphrase or reorder the questions. Users rate each statement on a scale of 1 (Strongly Disagree) to 5 (Strongly Agree).
The ten statements are:
- 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.
One practical note: replace "system" with the name of your product if it reads more naturally. "I thought [product name] was easy to use" is fine and makes the survey feel less generic.
Step 7: Calculate the score
The scoring method is slightly counterintuitive because the questions alternate between positive and negative framing. Here's how it works:
For odd-numbered questions (1, 3, 5, 7, 9): Subtract 1 from the user's response.
For even-numbered questions (2, 4, 6, 8, 10): Subtract the user's response from 5.
Add all ten adjusted values together and multiply by 2.5. The result is your SUS score for that user, on a scale of 0 to 100.
To get your overall score, average the individual scores across all respondents.
If this sounds fiddly, it is. Most teams build a spreadsheet template to handle the calculation, or use a tool that does it automatically.
Step 8: Interpret the result
Once you have your score, here's how to read it:
| Score | Grade | What it means |
|---|---|---|
| Above 90 | A+ | Exceptional — users find it delightfully easy |
| 80–90 | A | Excellent — above this threshold, users are likely to recommend |
| 68–80 | B/C | Above average — workable, but room to improve |
| 68 | C | The industry average |
| 51–67 | D | Below average — users are experiencing meaningful friction |
| Below 51 | F | Serious usability problems requiring immediate attention |
Remember: 68 is average, not good. If you're celebrating a score in the low 70s, you're at a C grade. Aim for 80 and above — that's where users start actively recommending the product to others.
Step 9: Don't stop at one score
A single SUS score is a snapshot. Useful, but limited.
The real value of SUS comes from tracking it over time — running the survey at consistent intervals and watching the trend line. A score of 71 today means very little on its own. A score that has moved from 58 to 71 across four releases tells you that your team's usability work is having a measurable effect.
Build SUS into your release cycle. Run it after every significant change. Give yourself something to beat each time.
The shortcut
Everything above can be done manually — a Google Form for the survey, a spreadsheet for the scoring, a chart you update by hand after each run.
That works, especially when you're getting started. But it creates friction, which means it tends not to happen consistently. The survey doesn't go out after the next release because someone forgot. The spreadsheet doesn't get updated because no one owns it. The trend line never forms.
UXScore handles the survey, the scoring, and the tracking automatically — so running SUS regularly becomes a habit rather than a project.
Share this post
Back to Blog