Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Quantitative UX Methods

UX Metrics and Analytics Bài 2/60

Mở đầu — vì sao bài này quan trọng

Nếu bạn đã từng ngồi trong một buổi họp và nói với sếp rằng "trải nghiệm sản phẩm của chúng ta khá tốt", rồi bị hỏi lại "tốt là tốt thế nào? Có con số nào không?", bạn sẽ hiểu ngay tại sao bài học này quan trọng. Trong thế giới UX, cảm giác chủ quan là điểm khởi đầu, nhưng nó không thể là điểm kết thúc. Khi bạn muốn thuyết phục ban lãnh đạo đầu tư vào thiết kế lại một luồng đăng ký, hay khi bạn cần chứng minh rằng phiên bản mới thực sự tốt hơn phiên bản cũ, bạn cần những con số.

Đó chính là địa hạt của Quantitative UX — phương pháp đo lường trải nghiệm người dùng bằng dữ liệu định lượng. Ở bài trước, chúng ta đã dựng lên khung tư duy tổng thể về UX Metrics. Trong bài này, chúng ta đi sâu vào một trong những công cụ định lượng kinh điển, dễ áp dụng và được tin dùng nhất trong ngành suốt hơn ba thập kỷ qua: System Usability Scale (SUS).

Vì sao lại chọn SUS để mở màn cho các phương pháp định lượng? Bởi vì SUS là ví dụ hoàn hảo cho triết lý cốt lõi của quantitative UX: biến một khái niệm mơ hồ ("sản phẩm này có dễ dùng không?") thành một con số duy nhất, có thể so sánh, có thể theo dõi theo thời gian, và quan trọng nhất là có chuẩn tham chiếu để biết con số đó là tốt hay xấu. Bạn không cần một đội ngũ data scientist, không cần công cụ đắt tiền, chỉ cần 10 câu hỏi và một chút số học là đã có thể bắt đầu.

Khái niệm cốt lõi

Quantitative UX là gì và khác gì với việc "cảm nhận"

Quantitative UX (UX định lượng) là cách tiếp cận thu thập và phân tích dữ liệu số để hiểu và đánh giá trải nghiệm người dùng. Câu hỏi mà nó trả lời không phải là "tại sao người dùng gặp khó khăn" (đó là địa hạt của định tính), mà là "bao nhiêu người gặp khó khăn", "mức độ dễ dùng là bao nhiêu", "phiên bản A hay B tốt hơn bao nhiêu phần trăm".

Sức mạnh của định lượng nằm ở ba đặc tính:

  • So sánh được (comparable): một con số cho phép bạn so sánh giữa các phiên bản, giữa các đối thủ, giữa các nhóm người dùng.
  • Theo dõi được (trackable): bạn đo hôm nay, đo lại sau 3 tháng, và thấy được xu hướng đi lên hay đi xuống.
  • Truyền đạt được (communicable): một con số 82 điểm dễ đưa vào slide và dễ thuyết phục hơn là một đoạn mô tả dài dòng.

System Usability Scale (SUS): bảng câu hỏi 10 mục kinh điển

SUS được John Brooke phát triển năm 1986 tại công ty Digital Equipment Corporation. Điều thú vị là chính Brooke gọi nó là một "quick and dirty" scale — một thang đo nhanh và thô — vậy mà nó đã trở thành tiêu chuẩn de facto của ngành, được trích dẫn trong hàng nghìn nghiên cứu và dùng bởi hầu hết các đội UX chuyên nghiệp.

SUS gồm đúng 10 câu hỏi (statement), người dùng trả lời trên thang Likert 5 mức từ 1 (Hoàn toàn không đồng ý) đến 5 (Hoàn toàn đồng ý). Điểm đặc biệt trong thiết kế của SUS là các câu hỏi xen kẽ chiều tích cực và tiêu cực: câu lẻ (1, 3, 5, 7, 9) diễn đạt theo hướng tích cực, câu chẵn (2, 4, 6, 8, 10) diễn đạt theo hướng tiêu cực. Sự xen kẽ này buộc người trả lời phải đọc kỹ từng câu thay vì máy móc tích cùng một cột — giảm hiện tượng "acquiescence bias" (xu hướng gật đầu đồng ý cho xong).

Mười câu hỏi gốc (đã Việt hóa để bạn dễ hình dung, khi triển khai thật nên giữ bản chuẩn hóa):

  • Tôi nghĩ tôi 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ĩ tôi cần sự trợ giúp của người có chuyên môn để 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 tốt với nhau. (tích cực)
  • Tôi thấy hệ thống này có quá nhiều điểm 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 khó dùng/rườm rà. (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)

Cách tính điểm SUS

Đây là phần khiến nhiều người lúng túng lần đầu, nhưng thực ra chỉ gồm ba bước số học:

