Thông thường thang đo SUS ứng dụng kỹ thuật mà người ta hay gọi là Reverse-Worded Items, hay nói ngắn gọn là đảo chiều câu hỏi liên tục:

Việc kết hợp này tạo nên một Balanced Scale, buộc người dùng phải đọc kỹ từng câu và loại bỏ Acquiescence BiasXu hướng đồng ý với mọi phát biểu được đưa ra, bất kể nội dung — người trả lời tick trôi một cột cho xong thay vì đọc từng câu. Trộn câu tích cực với câu tiêu cực buộc họ phải đổi cột liên tục, nên người tick trôi sẽ lộ ra. (thiên kiến đồng tình).

Nhìn vào bảng câu hỏi để bạn dễ hình dung.

Khi đã có bảng câu hỏi chuẩn bạn có thể sẽ bắt gặp những pattern chuỗi zích zắc hoàn hảo: 5, 1, 5, 1, 5, 1. Bạn có thể nhìn thấy pattern này ở 2 response của Minh Anh và Thu Hà Đây chính là dấu hiệu bất thường.

Vậy thì câu hỏi đặt ra là chúng ta có thể làm gì khi phát hiện những pattern này trong dữ liệu.

Một trong những action có thể làm là đối chiếu thời gian làm bài và nguồn user thu thập. Ví dụ user trả lời dưới 30s thì có lẽ chúng ta không nên đưa vào dữ liệu tổng hợp. Và điều đó dẫn đến là chúng ta cần phải sẵn sàng đo lường con số thời gian survey để đảm bảo data sạch.

Còn một điều nữa cần làm trước khi tổng hợp dữ liệu. Bạn có thể nhìn thấy cột Q2 toàn số 1, nó sẽ gây nhiễu và khiến researcher khá là khó scan thông tin. Vì Q2 là Reverse scored nên điểm 1 lại là điểm tốt. Vậy tốt nhất bạn nên tạo một bảng mới để đưa các chỉ số về một chiều cho dễ quan sát.

Cả hai việc đều thuộc bước sàng lọc, phải xong trước khi bất kỳ con số nào được đưa vào phép tính — checklist đầy đủ nằm ở cuối bài.

Điểm trung bình 94,5 cho biết mức hài lòng chung, nhưng không phản ánh được khoảng cách đánh giá giữa 5 người dùng — đó là lý do cần xem xét chỉ số SDStandard Deviation (độ lệch chuẩn) — đo mức các con số chênh nhau quanh giá trị trung bình của chúng. Càng nhỏ thì các giá trị càng sát nhau; bằng 0 nghĩa là mọi giá trị giống hệt nhau, không chênh một chút nào. Cách tính từng bước, có ví dụ số → Math is Fun .

Với SD = 7,37, kết quả này thấp hơn đáng kể so với mức SD chuẩn của SUS (17,7Jeff Sauro tổng hợp trong A Practical Guide to the System Usability Scale (2011): qua nhiều nguồn và nhiều loại sản phẩm, các ước lượng SD của SUS trải từ 16,8 đến 22,5. Bản cập nhật 2022 của MeasuringU, dựa trên hai khảo sát hồi cứu 2017 và 2020, chốt mức thường dùng là 17,7. Đây là SD giữa những người trả lời trong một nghiên cứu — cùng cấp phân tích với con số 7,37 ở trên, nên hai số này so được với nhau. Nguồn: MeasuringU ). Trong một thử nghiệm chỉ có 5 người, độ phân tán quá nhỏ này nghiêng về sự đồng nhất bất thường của mẫu hơn là bằng chứng cho một sản phẩm ổn định.

Vậy điều gì đã làm chỉ số SD giảm bất thường? Có hai nguyên nhân chính.

Percentile (bách phân vị) là con số thể hiện vị trí tương đối của bạn so với toàn bộ cơ sở dữ liệu chuẩn, chứ không phải là tỉ lệ phần trăm điểm số (percentage).

