System Usability Scale (SUS): 10 Questions and Scoring

The System Usability Scale (SUS) is a ten-item questionnaire about how usable people find a product after trying it. Responses on a 1–5 scale become a score from 0 to 100. This guide shows the calculation and how to read the result alongside what people actually accomplish.

Book a demo to explore competing workflow concepts before a human usability test. See our comparisons with human research and keep SUS scoring tied to people who have used the experience.

How to calculate a SUS score

Use John Brooke’s original ten-item questionnaire and wording after people try the product or prototype. The shortened labels below identify each item; use the original questionnaire when collecting responses.

Add the ten item scores and multiply by 2.5 to get a score from 0 to 100. Keep a missing answer missing. A calculator should not silently replace it with zero or a neutral answer.

What does a SUS benchmark score mean?

The historical average is near 68 in the studies summarized by Sauro and Lewis’s benchmarking material. It is a reference point for those studies, not a universal release threshold, a task-success percentage or a percentile. Compare suitable references and similar versions. Report the sample size and check critical task failures alongside the score.

Ask SUS after a defined product experience

Start with a usable product or prototype and a question about its use. Define the people, version, devices and tasks. Someone who only reads an onboarding promise can judge expectations. Someone who attempts the flow can report how that experience felt.

Use John Brooke’s original questionnaire and scoring instructions, hosted by AHRQ. Keep the standard ten-item order and five response choices. In that version, 1 means strong disagreement and 5 means strong agreement. Ask it after use and before the debrief, as Brooke specifies. Record which questionnaire version you used.

Define task success before the session. For an invitation flow, success might require sending an invitation with the intended permission, not just opening the sharing dialog. Record moderator help and incomplete attempts. In our UserTesting alternatives guide, we show why finishing after help needs its own code.

Example: scoring usability after an invitation task

In this hypothetical example, Roster’s product team wants a first-time user to create a workspace and send an editor invitation without help.

Read the score alongside what the person actually did. SUS summarizes how the experience felt. It cannot identify the broken interaction or certify that people can finish a critical task.

Use the odd/even scoring shown above. Each item contributes between 0 and 4. Add all ten contributions and multiply by 2.5.

Keep the original responses beside the calculation. Agreement categories have an order, but a 4 is not “twice the usability” of a 2. SUS uses a set scoring rule across the whole questionnaire.

Roster v1 is a desktop prototype for small project teams. First-time user P04 tries the workspace and editor-invitation tasks, then answers SUS before the debrief. The responses below show the arithmetic. Item numbers refer to the standard questionnaire linked above.

The contributions total 32. P04’s SUS score is 32 × 2.5 = 80.

Check the reversed scoring in your sheet. Subtracting 1 from every response would give 50 for these same answers. That difference comes entirely from incorrect coding.

SUS 80 does not mean 80% of tasks succeeded, 80% of users were satisfied or the product is at the 80th percentile. A percentile needs a suitable set of reference scores. Brooke explains the difference between scores and percentages in his retrospective on SUS.

P04’s 80 includes an unfinished invitation

Return to P04’s session. Both tasks receive neutral instructions and no moderator help.

The first prompt is: “Create a workspace for the Cedar project.” P04 completes it. The second is: “Invite Morgan to edit the Cedar project.” Before the session, the researcher defines success as sending an invitation with editor permission and seeing its pending status in the team list. Pending means invited, not that Morgan has accepted or started editing.

P04 opens the sharing dialog and selects editor access. A preview card shows the colleague’s name and permission. P04 thinks access has been granted and stops, but the invitation was never sent. The researcher records the second task as the wrong end state, not a completed invitation.

After both attempts and before discussion, P04 gives the SUS responses above. The record has one unassisted success, one wrong end state and SUS 80. The score describes perceived usability. The task record shows what happened in the prototype.

One participant’s two tasks cannot tell you that half of all users fail. Keep the person, task and score counts clear. This example shows an interpretation problem, not how often it occurs.

Check why the preview looks finished

Roster needs to know whether people understand that the invitation is unfinished. Start by checking the preview card, where P04 reaches the wrong conclusion. The SUS total cannot locate that problem for you.

During the debrief, ask what made P04 think access had been granted. Check the interaction record before blaming the wording. Button visibility, placement and a misleading confirmation state are other possible causes. One session cannot isolate their effects.

Try a design that makes the unfinished state clear and keeps the send action visible. Test it with relevant people using the same success rule. Check that they send the invitation with the intended permission and understand its pending status. Collect SUS after the same experience and report it beside the task result.

If the invitation still is not sent, a higher SUS score leaves the critical problem open. If people finish the task but feel the experience is worse, check where the friction increased. Both records matter.

Compare scores from similar experiences

When comparing versions, keep the tasks, audience, devices, questionnaire and timing of the questionnaire comparable. Record prior experience too. Existing customers and first-time users bring different histories. Explain any changes in those conditions beside the score movement.

Calculate a SUS score for each complete questionnaire first. For an average, keep the individual scores, the number included and the rule for missing answers. Do not quietly drop incomplete questionnaires or fill gaps with convenient values. Decide and document the rule before analysis.

An average should not hide a critical task failure. In our Maze alternatives guide, changing reporting rules changes completion percentages for the same attempts. Before crediting the interface for a SUS change, check what stayed comparable. A changed number alone is not proof of reliable improvement.

Check whether the invitation is actually sent

At Sapien, our team builds grounded simulated audiences and runs surveys, interviews and comparison studies. For the Roster decision, a study could compare how an audience understands different invitation explanations and what they expect next. That can help find wording worth testing in the interface.

Those simulated reactions would be ideas to test about interpretation. They cannot show that a person found a button, sent an invitation or used the product. Observe those actions in human task sessions and collect SUS from the people who tried the interface.

For Roster, the next step is a revised invitation state, a clear success rule and human sessions that show whether the misunderstanding remains. Keep SUS tied to that experience. Use the observed task outcome to judge whether the interaction works.

Related guides: NPS vs CSAT vs CES; Likert scales; sample size.

Use the NPS, CSAT and CES comparison to choose recommendation, satisfaction or effort questions. The Likert scales guide covers custom follow-up items and answer distributions. The sample size worksheet helps plan a survey share or two independent groups. Keep custom questions outside the standard ten-item SUS score.