Bước 1 — Chuẩn hóa từng câu về thang 0–4:

  • Với câu lẻ (tích cực): điểm đóng góp = (điểm người dùng chọn) − 1.
  • Với câu chẵn (tiêu cực): điểm đóng góp = 5 − (điểm người dùng chọn).
Logic ở đây rất tinh tế: sau bước này, mọi câu đều được quy về cùng một chiều — càng cao càng tốt. Với câu tích cực, chọn 5 (rất đồng ý) sẽ cho 5−1 = 4 điểm. Với câu tiêu cực, chọn 1 (rất không đồng ý — tức là người dùng phản đối điều xấu, một tín hiệu tốt) sẽ cho 5−1 = 4 điểm. Cả hai đều quy về mức tối đa 4.

Bước 2 — Cộng tổng: cộng 10 giá trị đã chuẩn hóa lại, được một số từ 0 đến 40.

Bước 3 — Nhân với 2.5: để đưa về thang 0–100.

Công thức tổng quát: SUS = (tổng điểm đóng góp của 10 câu) × 2.5.

Một lưu ý cực kỳ quan trọng: điểm SUS 100 KHÔNG phải là 100%, và một con số như 68 không có nghĩa là "68% người hài lòng". SUS chỉ là một điểm số trên thang 0–100, và nó cần được diễn giải dựa trên chuẩn tham chiếu (benchmark) của ngành.

Diễn giải điểm số: con số của bạn tốt hay xấu?

Đây là lý do SUS mạnh hơn nhiều thang đo tự chế. Qua phân tích hàng trăm nghiên cứu (đáng chú ý là công trình của Jeff Sauro và Aaron Bangor), ngành đã có các mốc chuẩn:

  • Điểm trung bình toàn ngành ≈ 68. Nếu sản phẩm của bạn đạt đúng 68, nghĩa là bạn ở mức trung bình, tương đương phân vị 50.
  • Trên 68: trên trung bình. Trên 80.3: thuộc nhóm dẫn đầu (top ~10%), đây là ngưỡng mà người dùng thường sẵn lòng giới thiệu sản phẩm cho người khác.
  • Dưới 51: dưới trung bình rõ rệt, có vấn đề usability nghiêm trọng cần ưu tiên xử lý.
Bangor và cộng sự còn gắn thêm thang xếp loại chữ cái (grade)tính từ mô tả (adjective) để dễ truyền đạt với stakeholder không chuyên: khoảng 85–100 là "Excellent" (A), 72–85 là "Good" (B), 68–72 là "OK/Fair" (C), dưới đó rơi vào "Poor" và "Awful". Nhờ vậy, khi báo cáo bạn có thể nói "sản phẩm đạt SUS 74 — mức Good, hạng B", thay vì để lãnh đạo tự đoán 74 là cao hay thấp.

Tình huống thực tế

Ví dụ 1 — Ví điện tử "MoMoPay" (giả định) đo lại sau khi redesign luồng chuyển tiền

Một đội UX của ví điện tử (bối cảnh giả định dựa trên các ví phổ biến ở Việt Nam) nhận nhiều phàn nàn rằng luồng chuyển tiền "rối". Trước khi thiết kế lại, họ mời 24 người dùng thực hiện task chuyển tiền rồi điền bảng SUS. Kết quả trung bình: SUS = 61 — dưới ngưỡng trung bình 68, xếp hạng D, tính từ "OK" nghiêng về "Poor".

Sau khi redesign (gộp bước xác nhận, thêm gợi ý người nhận gần đây), họ lặp lại đo với 26 người dùng khác: SUS = 79. Vượt qua ngưỡng "Good", chỉ còn cách top 10% một chút.

Diễn giải: Chênh lệch 18 điểm là rất đáng kể trên thang SUS (thông thường chênh 5–10 điểm đã là cải thiện có ý nghĩa). Con số này cho phép đội UX bước vào phòng họp và nói: "Bản redesign đưa usability từ hạng D lên hạng B". Đó là ngôn ngữ mà CFO cũng hiểu được.

Bài học rút ra: Sức mạnh thật sự của SUS không nằm ở một con số đơn lẻ, mà ở việc đo trước — đo sau (pre/post) để chứng minh tác động của thay đổi thiết kế.

Ví dụ 2 — Sàn thương mại điện tử Đông Nam Á so sánh app với đối thủ

Một sàn TMĐT khu vực Đông Nam Á (bối cảnh giả định) muốn biết app của mình đứng ở đâu so với hai đối thủ. Họ thuê một agency chạy unmoderated test: mỗi người dùng dùng thử một app, hoàn thành task tìm và thêm sản phẩm vào giỏ, rồi điền SUS.