Ô Percentile 100,00% trên dashboard vì thế nghĩa là điểm SUS 94,5 của hệ thống này đang nằm ở nhóm điểm cao vượt trội, tốt hơn khoảng 100% tổng số hệ thống/sản phẩm đã từng được đưa vào cơ sở dữ liệu benchmark — ở đây là 500 điểm SUS mà chính dashboard ghi trong chú thích.

Nói cách khác, con số percentile giúp bạn trả lời câu hỏi: “Điểm 94,5 này nếu so với mặt bằng chung các sản phẩm khác trên market thì đứng ở vị trí nào?”

Đến đây, có lẽ dữ liệu của 5 người chưa phải là một con số hoàn hảo để đánh giá SUS. Nhưng nếu nói n = 5 là một dữ liệu vô dụng thì cũng không đúng. Nếu so sánh giữa n = 0 và n = 5 thì tôi thấy việc có n = 5 đã là một việc thật sự quý giá.

Trong formative testFormative test (đánh giá định hình) là kiểm thử chạy trong quá trình thiết kế và phát triển — ở các giai đoạn sớm như wireframe, prototype, hay cuối mỗi sprint. Mục đích là tìm chỗ để sửa, khác với summative test vốn dùng để đo và nghiệm thu chất lượng ở cuối. Nguồn: NN/g , SUS trên năm người hoàn toàn có giá trị. Bạn không dùng nó để tuyên bố mức chất lượng; bạn dùng nó như một tín hiệu định hướng: rằng có gì đó đã tốt lên hoặc xấu đi. Đợt trước 62, đợt này 78, cùng task set, cùng cách tuyển người → hướng đang đúng.

Nhưng rồi sau tất cả, để ra được một quyết định thì cỡ mẫu cũng phải đủ lớn để quyết định đó đủ rõ ràng. Càng nhiều người tham gia, sai số của điểm SUS càng hẹp. Chúng ta có thể tham khảo các cột mốc của Lewis & Sauro (MeasuringU, 2022):

Lewis và Sauro tách SUS thành hai sub-score từ 2009: Usability gộp tám câu; Learnability chỉ gồm 2 câu (trong ví dụ trên là Q4 và Q10).

Cách tính giống điểm SUS tổng, chỉ khác hệ số quy đổi. Đưa từng câu về thang 0–4 — câu lẻ lấy điểm − 1, câu chẵn lấy 5 − điểm — rồi cộng lại và nhân hệ số để về thang 0–100:

Hãy thử phân tách điểm SUS thành hai điểm số Usability và Learnability để nhìn rõ hơn về từng người dùng:

Bạn có thể thấy chỉ số Learnability 100 ở cả năm người, đây là một trong những điểm yếu của bộ câu hỏi. Do Learnability (SUS) chỉ dựa trên 2 câu hỏi nên có độ nhạy rất thấp và dễ bị “kịch trần” (100/100). Nếu lúc này bài toán đặt ra cho product là “làm thế nào để user học nhanh hơn nữa”, thì điểm 100 không giúp team đưa ra next action.

Vậy để đo được khả năng học của user, chúng ta cần kết hợp thêm một số chỉ số khác như thời gianTime on Task — đo thời gian hoàn thành cùng một task ở lần 1 và lần 2. Learnability lộ ra ở khoảng cách giữa hai lần: rút ngắn nhanh là dễ học, gần như không đổi nghĩa là người dùng vẫn đang mò. Đi kèm là Task Completion Rate ở lần thử đầu — tỉ lệ hoàn thành khi chưa ai hướng dẫn gì. , tần suất lỗiError Rate — số lỗi trên mỗi task, tính riêng cho lần thử đầu: bấm nhầm chỗ, đi sai luồng, phải quay lại. Bổ sung bằng SEQ (Single Ease Question) — một câu hỏi độ khó đặt ngay sau mỗi task, để đối chiếu cảm nhận với hành vi vừa quan sát được. — mỗi chỉ số soi một mặt mà hai câu hỏi Learnability không với tới.

Như vậy, để đánh giá chi tiết hơn khả năng sử dụng của một ứng dụng, trong một chiến dịch đo lường chúng ta cần nhiều hơn một dashboard thì mới có được những chỉ dẫn có định hướng và rõ ràng hơn.

Vậy thì tổng kết lại chúng ta có gì: