Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa kết thúc một buổi usability testing với 8 người dùng cho ứng dụng đặt vé xe khách của công ty. Sếp hỏi bạn: "Vậy sản phẩm mình dễ dùng hay khó dùng? Lần này so với phiên bản trước thì sao?" Nếu bạn chỉ trả lời "À, nhìn chung họ thấy ổn, một vài người hơi lúng túng ở bước thanh toán" thì câu trả lời đó vừa mơ hồ, vừa không thể so sánh được qua các lần đo, và càng không thể đem ra so với đối thủ.
Đây chính là khoảng trống mà SUS — System Usability Scale lấp vào. SUS cho bạn một con số duy nhất từ 0 đến 100 đại diện cho cảm nhận tổng thể của người dùng về mức độ dễ sử dụng của sản phẩm. Con số đó đã được chuẩn hoá (standardized), nghĩa là điểm SUS của ứng dụng bạn có thể đem so với hàng trăm sản phẩm khác trên thế giới, so với chính sản phẩm của bạn ở quý trước, hoặc so với đối thủ trực tiếp.
Trong toàn bộ khoá học này, bạn đã và sẽ học nhiều phương pháp đo lường — bài usability testing dạy bạn cách quan sát người dùng, các bài về NPS hay analytics đo những thứ khác. Riêng bài này, chúng ta tập trung hoàn toàn vào SUS: nó là gì, vì sao nó đặc biệt, cách tính điểm chính xác, cách diễn giải con số đó cho đúng, và những cái bẫy khiến nhiều người dùng SUS sai mà không biết. Đây là một trong những công cụ định lượng rẻ nhất, nhanh nhất và đáng tin cậy nhất mà một UX researcher cần nắm vững.
Khái niệm cốt lõi
SUS là gì?
SUS là một bộ 10 câu hỏi dạng Likert (thang đo từ 1 = Hoàn toàn không đồng ý đến 5 = Hoàn toàn đồng ý) do John Brooke tạo ra năm 1986 khi ông làm việc tại Digital Equipment Corporation. Ban đầu ông gọi nó nửa đùa là "quick and dirty" — một cách đo nhanh và đơn giản. Nhưng gần 40 năm sau, nó trở thành một trong những thang đo usability được trích dẫn và sử dụng nhiều nhất thế giới, chính vì nó đơn giản mà vẫn đáng tin cậy.
Điểm mấu chốt khiến SUS mạnh là tính chuẩn hoá: bất kể bạn đo website ngân hàng, app gọi xe, phần mềm kế toán hay máy ATM, bộ 10 câu vẫn gần như giữ nguyên (chỉ thay từ "system" thành tên sản phẩm). Nhờ đó điểm số có thể đặt cạnh nhau và so sánh được — điều mà một bảng khảo sát tự chế không bao giờ làm được.
10 câu hỏi gốc
Đặc trưng thông minh nhất của SUS là cách nó xen kẽ câu tích cực và câu tiêu cực. Câu lẻ (1, 3, 5, 7, 9) viết theo hướng tích cực; câu chẵn (2, 4, 6, 8, 10) viết theo hướng tiêu cực:
- Tôi nghĩ rằng tôi sẽ muốn sử dụng hệ thống này thường xuyên.
- Tôi thấy hệ thống này phức tạp một cách không cần thiết.
- Tôi thấy hệ thống này dễ sử dụng.
- Tôi nghĩ tôi sẽ cần sự hỗ trợ của người có chuyên môn để có thể dùng được hệ thống này.
- Tôi thấy các chức năng trong hệ thống này được tích hợp tốt với nhau.
- Tôi thấy hệ thống này có quá nhiều điểm thiếu nhất quán.
- Tôi nghĩ hầu hết mọi người sẽ học cách dùng hệ thống này rất nhanh.
- Tôi thấy hệ thống này rất rườm rà/cồng kềnh khi sử dụng.
- Tôi cảm thấy rất tự tin khi sử dụng hệ thống này.
- Tôi cần học rất nhiều thứ trước khi có thể bắt đầu dùng hệ thống này.
Cách tính điểm — phần dễ sai nhất
Điểm SUS không phải là trung bình cộng đơn giản. Quy trình đúng gồm ba bước:
Bước 1 — Chuẩn hoá mỗi câu về thang 0–4:
- Với câu lẻ (tích cực): điểm đóng góp = (giá trị người dùng chọn) − 1.
- Với câu chẵn (tiêu cực): điểm đóng góp = 5 − (giá trị người dùng chọn).
Bước 3 — Nhân tổng đó với 2,5 để quy về thang 0–100.
Một lưu ý cực kỳ quan trọng: điểm SUS không phải là phần trăm. Một điểm 72 không có nghĩa là "72% người dùng hài lòng" hay "sản phẩm tốt 72%". Nó chỉ là một con số trên thang quy ước, và chỉ có ý nghĩa khi đem so sánh.
Diễn giải con số: 70 là tốt hay tệ?
Đây là nơi nghiên cứu của Jeff Sauro và Aaron Bangor giúp chúng ta rất nhiều. Qua việc phân tích hàng nghìn khảo sát SUS, họ đưa ra các mốc tham chiếu:
- Điểm trung bình toàn cầu ≈ 68. Đây là đường ranh quan trọng nhất. Nếu sản phẩm của bạn đạt 68, nghĩa là nó trung bình — không hơn không kém phần lớn sản phẩm ngoài kia.
- Trên 68: trên mức trung bình.
- Khoảng 80,3 trở lên: rất tốt — đây là ngưỡng mà người dùng có xu hướng giới thiệu sản phẩm cho người khác.
- Dưới 51: đáng báo động, usability có vấn đề nghiêm trọng.
Tình huống thực tế
Ví dụ 1 — So sánh hai phiên bản app đặt vé xe khách (bối cảnh Việt Nam)
Một startup ở TP.HCM làm app đặt vé xe khách liên tỉnh (giả định tên VeXe24). Phiên bản hiện tại có luồng thanh toán rườm rà, nhiều người dùng kêu khó. Đội ngũ thiết kế lại luồng đặt vé và muốn chứng minh bằng số liệu rằng bản mới tốt hơn.
Họ chạy SUS hai lần: 12 người dùng thử bản cũ, 12 người khác thử bản mới (cùng tệp người dùng — dân văn phòng hay về quê dịp lễ). Kết quả: bản cũ đạt SUS = 58,5, bản mới đạt SUS = 76,0.
Diễn giải: Bản cũ (58,5) nằm dưới mức trung bình 68 — đúng như phản ánh "khó dùng". Bản mới (76,0) vượt qua mốc trung bình một quãng đáng kể, rơi vào hạng "Good". Mức tăng 17,5 điểm là rất lớn (trong thực tế, một cải tiến đáng kể thường tạo chênh lệch 5–10 điểm).
Bài học rút ra: Sức mạnh thật của SUS nằm ở so sánh trước–sau. Một con số 76 đứng một mình không nói được nhiều, nhưng "tăng từ 58,5 lên 76,0" là bằng chứng định lượng thuyết phục để bảo vệ ngân sách thiết kế lại trước ban giám đốc.
Ví dụ 2 — Khi điểm SUS cao nhưng người dùng vẫn rời bỏ (sản phẩm SaaS)
Một công ty phần mềm quản lý nhà hàng tại Hà Nội (giả định QuánMềm) đo SUS cho dashboard của họ và rất phấn khởi: SUS = 82, hạng A. Nhưng tỷ lệ khách hàng huỷ gói (churn) vẫn cao, nhiều chủ quán dùng vài tuần rồi bỏ.
Khi đào sâu, đội nghiên cứu phát hiện vấn đề: họ chỉ đo SUS với những người dùng đã quen hệ thống và còn ở lại — tức nhóm vốn đã thích sản phẩm. Những người gặp khó và bỏ đi từ tuần đầu chưa bao giờ được khảo sát. Đây là một dạng survivorship bias.
Diễn giải: Điểm SUS đo cảm nhận về tính dễ dùng, nó không đo giá trị kinh doanh, không đo lý do người dùng rời bỏ, cũng không đo vấn đề onboarding của người mới. Một sản phẩm có thể dễ dùng với người ở lại nhưng vẫn thất bại vì giá, vì thiếu tính năng cốt lõi, hoặc vì onboarding quá dốc.
Bài học rút ra: SUS chỉ đáng tin khi mẫu khảo sát đại diện cho đúng nhóm bạn quan tâm — đặc biệt phải bao gồm cả người dùng mới và người gặp khó. Và đừng bao giờ dùng SUS một mình để kết luận về sức khoẻ sản phẩm; nó là một mảnh ghép, không phải bức tranh toàn cảnh.
Ví dụ 3 — SUS trong usability test có điều phối (moderated)
Một nhóm researcher kiểm thử website thương mại điện tử mỹ phẩm. Họ mời 6 người dùng vào phòng lab, mỗi người thực hiện 5 tác vụ (tìm sản phẩm, thêm giỏ hàng, áp mã giảm giá, thanh toán, theo dõi đơn). Ngay sau khi hoàn thành tác vụ và trước khi rời đi, mỗi người điền bảng SUS trên giấy.
Kết quả trung bình SUS = 64, kèm theo những quan sát định tính: 4/6 người chật vật ở bước áp mã giảm giá.
Diễn giải: SUS (định lượng) cho biết "tổng thể hơi dưới trung bình"; quan sát định tính cho biết "vì sao" — nút áp mã bị khuất, gây bối rối. Hai loại dữ liệu bổ trợ nhau hoàn hảo: con số để báo cáo và theo dõi xu hướng, quan sát để biết phải sửa cái gì.
Bài học rút ra: Thời điểm vàng để thu SUS là ngay sau khi người dùng vừa trải nghiệm sản phẩm, khi ấn tượng còn tươi mới. Kết hợp SUS với quan sát định tính trong cùng một buổi test cho bạn cả "what" lẫn "why" mà gần như không tốn thêm chi phí.
Hướng dẫn từng bước
Bước 1 — Xác định bạn đo cái gì và với ai. Chọn rõ sản phẩm/luồng cần đo và nhóm người dùng đại diện. SUS đáng tin nhất khi áp cho cùng một đối tượng qua các lần đo. Về cỡ mẫu: SUS đã có thể cho ước lượng tương đối từ 5–8 người trong test định tính, nhưng nếu muốn benchmark hay so sánh có ý nghĩa thống kê, hãy hướng tới ít nhất 15–20 người mỗi nhóm trở lên.
Bước 2 — Cho người dùng trải nghiệm trước, khảo sát sau. Đừng đưa bảng SUS khi họ chưa dùng sản phẩm. Hãy để họ thực hiện các tác vụ thực tế trước, rồi mới khảo sát ngay sau đó.
Bước 3 — Trình bày đúng 10 câu, đúng thứ tự, đúng thang 1–5. Giữ nguyên cấu trúc xen kẽ tích cực/tiêu cực. Nếu phải dịch sang tiếng Việt, hãy dịch cẩn thận sao cho sắc thái "đồng ý/không đồng ý" rõ ràng và tự nhiên, rồi kiểm tra lại với vài người để đảm bảo không ai hiểu nhầm.
Bước 4 — Khuyến khích trả lời ngay theo trực giác. Hướng dẫn người dùng: nếu phân vân ở câu nào, cứ chọn điểm giữa (3) thay vì bỏ trống — bỏ trống sẽ làm hỏng cách tính điểm.
Bước 5 — Tính điểm cho từng người theo công thức 3 bước. Với câu lẻ lấy (giá trị − 1); câu chẵn lấy (5 − giá trị); cộng lại; nhân 2,5. Bạn sẽ ra một điểm 0–100 cho mỗi người.
Bước 6 — Lấy trung bình cộng điểm của tất cả người dùng. Đây mới là điểm SUS của sản phẩm. Nên báo cáo kèm độ phân tán (ví dụ khoảng dao động hoặc độ lệch chuẩn) để biết các ý kiến có đồng thuận hay phân cực.
Bước 7 — Diễn giải và đặt vào bối cảnh. So với mốc 68, so với lần đo trước, so với đối thủ nếu có. Gắn thêm grade/adjective để báo cáo dễ hiểu, và luôn kèm phát hiện định tính để giải thích "vì sao".
Lỗi thường gặp & mẹo
Lỗi 1 — Tính điểm như trung bình cộng thô. Đây là lỗi phổ biến nhất. Nếu bạn quên đảo chiều câu tiêu cực, điểm sẽ sai hoàn toàn và thường ra một con số vô nghĩa quanh 50. Luôn nhớ: câu lẻ lấy (x−1), câu chẵn lấy (5−x).
Lỗi 2 — Hiểu SUS là phần trăm. SUS 80 không phải "80% hài lòng". Nó là điểm trên thang quy ước; chỉ có ý nghĩa khi so sánh. Nói "80, hạng A, trên mức trung bình ngành" thay vì "80%".
Lỗi 3 — Sửa lời các câu hỏi. Khoảnh khắc bạn đổi nội dung câu, bạn mất luôn khả năng so sánh với benchmark toàn cầu — vì đó không còn là SUS chuẩn nữa. Chỉ được thay từ "system" bằng tên sản phẩm.
Lỗi 4 — Mẫu thiên lệch. Như ví dụ QuánMềm: chỉ đo người dùng trung thành sẽ cho điểm cao giả tạo. Hãy đảm bảo mẫu bao gồm cả người mới và người gặp khó.
Lỗi 5 — Dùng SUS để chẩn đoán lỗi cụ thể. SUS chỉ cho một con số tổng thể, nó không nói được nút nào khó bấm, màn hình nào gây bối rối. Đừng kỳ vọng nó thay thế quan sát định tính.
Mẹo: Hãy lập một bảng tính (spreadsheet) sẵn công thức để nhập điểm thô và tự ra điểm SUS — tránh sai sót thủ công. Mẹo nữa: lưu lại điểm SUS qua từng quý để dựng đường xu hướng usability theo thời gian; đây là dữ liệu rất giá trị khi báo cáo với lãnh đạo. Cuối cùng, vì SUS có một câu thứ 8 chuyên đo từ "rườm rà", nếu nghi ngờ ai trả lời ẩu, hãy đối chiếu các cặp câu mâu thuẫn (ví dụ ai đó vừa nói "rất dễ dùng" ở câu 3 vừa nói "cần học rất nhiều" ở câu 10).
Bài tập thực hành
Bài 1 — Tính tay một bảng SUS. Một người dùng trả lời 10 câu lần lượt như sau: 4, 2, 5, 1, 4, 2, 5, 2, 4, 1. Hãy tính điểm SUS của người này theo đúng 3 bước. (Gợi ý đáp án: tổng đã chuẩn hoá = 3+3+4+4+3+3+4+3+3+4 = 34; nhân 2,5 → 85, hạng A.)
Bài 2 — Chạy một mini-study. Chọn một app bạn dùng hằng ngày (Grab, Shopee, MoMo, hay app ngân hàng của bạn). Mời 3–5 người quen thực hiện một tác vụ thực tế trên app đó, rồi cho họ điền bảng SUS ngay sau đó. Tính điểm trung bình và đặt cạnh mốc 68. Sản phẩm đó trên hay dưới trung bình?
Bài 3 — Diễn giải và phản biện. Giả sử bạn đo được SUS = 71 cho một sản phẩm, nhưng chỉ khảo sát 4 người dùng đều là đồng nghiệp trong công ty. Hãy viết 4–5 câu nêu vì sao con số này chưa đáng tin, và bạn sẽ điều chỉnh thiết kế nghiên cứu thế nào để kết quả đáng tin hơn.
Bài 4 — Kết hợp định tính. Lấy lại mini-study ở Bài 2, ghi chú thêm những điểm người dùng tỏ ra lúng túng trong lúc làm tác vụ. Viết một đoạn báo cáo ngắn gắn điểm SUS (con số) với 2–3 quan sát định tính (lý do) — đúng tinh thần "what + why".
Tóm tắt
- SUS là bộ 10 câu Likert đo cảm nhận tổng thể về tính dễ sử dụng, cho ra một điểm 0–100 đã được chuẩn hoá và có thể so sánh giữa các sản phẩm và qua thời gian.
- Đặc trưng thông minh là xen kẽ câu tích cực (lẻ) và tiêu cực (chẵn) để chống trả lời ẩu.
- Cách tính: câu lẻ lấy (giá trị − 1), câu chẵn lấy (5 − giá trị), cộng lại rồi nhân 2,5. Đây không phải phần trăm.
- Mốc diễn giải then chốt: 68 = trung bình; trên 68 là trên trung bình; khoảng 80,3 trở lên là rất tốt.
- Sức mạnh thật của SUS là so sánh — trước/sau, đối thủ, theo quý — chứ không phải một con số đứng một mình.
- Cạm bẫy lớn nhất: tính điểm sai (quên đảo chiều câu tiêu cực), mẫu thiên lệch, và kỳ vọng SUS chẩn đoán lỗi cụ thể. Hãy luôn kết hợp SUS (what) với quan sát định tính (why).