Kết quả: App của họ 72, đối thủ A 77, đối thủ B 64. Nhìn con số thô, đội sản phẩm thở phào vì "trên trung bình 68". Nhưng khi đặt cạnh đối thủ A (77 — vượt trội), họ nhận ra mình đang tụt lại ở phân khúc dẫn đầu.

Diễn giải: SUS ở đây được dùng như một công cụ benchmark cạnh tranh (competitive benchmarking). Vì SUS được chuẩn hóa và không phụ thuộc tính năng cụ thể, bạn có thể so sánh táo với táo giữa các sản phẩm khác nhau — điều mà các metric nội bộ như "số click" không làm được.

Bài học rút ra: Một con số trên trung bình vẫn có thể là tín hiệu cảnh báo nếu đối thủ ở cao hơn. Luôn diễn giải điểm SUS trong ngữ cảnh so sánh, không chỉ so với mốc 68.

Ví dụ 3 — Startup SaaS B2B và cái bẫy cỡ mẫu

Một startup SaaS ở TP.HCM (giả định) làm phần mềm quản lý kho. Founder rất hào hứng khoe với nhà đầu tư: "SUS của chúng tôi là 88 — hạng A!". Nhưng khi hỏi kỹ, con số đó đến từ chỉ 3 người dùng, và cả ba đều là khách hàng thân thiết đã dùng sản phẩm cả năm.

Khi mở rộng khảo sát ra 18 người dùng mới đại diện hơn cho thị trường mục tiêu, điểm rơi xuống 65.

Diễn giải: Con số 88 ban đầu không sai về mặt tính toán, nhưng vô nghĩa về mặt thống kê và thiên lệch nghiêm trọng về mẫu. Ba người thân thiết không đại diện cho người dùng mới — nhóm mà sản phẩm cần chinh phục.

Bài học rút ra: Con số SUS chỉ đáng tin khi cỡ mẫu đủ và mẫu đại diện. Với SUS, thực tiễn khuyến nghị tối thiểu khoảng 12–15 người để ước lượng ổn định, và người tham gia phải phản ánh đúng chân dung người dùng thật.

Hướng dẫn từng bước

Đây là quy trình triển khai một lần đo SUS từ đầu đến cuối:

  • Xác định đối tượng đo (what). SUS đo trải nghiệm với một hệ thống cụ thể sau khi người dùng đã tương tác với nó. Hãy quyết định rõ: bạn đo toàn bộ app, hay chỉ một luồng (ví dụ luồng thanh toán)? Đo cái gì thì trong bảng câu hỏi từ "hệ thống" cần được thay bằng đúng đối tượng đó.
  • Chọn thời điểm đo (when). Nguyên tắc vàng: cho người dùng thực hiện task trước, rồi mới điền SUS ngay sau đó. Đừng phát bảng câu hỏi khi họ chưa dùng sản phẩm — SUS đo cảm nhận dựa trên trải nghiệm thực.
  • Tuyển người tham gia (who). Nhắm tối thiểu 12–15 người phản ánh đúng chân dung người dùng mục tiêu. Nếu cần so sánh nhiều nhóm (ví dụ người mới vs người cũ), mỗi nhóm nên đủ cỡ mẫu riêng.
  • Triển khai bảng câu hỏi. Giữ đúng 10 câu, đúng thứ tự xen kẽ tích cực/tiêu cực, thang 1–5. Có thể dùng Google Forms, Typeform hay chèn ngay trong sản phẩm. Bắt buộc trả lời cả 10 câu (không bỏ trống).
  • Chấm điểm từng phiếu. Áp dụng: câu lẻ = (điểm − 1); câu chẵn = (5 − điểm); cộng tổng rồi × 2.5. Bạn sẽ có một điểm SUS cho mỗi người.
  • Tính điểm trung bình của cả nhóm. Điểm SUS đại diện cho sản phẩm là trung bình cộng điểm SUS của tất cả người tham gia. Nên báo cáo kèm khoảng tin cậy (confidence interval) nếu có thể.
  • Diễn giải theo benchmark. Đặt điểm cạnh mốc 68, ngưỡng 80.3, và bảng grade/adjective. Nếu có dữ liệu đối thủ hoặc lần đo trước, so sánh trực tiếp.
  • Kết nối với hành động. SUS cho bạn biết có vấn đề hay không, chứ không nói vấn đề nằm ở đâu. Điểm thấp là tín hiệu để bạn đào sâu bằng nghiên cứu định tính. Luôn khép vòng lặp bằng bước hành động.

Lỗi thường gặp & mẹo

Lỗi 1 — Hiểu điểm SUS là phần trăm. Rất nhiều người báo cáo "SUS 80 nghĩa là 80% hài lòng". Sai. SUS là điểm trên thang 0–100, không phải tỷ lệ phần trăm. Luôn diễn giải qua benchmark.

