Measuring UX with Quantitative Metrics: SUS, NPS, and CSAT

SUS is a validated 10-item questionnaire developed by John Brooke in 1986 that produces a single usability score from 0 to 100. Despite its age, it remains the most widely used standardised usability instrument because it is quick (2 minutes to complete), reliable across industries, and has a large benchmark database. The 10 items alternate between positive and odd-numbered items (1,3,5,7,9) and negative even-numbered items (2,4,6,8,10), each rated 1–5. Scoring: sum (odd item scores − 1) + (5 − even item scores), then multiply by 2.5 to get 0–100. Interpretation using the Bangor adjective scale: below 51 = Awful, 51–68 = Poor (below average), 68–80.3 = Good (above average), 80.3–90.9 = Excellent, above 90.9 = Best Imaginable. An industry average SUS is approximately 68. Administer after participants complete representative tasks, not after a tour of features.

Net Promoter Score (NPS) asks 'How likely are you to recommend [product] to a colleague? (0–10)'. Promoters (9–10) minus Detractors (0–6) equals NPS (-100 to +100). NPS measures loyalty and word-of-mouth potential — it is a lagging indicator that reflects the overall relationship with the product. Benchmark: SaaS average NPS is approximately +30. Customer Satisfaction Score (CSAT) asks 'How satisfied were you with [specific interaction]? (1–5 or 1–7)'. Report as percentage of satisfied responses (4–5 or 5–7). CSAT measures satisfaction with a specific touchpoint — it is a leading indicator that can catch problems before they affect NPS. Customer Effort Score (CES) asks 'How much effort did it take to complete [task]? (1–7, low to high)'. CES is the strongest predictor of churn because high-effort interactions drive abandonment. Use NPS quarterly for overall health, CSAT on critical transactional touchpoints, and CES on support interactions and complex workflows.

Administer SUS immediately after a user completes a representative task session — the score reflects the interaction being measured, not general feelings about the product. A minimal accessible SUS implementation:

1<!-- SUS Survey Form - WCAG 2.1 AA compliant -->
2<form id="sus-form" aria-labelledby="sus-title">
3  <h2 id="sus-title">Quick usability feedback (2 minutes)</h2>
4  <p>For each statement, select how much you agree or disagree.</p>
5
6  <!-- Render all 10 SUS items with correct polarity labelling -->
7  <fieldset>
8    <legend>1. I think that I would like to use this system frequently.</legend>
9    <div role="radiogroup" aria-label="Agreement scale 1 to 5">
10      <label><input type="radio" name="sus1" value="1" required> 1 Strongly disagree</label>
11      <label><input type="radio" name="sus1" value="2"> 2</label>
12      <label><input type="radio" name="sus1" value="3"> 3</label>
13      <label><input type="radio" name="sus1" value="4"> 4</label>
14      <label><input type="radio" name="sus1" value="5"> 5 Strongly agree</label>
15    </div>
16  </fieldset>
17  <!-- Repeat fieldset pattern for items 2-10 -->
18
19  <button type="submit">Submit feedback</button>
20</form>
21
22<script>
23function calculateSUS(responses: Record<string, number>): number {
24  // Odd items (1,3,5,7,9): score - 1
25  // Even items (2,4,6,8,10): 5 - score
26  const oddItems = [1, 3, 5, 7, 9];
27  const evenItems = [2, 4, 6, 8, 10];
28  let total = 0;
29  oddItems.forEach(i => { total += (responses[`sus${i}`] - 1); });
30  evenItems.forEach(i => { total += (5 - responses[`sus${i}`]); });
31  return total * 2.5; // Scale to 0-100
32}
33
34document.getElementById('sus-form')!.addEventListener('submit', async (e) => {
35  e.preventDefault();
36  const formData = new FormData(e.target as HTMLFormElement);
37  const responses = Object.fromEntries(
38    [...formData.entries()].map(([k, v]) => [k, Number(v)])
39  );
40  const score = calculateSUS(responses);
41  await fetch('/api/feedback/sus', {
42    method: 'POST',
43    headers: { 'Content-Type': 'application/json' },
44    body: JSON.stringify({ score, responses, page: location.pathname, ts: Date.now() })
45  });
46});
47</script>

A UX scorecard tracks multiple metrics over time with defined targets, providing a single-page view of experience health for stakeholders. Structure: one row per metric (SUS, NPS, CSAT by touchpoint, CES on key workflows, task completion rate on critical paths). Columns: current score, previous score, target, trend (up/down/stable), and the research finding or product change that explains the movement. Update the scorecard on a defined cadence: SUS and NPS quarterly, CSAT and CES monthly, task completion rate after each major release. Set targets based on industry benchmarks and your own baseline: a realistic initial target is to move SUS from below-average (under 68) to above-average (above 68) within two quarters of focused usability improvements. Publish the scorecard to all stakeholders, not just the design team — when engineering leads see that their API changes affected the SUS score, they make different tradeoff decisions.

UX metrics earn organisational credibility when linked to business metrics that executives already track. The standard connections: SUS improvement correlates with reduced support ticket volume (measurable in Zendesk or Intercom data). NPS improvement correlates with increased referral traffic and organic sign-ups (measurable in acquisition data). CES reduction correlates with decreased churn rate (measurable in subscription analytics). CSAT improvement on checkout correlates with conversion rate improvement (measurable in revenue data). Build a simple correlation analysis: plot your UX metric scores against the corresponding business metric over 6–12 months. A positive correlation (both trending in the same direction) provides evidence for the business case for UX investment. Present this as 'when SUS increased from 62 to 74 between Q1 and Q3, support tickets per active user decreased by 23%' — concrete and credible.