System Usability Scale: score SUS and decide what to fix

A participant can give your product an encouraging usability score and still fail the task that matters most. The useful response is to examine both records: how the experience felt, and what the person actually accomplished.

The System Usability Scale, or SUS, summarizes perceived usability through ten questionnaire items. It produces a score from 0 to 100. That number can accompany a product decision, but it does not identify the broken interaction or certify that people can complete a critical task.

Here is how to calculate the score correctly, then use a disagreement between SUS and observed behavior to choose a specific design change.

Give SUS a defined experience to summarize

Start with a usable product or prototype and a question about its use. Define the relevant participants, version, device and tasks. Someone who has only read an onboarding promise is judging an expectation; someone who has attempted the flow can report on that experience.

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. Administer it after use and before the debrief, as Brooke specifies. Record which questionnaire version you used.

Define task success separately, before the session. For an invitation flow, success could require sending an invitation with the intended permission, rather than opening a sharing dialog. Retain moderator assistance and incomplete attempts. In our UserTesting alternatives guide, we show why eventual completion after help needs its own code.

Calculate SUS without reversing the wrong items

The items alternate direction. For odd-numbered items, subtract 1 from the response. For even-numbered items, subtract the response from 5. Each contribution is between 0 and 4. Add the ten contributions, then multiply by 2.5.

Keep the raw responses beside the calculation. They are ordered agreement categories; a response of 4 is not “twice the usability” of a response of 2. SUS applies a prescribed scoring transformation across the complete instrument.

Consider this entirely fictional human research session. Roster v1 is a desktop prototype that helps small project teams create workspaces and invite colleagues. The team wants a first-time user to create a workspace and send an editor invitation without help. P04, a first-time user, attempts both tasks, then answers SUS before the debrief. The invented responses below demonstrate the arithmetic; they are not collected data, a Sapien result or a population estimate. Item numbers refer to the standard questionnaire linked above.

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

Check the reversal once in your scoring sheet. If you subtract 1 from every response, these same responses produce 50, a different answer caused entirely by incorrect coding.

SUS 80 does not mean 80% of tasks succeeded, 80% of users were satisfied or the product occupies the 80th percentile. A percentile needs an appropriate reference distribution. Brooke makes the distinction between scores and percentages explicit in his retrospective on SUS.

An 80 can sit beside a failed task

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 a sharing dialog and selects editor access. A preview card displays the colleague’s name and permission. P04 says the colleague now has access and stops. The invitation was never sent. The researcher codes the second task as the wrong end state, rather than accepting the participant’s belief as completion.

After both attempts and before discussion, P04 supplies the questionnaire responses shown above. The record therefore contains one unassisted success, one wrong end state and SUS 80. These observations can coexist: the questionnaire summarizes the perceived experience, while the task record establishes what happened in the prototype.

Do not turn one participant’s two tasks into a claim that half of all users fail. Keep the participant, task and score units visible. This constructed session demonstrates an interpretation problem, not how often that problem occurs.

Use the disagreement to choose the next change

For Roster, the release question is whether people understand that the invitation is unfinished. The preview card is a specific place to investigate because the mistaken conclusion occurs there. The SUS total cannot locate that point for you.

In the debrief, ask what made P04 believe access had been granted. Review the interaction record before deciding that wording caused the error. Button visibility, placement or a misleading confirmation state are competing explanations. A single session does not isolate their effects.

A reasonable next design candidate would make the unfinished state explicit and keep the send action visible. Test the revised flow with relevant people under the same success definition. Look for the invitation being sent with the intended permission, and for the participant correctly understanding its pending status. Collect SUS again after the defined experience, keeping the task result alongside it.

If the invitation still is not sent, an improved SUS total leaves the critical problem unresolved. If people complete the task but report a worse experience, inspect the new friction. You need both records to judge the change.

Compare versions without changing the question

For a version comparison, retain the task set, audience definition, device scope, questionnaire and administration point. Record prior experience too: established customers and first-time users bring different histories. If those conditions change, explain them beside the score movement.

Calculate each complete respondent’s SUS score first. When reporting an average, retain the underlying individual scores, the number included and the treatment of missing responses. Do not quietly drop incomplete questionnaires or replace missing answers with convenient values. Set and document the handling rule before analysis.

Averages should not erase a critical task failure. In our Maze alternatives guide, the same attempts produce different completion percentages when reporting rules change. A SUS comparison deserves the same care: establish what stayed comparable before crediting the interface for a movement. A changed number alone does not establish a reliable improvement.

Research the language, then observe the use

At Sapien, our team builds grounded simulated audiences and runs surveys, interviews and comparison studies. For the Roster decision, a scoped study could explore how an audience interprets alternative invitation explanations and what they expect to happen next. That can help identify language worth testing in the interface.

Those modeled reactions would remain hypotheses about interpretation. They would not establish that a person found the button, sent the invitation or experienced the product. Observe those actions in human task sessions and collect the questionnaire responses from the people who used the interface.

The useful handoff for Roster is a revised invitation state, a clear task-success rule and a human session that can show whether the misunderstanding remains. Keep the SUS score attached to that experience. Let the observed outcome determine whether the critical interaction works.