Lỗi 2 — Sửa lời câu hỏi tùy tiện. Sức mạnh của SUS đến từ việc nó được chuẩn hóa. Nếu bạn tự viết lại câu hỏi, đảo thứ tự, hay bỏ bớt câu, bạn mất luôn quyền so sánh với benchmark ngành — thang đo trở thành một bảng khảo sát tự chế bình thường. Chỉ nên thay từ "hệ thống" bằng tên sản phẩm cụ thể.

Lỗi 3 — Bỏ qua tính xen kẽ khi Việt hóa. Khi dịch, hãy giữ đúng chiều của từng câu: câu tiêu cực phải thực sự mang nghĩa tiêu cực. Nếu bạn vô tình dịch câu 8 thành nghĩa tích cực, công thức chấm điểm sẽ tính sai hoàn toàn.

Lỗi 4 — Cỡ mẫu quá nhỏ hoặc mẫu thiên lệch. Như ví dụ 3, ba khách hàng thân thiết cho ra con số đẹp nhưng vô dụng. Ưu tiên đủ số lượng và đúng đối tượng.

Lỗi 5 — Coi SUS là câu trả lời cuối cùng. SUS là chẩn đoán tổng quát ("có sốt hay không"), không phải phác đồ điều trị ("bệnh gì, chữa sao"). Đừng dừng ở con số.

Mẹo hữu ích:

  • Chấm điểm bằng bảng tính: dựng sẵn một Google Sheet với công thức tự động, bạn chỉ việc nhập điểm thô của từng câu.
  • Luôn đo pre/post: giá trị lớn nhất của SUS nằm ở việc so sánh trước và sau thay đổi.
  • Ghi lại điều kiện đo: ai tham gia, task gì, phiên bản nào — để lần sau so sánh công bằng.
  • Kết hợp một câu mở phía sau: thêm câu hỏi "Điều gì khiến bạn cho điểm này?" để có manh mối định tính đi kèm con số.

Bài tập thực hành

Bài tập 1 — Chấm điểm thủ công. Một người dùng trả lời 10 câu SUS lần lượt như sau (theo thứ tự câu 1→10): 4, 2, 5, 1, 4, 2, 5, 1, 4, 2. Hãy tự tay áp dụng công thức (câu lẻ = điểm − 1; câu chẵn = 5 − điểm), cộng tổng rồi nhân 2.5. (Gợi ý kiểm tra: mỗi câu ở đây đều quy về 3 hoặc 4 điểm — bạn sẽ ra một điểm SUS khá cao, quanh mức 85–90. Hãy tự tính chính xác con số.)

Bài tập 2 — Diễn giải. Giả sử sản phẩm bạn đo được SUS trung bình 66 từ 20 người dùng, trong khi đối thủ chính đạt 74. Hãy viết 3–4 câu diễn giải: điểm của bạn ở mức nào so với benchmark 68, so với đối thủ ra sao, và bạn đề xuất bước tiếp theo là gì.

Bài tập 3 — Thiết kế một lần đo thật. Chọn một sản phẩm số bạn đang dùng (một app ngân hàng, một sàn TMĐT…). Viết ra kế hoạch đo SUS: đo luồng nào, tuyển bao nhiêu người và là ai, đo vào thời điểm nào trong hành trình, và bạn kỳ vọng điểm rơi vào khoảng nào. Đây là bài tập rèn tư duy quan trọng hơn cả việc tính toán.

Tóm tắt

Quantitative UX là nghệ thuật biến những cảm nhận mơ hồ về trải nghiệm thành con số có thể so sánh, theo dõi và truyền đạt. System Usability Scale (SUS) là điểm khởi đầu lý tưởng: 10 câu hỏi trên thang Likert 1–5, xen kẽ tích cực và tiêu cực, cho ra một điểm duy nhất trên thang 0–100.

Ghi nhớ ba điều cốt lõi:

  • Cách tính: câu lẻ = (điểm − 1), câu chẵn = (5 − điểm), cộng tổng rồi × 2.5.
  • Cách diễn giải: 68 là trung bình ngành, trên 80.3 là nhóm dẫn đầu; điểm SUS không phải phần trăm.
  • Cách dùng đúng: giữ nguyên bảng chuẩn hóa, đủ và đúng cỡ mẫu, đo pre/post, và luôn dùng con số làm chẩn đoán để dẫn tới nghiên cứu sâu hơn — chứ không dừng ở con số.
SUS mạnh vì nó đơn giản, rẻ và có benchmark. Nhưng hãy nhớ: nó nói cho bạn vấn đề usability hay không, chứ không nói vì sao. Đó là lý do trong các bài tiếp theo, chúng ta sẽ ghép SUS cùng các phương pháp khác để có một bức tranh trải nghiệm hoàn chỉnh.