Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành một cuộc usability test cho tính năng thanh toán mới của một ứng dụng ví điện tử. Sếp hỏi: "Vậy trải nghiệm mới có tốt hơn cái cũ không?" Bạn trả lời: "Dạ em thấy người dùng có vẻ mượt hơn ạ." Sếp cau mày: "Có vẻ" là bao nhiêu? Tốt hơn 5% hay 30%? So với sản phẩm của đối thủ thì sao?
Đây chính là khoảnh khắc mà nhiều UX researcher mới vào nghề bị "đứng hình". Cảm nhận định tính rất giá trị, nhưng khi ngồi vào bàn họp với ban lãnh đạo, product manager hay nhà đầu tư, bạn cần một con số. Một con số đủ đơn giản để ai cũng hiểu, đủ chuẩn hóa để so sánh được giữa các phiên bản, và đủ rẻ để đo đi đo lại nhiều lần.
SUS — System Usability Scale — chính là công cụ đó. Chỉ với 10 câu hỏi, mất khoảng 2 phút để người dùng trả lời, bạn thu được một điểm số từ 0 đến 100 phản ánh mức độ dễ dùng của sản phẩm. Đây là thước đo usability được sử dụng nhiều nhất trên thế giới, có mặt trong hàng chục nghìn nghiên cứu, và quan trọng nhất: nó miễn phí, thuộc phạm vi công cộng (public domain). Bạn không cần trả một đồng bản quyền nào để dùng SUS trong dự án của mình.
Trong bài này, chúng ta sẽ mổ xẻ SUS đến từng chi tiết: nó ra đời thế nào, 10 câu hỏi là gì, tại sao chúng lại đan xen tích cực và tiêu cực, cách tính điểm chuẩn xác, và cách diễn giải con số bạn thu được. Đây là một trong những kỹ năng nền tảng nhất mà bất kỳ người làm UX metrics nào cũng phải nắm vững.
Khái niệm cốt lõi
SUS là gì và ra đời như thế nào
SUS được John Brooke tạo ra vào năm 1986, khi ông làm việc tại Digital Equipment Corporation (DEC) — một trong những gã khổng lồ máy tính thời bấy giờ. Bối cảnh ra đời rất thực tế: nhóm của Brooke cần một cách nhanh, rẻ và đáng tin cậy để đánh giá cảm nhận về mức độ dễ dùng của các hệ thống văn phòng điện tử mà họ đang phát triển. Các phương pháp đo lường usability lúc đó thường phức tạp và tốn thời gian, nên ông thiết kế một bảng câu hỏi ngắn gọn mà chính ông gọi là "quick and dirty" — nhanh và thô nhưng hiệu quả đến bất ngờ.
Điều thú vị là Brooke đã đưa SUS vào phạm vi công cộng. Bất kỳ ai cũng được tự do sử dụng, chỉ cần ghi nhận nguồn gốc. Chính sự cởi mở này đã giúp SUS lan rộng và trở thành một tiêu chuẩn de facto trong ngành. Sau gần 40 năm, nó vẫn được tin dùng vì tính đơn giản và độ tin cậy đã được kiểm chứng qua vô số nghiên cứu.
10 câu hỏi (statements)
SUS gồm 10 phát biểu (statement), người dùng đánh giá mức độ đồng ý trên thang Likert 5 mức: 1 = Hoàn toàn không đồng ý → 5 = Hoàn toàn đồng ý. Đây là 10 câu gốc (kèm bản dịch tham khảo sang tiếng Việt):
- Tôi nghĩ mình sẽ muốn sử dụng hệ thống này thường xuyên. (tích cực)
- Tôi thấy hệ thống này phức tạp một cách không cần thiết. (tiêu cực)
- Tôi thấy hệ thống này dễ sử dụng. (tích cực)
- Tôi nghĩ mình sẽ cần sự hỗ trợ của một người kỹ thuật để có thể dùng được hệ thống này. (tiêu cực)
- Tôi thấy các chức năng trong hệ thống này được tích hợp gắn kết tốt với nhau. (tích cực)
- Tôi thấy hệ thống này có quá nhiều sự thiếu nhất quán. (tiêu cực)
- Tôi hình dung hầu hết mọi người sẽ học cách dùng hệ thống này rất nhanh. (tích cực)
- Tôi thấy hệ thống này rất cồng kềnh, khó thao tác. (tiêu cực)
- Tôi cảm thấy rất tự tin khi sử dụng hệ thống này. (tích cực)
- 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. (tiêu cực)
Vì sao câu hỏi lại đan xen tích cực và tiêu cực
Bạn để ý các câu lẻ (1, 3, 5, 7, 9) đều mang tính tích cực, còn các câu chẵn (2, 4, 6, 8, 10) mang tính tiêu cực. Đây không phải ngẫu nhiên. Đây là một thiết kế có chủ đích nhằm chống lại hiện tượng acquiescence bias (thiên kiến đồng thuận) và extreme response bias (thiên kiến trả lời cực đoan).
Khi tất cả câu hỏi đều tích cực, nhiều người có xu hướng bấm "đồng ý" một cách máy móc mà không thật sự đọc kỹ — kiểu trả lời cho xong. Bằng cách đảo chiều xen kẽ, SUS buộc người trả lời phải đọc và suy nghĩ từng câu: nếu họ thích sản phẩm, họ phải bấm điểm cao ở câu lẻ nhưng điểm thấp ở câu chẵn. Sự "đổi chiều" liên tục này giúp lọc ra những phản hồi thiếu tập trung và làm dữ liệu đáng tin cậy hơn.
Đánh đổi là công thức tính điểm phức tạp hơn một chút — nhưng đừng lo, chúng ta sẽ đi qua từng bước ở phần dưới.
Cách tính điểm SUS
Đây là phần mà người mới hay tính sai nhất. Điểm SUS không phải là trung bình cộng đơn giản của 10 câu. Quy trình như sau:
- Câu lẻ (tích cực): lấy điểm người dùng chọn trừ đi 1. Ví dụ chọn 5 → 5 − 1 = 4.
- Câu chẵn (tiêu cực): lấy 5 trừ đi điểm người dùng chọn. Ví dụ chọn 2 → 5 − 2 = 3.
- Sau khi quy đổi, mỗi câu cho ra một giá trị từ 0 đến 4. Cộng tất cả 10 câu lại, được tổng từ 0 đến 40.
- Nhân tổng đó với 2.5 để quy về thang 0–100.
Diễn giải điểm số: các mốc benchmark
Dựa trên nghiên cứu quy mô lớn của Jeff Sauro và các cộng sự (phân tích hàng trăm nghiên cứu), điểm trung bình toàn ngành vào khoảng 68. Đây là mốc vàng để ghi nhớ:
- Dưới 68: sản phẩm của bạn có usability dưới trung bình — cần cải thiện.
- Bằng 68: đúng mức trung bình, tương đương percentile thứ 50.
- 80.3 trở lên: nằm ở top khoảng 10% — người dùng nhiều khả năng sẽ giới thiệu sản phẩm cho người khác.
- ≥ 80.3: A — "Excellent" (Xuất sắc)
- 68–80.3: B/C — "Good" (Tốt)
- ~68: D — "OK" (Chấp nhận được)
- Dưới ~51: F — "Poor / Awful" (Kém)
Tình huống thực tế
Ví dụ 1: Ví điện tử "MoMoPay giả định" so sánh hai luồng thanh toán
Một đội UX tại một công ty fintech Việt Nam (gọi là VíXanh) vừa thiết kế lại luồng thanh toán QR. Họ muốn biết bản mới có thực sự dễ dùng hơn bản cũ hay không. Thay vì chỉ dựa vào cảm nhận, họ tổ chức test với 24 người dùng, chia đôi: 12 người dùng bản cũ, 12 người dùng bản mới. Sau mỗi phiên, mỗi người điền bảng SUS.
Kết quả: bản cũ đạt SUS trung bình 61, bản mới đạt 77. Con số này lập tức trở nên "biết nói": bản cũ nằm dưới mức trung bình ngành (68, hạng D), còn bản mới vọt lên hạng B (Good). Chênh lệch 16 điểm là một bước nhảy đáng kể.
Bài học rút ra: SUS biến một câu hỏi mơ hồ ("có tốt hơn không?") thành một quyết định dựa trên dữ liệu. Đội VíXanh mang con số này lên họp và được duyệt ngân sách để triển khai bản mới trên toàn hệ thống. Không có con số, cuộc tranh luận có thể đã kéo dài hàng tuần dựa trên ý kiến cá nhân.
Ví dụ 2: Sàn thương mại điện tử đo SUS định kỳ để theo dõi theo thời gian
Một sàn TMĐT khu vực Đông Nam Á (giả định tên ShopSea) tích hợp một micro-survey SUS hiện lên với 3% người dùng ngẫu nhiên sau khi hoàn tất đơn hàng. Mỗi quý họ thu được vài nghìn phản hồi và vẽ đường xu hướng điểm SUS.
Quý 1 điểm là 70. Sau khi tung ra một trang giỏ hàng "được tối ưu" ở quý 2, điểm bất ngờ rớt xuống 64. Nhóm hoảng hốt xem session replay và phát hiện trang mới thêm quá nhiều bước upsell (mời mua thêm), khiến người dùng thấy "cồng kềnh" — đúng như câu số 8 trong SUS. Họ gỡ bớt bước upsell, và quý 3 điểm hồi phục lên 72.
Bài học rút ra: SUS đặc biệt mạnh khi được đo lặp lại theo thời gian (longitudinal). Một điểm số đơn lẻ nói lên hiện trạng; một chuỗi điểm số nói lên xu hướng và cảnh báo sớm khi một thay đổi vô tình làm hỏng trải nghiệm.
Ví dụ 3: Startup B2B dịch SUS sang tiếng Việt và mắc lỗi cỡ mẫu
Một startup phần mềm quản lý kho ở TP.HCM muốn đo usability của dashboard mới. Họ dịch 10 câu SUS sang tiếng Việt và chỉ test với 4 người trong nội bộ công ty. Điểm trung bình ra 82 — rất cao — nên họ tự tin ra mắt. Ba tháng sau, tỷ lệ khách hàng bỏ dùng cao bất thường.
Vấn đề nằm ở hai chỗ. Thứ nhất, cỡ mẫu 4 người quá nhỏ, lại toàn nhân viên nội bộ vốn đã quen sản phẩm — họ không đại diện cho khách hàng thật. Thứ hai, bản dịch câu số 5 ("tích hợp gắn kết") bị dịch tối nghĩa khiến người trả lời hiểu lệch. Khi họ làm lại với 18 khách hàng thật và bản dịch được kiểm định, điểm thực tế chỉ còn 58.
Bài học rút ra: SUS đơn giản nhưng không "miễn nhiễm" với sai lầm phương pháp. Cỡ mẫu, tính đại diện của người tham gia, và chất lượng bản dịch quyết định con số bạn nhận được có đáng tin hay không.
Hướng dẫn từng bước
Bước 1 — Xác định thời điểm khảo sát. SUS nên được điền ngay sau khi người dùng đã hoàn thành một hoặc vài tác vụ với sản phẩm, khi trải nghiệm còn nóng hổi. Đừng hỏi trước khi họ dùng thử, và đừng để quá lâu sau đó.
Bước 2 — Trình bày đúng thang đo. Dùng thang Likert 5 mức từ "Hoàn toàn không đồng ý" (1) đến "Hoàn toàn đồng ý" (5). Giữ nguyên thứ tự và cách diễn đạt 10 câu — đừng tự ý bỏ bớt hay đảo lộn, vì cấu trúc đan xen tích cực/tiêu cực chính là điểm cốt lõi.
Bước 3 — Thu thập phản hồi từ đủ số người. Với mục đích so sánh hay báo cáo có ý nghĩa thống kê, hãy nhắm tối thiểu 12–15 người mỗi nhóm; nhiều hơn thì càng ổn định. Đảm bảo người tham gia đại diện cho người dùng thật, không phải đồng nghiệp trong team.
Bước 4 — Quy đổi điểm từng câu. Với câu lẻ: (điểm chọn − 1). Với câu chẵn: (5 − điểm chọn). Mỗi câu ra giá trị 0–4.
Bước 5 — Tính điểm cho từng người. Cộng 10 giá trị đã quy đổi (được tổng 0–40), rồi nhân 2.5. Đó là điểm SUS của một người, thang 0–100.
Bước 6 — Tính điểm trung bình. Lấy trung bình cộng điểm SUS của tất cả người tham gia. Đây mới là con số bạn báo cáo. Nên kèm theo cả độ lệch chuẩn hoặc khoảng tin cậy để thể hiện mức độ dao động.
Bước 7 — Diễn giải bằng benchmark. So sánh với mốc 68 (trung bình ngành), gán grade letter và adjective rating. Nếu có điểm của phiên bản cũ hoặc của đối thủ, hãy đặt cạnh nhau để câu chuyện thêm sức nặng.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi điểm SUS là phần trăm. SUS 80 không phải "80% hài lòng". Nó là điểm trên thang riêng, phải diễn giải bằng percentile và benchmark. Nói "SUS 80, tương đương hạng A, top 10% ngành" thì đúng; nói "80% người dùng thấy dễ dùng" thì sai.
Lỗi 2 — Quên đảo điểm câu tiêu cực. Đây là lỗi tính toán phổ biến nhất. Nếu bạn cộng thẳng điểm thô cả 10 câu, kết quả sẽ vô nghĩa. Luôn nhớ: câu lẻ trừ 1, câu chẵn lấy 5 trừ.
Lỗi 3 — Sửa lời câu hỏi. Nhiều bạn thấy câu chữ hơi cứng nên tự viết lại cho "mượt". Việc này phá vỡ tính chuẩn hóa và khiến điểm không còn so sánh được với benchmark. Nếu buộc phải điều chỉnh (ví dụ đổi "hệ thống" thành "ứng dụng" cho phù hợp ngữ cảnh), hãy giữ nguyên cấu trúc và ý nghĩa.
Lỗi 4 — Cỡ mẫu quá nhỏ. Test 3–5 người là đủ để tìm lỗi usability định tính, nhưng để có một con số SUS đáng tin thì cần nhiều hơn. Con số từ 4 người có sai số rất lớn.
Lỗi 5 — Dịch ẩu. Với người dùng Việt Nam, bản dịch phải tự nhiên và chính xác về sắc thái. Nên back-translate (dịch ngược lại tiếng Anh để kiểm tra) và test thử vài người xem họ có hiểu đúng không.
Mẹo: SUS đo cảm nhận tổng thể (perceived usability), không cho bạn biết tại sao sản phẩm khó dùng. Hãy luôn ghép SUS với dữ liệu định tính — một câu hỏi mở "Điều gì khiến bạn khó chịu nhất?" ngay sau bảng SUS sẽ giúp bạn hiểu con số đến từ đâu.
Mẹo: SUS đo usability, không đo mức độ khách hàng sẵn sàng giới thiệu sản phẩm hay mức hài lòng nói chung — đó là địa hạt của các chỉ số khác mà bạn sẽ học ở các bài sau. Đừng dùng SUS thay thế cho chúng.
Bài tập thực hành
Bài 1 — Tính điểm bằng tay. Một người dùng trả lời 10 câu SUS lần lượt như sau: 4, 2, 5, 1, 4, 2, 5, 1, 4, 2. Hãy quy đổi từng câu (nhớ: câu lẻ trừ 1, câu chẵn lấy 5 trừ), cộng lại và nhân 2.5. Bạn ra bao nhiêu? (Gợi ý đáp án: các giá trị quy đổi lần lượt là 3, 3, 4, 4, 3, 3, 4, 4, 3, 3; tổng 34; × 2.5 = 85, hạng A.)
Bài 2 — Diễn giải. Nhóm bạn đo được SUS trung bình 64 cho ứng dụng đặt đồ ăn. Hãy viết 3 câu báo cáo cho sếp: (a) con số này so với trung bình ngành thế nào, (b) tương đương grade và adjective rating gì, (c) đề xuất bước tiếp theo.
Bài 3 — Thiết kế khảo sát thật. Chọn một app bạn hay dùng (ví dụ một ví điện tử hoặc sàn TMĐT Việt Nam). Viết lại 10 câu SUS bằng tiếng Việt phù hợp với ngữ cảnh app đó, rồi nhờ ít nhất 5 người thật điền. Tính điểm trung bình và độ lệch. Ghi lại: bạn có gặp câu nào người dùng thấy khó hiểu không, và bạn đã điều chỉnh ra sao mà vẫn giữ chuẩn.
Tóm tắt
SUS — System Usability Scale — do John Brooke tạo ra năm 1986 tại Digital Equipment Corporation, là thước đo cảm nhận usability phổ biến nhất thế giới, miễn phí và thuộc phạm vi công cộng. Nó gồm 10 phát biểu trên thang Likert 5 mức, đan xen câu tích cực (lẻ) và tiêu cực (chẵn) một cách có chủ đích để chống thiên kiến trả lời máy móc.
Cách tính: câu lẻ lấy điểm trừ 1, câu chẵn lấy 5 trừ điểm, cộng 10 giá trị (0–40) rồi nhân 2.5 để ra thang 0–100. Nhớ rằng đây không phải phần trăm. Mốc trung bình ngành là 68; từ 80.3 trở lên là xuất sắc (hạng A). SUS mạnh nhất khi dùng để so sánh phiên bản, so với đối thủ, và theo dõi xu hướng theo thời gian.
Những cạm bẫy cần tránh: coi điểm là phần trăm, quên đảo điểm câu tiêu cực, tự sửa lời câu hỏi, cỡ mẫu quá nhỏ, và dịch ẩu. Cuối cùng, hãy luôn nhớ SUS cho bạn con số "dễ dùng đến mức nào" chứ không cho bạn biết "tại sao" — nên hãy ghép nó với dữ liệu định tính để có bức tranh trọn vẹn.