Cách đánh giá khả năng sử dụng công cụ nghiên cứu

Đánh giá khả năng sử dụng phải bắt đầu từ bối cảnh sử dụng

Trước khi chọn thang đo hoặc chỉ số, cần xác định ai sử dụng công cụ, họ cần hoàn thành nhiệm vụ gì và trong điều kiện nào. Đây không phải bước chuẩn bị mang tính thủ tục mà là điều kiện để các số liệu usability có ý nghĩa.

Brooke chỉ ra rằng rất khó xác định khả năng sử dụng của một hệ thống nếu chưa biết người dùng dự kiến, nhiệm vụ họ thực hiện và đặc điểm của môi trường vật lý, tổ chức cũng như xã hội. ISO 9241-11 cũng xây dựng usability như một khái niệm gắn với tình huống sử dụng thay vì một thuộc tính tuyệt đối của sản phẩm.

Với một công cụ nghiên cứu, bối cảnh nên được mô tả đủ cụ thể để có thể xây dựng nhiệm vụ kiểm thử. Chẳng hạn, cùng một chức năng nhập dữ liệu có thể được nhà nghiên cứu giàu kinh nghiệm sử dụng thành thạo nhưng lại tạo nhiều lỗi cho trợ lý nghiên cứu mới. Kết quả của hai nhóm không mâu thuẫn; chúng cho thấy khả năng sử dụng phụ thuộc vào nhóm người dùng mà nghiên cứu đang quan tâm.

Điều này cũng đặt ra giới hạn khi so sánh công cụ. Hai điểm usability chỉ thực sự có giá trị so sánh khi các công cụ phục vụ mục tiêu tương đối tương đồng và được đánh giá trong các điều kiện đủ giống nhau. Việc so sánh trực tiếp những hệ thống phục vụ các nhiệm vụ rất khác nhau có thể dẫn đến kết luận sai.

Ba tiêu chí cốt lõi để đánh giá khả năng sử dụng

Một khung đánh giá có thể bắt đầu từ ba phương diện cốt lõi được sử dụng trong ISO 9241-11 và được Brooke diễn giải trong nghiên cứu về SUS: hiệu quả, hiệu suất và sự hài lòng. Ba phương diện này trả lời ba câu hỏi khác nhau: người dùng có làm được việc không, họ phải tốn bao nhiêu nguồn lực để làm được và họ cảm nhận thế nào về quá trình đó.

Hiệu quả: người dùng có hoàn thành đúng nhiệm vụ không?

Hiệu quả phản ánh mức độ người dùng đạt được mục tiêu của nhiệm vụ. Đối với công cụ nghiên cứu, chỉ hoàn thành thao tác chưa chắc đã đủ; kết quả còn phải đúng và đầy đủ.

Một chỉ số trực tiếp là tỷ lệ hoàn thành nhiệm vụ:

Tỷ lệ hoàn thành = Số nhiệm vụ hoàn thành đúng / Tổng số lần thực hiện × 100%

Có thể bổ sung tỷ lệ hoàn thành không cần trợ giúp, số lỗi nghiêm trọng hoặc độ chính xác của đầu ra. Ví dụ, nếu nhiệm vụ là xuất dữ liệu nghiên cứu, việc tạo được tệp nhưng làm thiếu biến hoặc sai định dạng vẫn là vấn đề về hiệu quả, không chỉ là vấn đề trải nghiệm.

Brooke mô tả effectiveness bằng khả năng hoàn thành nhiệm vụ và chất lượng đầu ra của nhiệm vụ đó, vì vậy tiêu chí thành công phải được xác định theo đúng loại công việc mà công cụ hỗ trợ.

Hiệu suất: hoàn thành nhiệm vụ với bao nhiêu thời gian và công sức?

Một người có thể cuối cùng vẫn hoàn thành nhiệm vụ nhưng phải thử lại nhiều lần, đọc hướng dẫn liên tục hoặc mất quá nhiều thời gian. Trong trường hợp đó, effectiveness có thể đạt nhưng efficiency vẫn thấp.

Các phép đo phù hợp gồm thời gian hoàn thành nhiệm vụ, số bước thực hiện, số lần quay lại thao tác trước, số lần cần trợ giúp và số lần thử lại. Brooke mô tả efficiency theo lượng nguồn lực được tiêu thụ trong quá trình thực hiện nhiệm vụ.

Không nhất thiết phải có một ngưỡng thời gian chung cho mọi công cụ. Hợp lý hơn là xác định ngưỡng theo nhiệm vụ, so với phiên bản trước, quy trình hiện tại hoặc một công cụ tương đương được sử dụng trong cùng điều kiện.

Sự hài lòng: người dùng cảm nhận việc sử dụng ra sao?

Satisfaction phản ánh phản ứng chủ quan của người dùng đối với việc sử dụng hệ thống. Người dùng có thể đánh giá mức độ dễ sử dụng, sự tự tin, mức độ phức tạp cảm nhận hoặc nhu cầu được hỗ trợ.

Tuy nhiên, sự hài lòng không nên được dùng thay cho dữ liệu hành vi. Một người có thể nói rằng công cụ “khá dễ dùng” nhưng vẫn mắc lỗi ở một nhiệm vụ quan trọng. Ngược lại, một chuyên gia có thể hoàn thành nhiệm vụ rất nhanh nhưng đánh giá trải nghiệm không tốt vì giao diện tạo nhiều thao tác thừa.

Do đó, satisfaction có giá trị nhất khi được đọc cùng effectiveness và efficiency chứ không phải như một kết luận độc lập.

Các chỉ báo bổ sung giúp tìm nguyên nhân khó sử dụng

Ba tiêu chí cốt lõi cho biết kết quả usability đang tốt hay kém, nhưng chưa phải lúc nào cũng giải thích được nguyên nhân. Khi cần chẩn đoán sâu hơn, có thể theo dõi khả năng học, lỗi và khả năng phục hồi, cùng mức độ phù hợp với các nhóm người dùng mục tiêu.

Khả năng học thể hiện qua việc người mới cần bao lâu để bắt đầu sử dụng được công cụ, số lần phải hỏi trợ giúp và mức cải thiện giữa những lần thực hiện nhiệm vụ. Nếu người dùng thất bại ở lần đầu nhưng nhanh chóng tự thực hiện được ở các lần sau, vấn đề có thể nằm ở quá trình làm quen. Nếu lỗi tiếp tục lặp lại, nguyên nhân có thể sâu hơn ở cấu trúc tương tác.

Lỗi và khả năng phục hồi cần được đánh giá không chỉ bằng số lần lỗi xảy ra. Một lỗi buộc người dùng làm lại toàn bộ công việc có mức tác động khác với một lỗi có thể sửa ngay mà không mất dữ liệu. Vì vậy, nên ghi nhận hậu quả của lỗi, khả năng nhận biết lỗi và việc người dùng có tự phục hồi được hay cần hỗ trợ.

Khả năng tiếp cận và sự phù hợp với người dùng cũng phải được xem trong bối cảnh nhóm mục tiêu. Kết quả trung bình tốt không chứng minh công cụ usable cho mọi nhóm nếu một nhóm người dùng quan trọng liên tục thất bại. Đây là lý do bối cảnh sử dụng cần được xác định trước khi thu thập dữ liệu.

Các chỉ báo trên nên được xem như lớp chẩn đoán hỗ trợ. Chúng giúp giải thích tại sao effectiveness, efficiency hoặc satisfaction kém, nhưng không cần thay thế ba tiêu chí cốt lõi bằng một danh sách đặc tính ngày càng dài.

Chuyển tiêu chí thành chỉ số đo lường cụ thể

Một đánh giá tốt cần chuyển khái niệm usability thành dữ liệu có thể quan sát hoặc đo lường. Có thể tổ chức bộ chỉ số theo cách sau:

Khung ISO xác định các lớp usability nhưng không quy định một phương pháp đánh giá duy nhất, vì vậy chỉ số cụ thể phải được lựa chọn theo mục tiêu và bối cảnh.

Dữ liệu hành vi cho biết người dùng thực sự làm được gì

Tỷ lệ thành công, thời gian, lỗi và yêu cầu trợ giúp đều đến từ hành vi thực tế trong nhiệm vụ. Chúng có ưu điểm là chỉ ra chính xác nơi người dùng gặp ma sát.

Đặc biệt, nên phân tích dữ liệu theo từng nhiệm vụ thay vì chỉ tạo một điểm trung bình cho cả công cụ. Một điểm tổng hợp có thể che khuất tình huống trong đó phần lớn chức năng hoạt động tốt nhưng một nhiệm vụ nghiên cứu quan trọng lại có tỷ lệ thất bại cao.

Quan sát định tính bổ sung câu trả lời cho câu hỏi “tại sao”. Việc ghi lại nơi người dùng dừng lại, hiểu sai thuật ngữ, chọn nhầm thao tác hoặc phải quay lại giúp biến một con số kém thành vấn đề cụ thể có thể xử lý.

Dữ liệu cảm nhận cho biết người dùng thấy việc sử dụng khó hay dễ ra sao

System Usability Scale (SUS) là một lựa chọn phổ biến khi cần phép đo tổng quát về perceived usability. Phiên bản của Brooke gồm 10 mục và tạo ra một điểm tổng hợp từ 0 đến 100. Tài liệu gốc cũng lưu ý rằng điểm của từng câu hỏi riêng lẻ không nên được diễn giải như các thước đo độc lập.

Điểm SUS 0–100 không phải tỷ lệ phần trăm nhiệm vụ được hoàn thành. Một công cụ đạt SUS 80 không có nghĩa là người dùng hoàn thành đúng 80% công việc. SUS phản ánh đánh giá cảm nhận tổng hợp, còn tỷ lệ hoàn thành phải được đo trực tiếp bằng dữ liệu nhiệm vụ.

Brooke cũng khuyến nghị thu SUS sau khi người tham gia đã sử dụng hệ thống và trước khi thảo luận/debrief để phản ứng ban đầu không bị ảnh hưởng bởi cuộc trao đổi sau thử nghiệm.

Quy trình thử nghiệm khả năng sử dụng của công cụ nghiên cứu

Khi tiêu chí và chỉ số đã rõ, quá trình kiểm thử nên giữ cho bối cảnh thử nghiệm gần với việc sử dụng thực tế và tránh thay đổi tiêu chuẩn đánh giá sau khi đã nhìn thấy kết quả.

1.    Xác định người dùng mục tiêu và bối cảnh bằng cách mô tả kinh nghiệm, nhiệm vụ, điều kiện sử dụng và các hạn chế có liên quan

2.    Chọn những nhiệm vụ nghiên cứu quan trọng thay vì kiểm thử các thao tác rời rạc không phản ánh mục tiêu thực tế

3.    Đặt tiêu chí thành công trước khi thử nghiệm, chẳng hạn nhiệm vụ phải hoàn thành đúng, không xảy ra lỗi nghiêm trọng và thời gian không vượt quá ngưỡng đã được xác định từ quy trình hiện tại

4.    Cho người tham gia thực hiện nhiệm vụ và ghi dữ liệu hành vi, gồm thành công, thời gian, lỗi, lần thử lại, yêu cầu trợ giúp và những điểm gây do dự

5.    Thu dữ liệu cảm nhận sau khi sử dụng, có thể bằng SUS kết hợp câu hỏi ngắn nhằm làm rõ nguyên nhân của những điểm khó

6.    Đối chiếu các nguồn bằng chứng theo từng nhiệm vụ, nhóm người dùng và mức độ nghiêm trọng trước khi đưa ra kết luận

Cỡ mẫu phải phụ thuộc vào mục tiêu của nghiên cứu. Với usability testing định tính nhằm phát hiện vấn đề, Nielsen Norman Group sử dụng 5 người tham gia như một hướng dẫn thực hành cho nhiều vòng kiểm thử nhỏ. Nhưng con số này không phải quy tắc cho nghiên cứu định lượng. Trong hướng dẫn riêng cho quantitative usability studies, NN/g cho rằng khoảng 40 người tham gia là một điểm tham chiếu phù hợp cho nhiều nghiên cứu, đồng thời nhấn mạnh rằng nhu cầu thực tế thay đổi theo phép đo và mức độ chính xác cần đạt.

Vì vậy, “thử với 5 người” chỉ nên được hiểu như một chiến lược khám phá định tính trong những điều kiện phù hợp, không phải bằng chứng rằng mọi điểm số hoặc tỷ lệ thu được từ 5 người đều đại diện đáng tin cậy cho toàn bộ người dùng.

Khi nào có thể kết luận công cụ có khả năng sử dụng tốt?

Không nên kết luận dựa trên một điểm số duy nhất. Một kết luận mạnh hơn xuất hiện khi nhiều loại bằng chứng cùng hướng về một kết quả.

Nếu người dùng hoàn thành các nhiệm vụ quan trọng với độ chính xác cao, thời gian và nỗ lực nằm trong giới hạn đã xác định, đồng thời đánh giá cảm nhận ở mức chấp nhận được, có cơ sở để xem công cụ đáp ứng yêu cầu usability trong bối cảnh đã kiểm thử. Cách diễn đạt cuối cùng này rất quan trọng vì usability không phải một thuộc tính tuyệt đối có thể tự động áp dụng cho mọi người dùng và mọi nhiệm vụ.

Ngược lại, nếu tỷ lệ hoàn thành thấp thì vấn đề chính nằm ở effectiveness, kể cả khi người dùng nói rằng giao diện đẹp hoặc dễ chịu. Nếu họ hoàn thành được nhưng mất quá nhiều thời gian hay liên tục cần trợ giúp, vấn đề chủ yếu là efficiency. Nếu dữ liệu hành vi tốt nhưng SUS hoặc phản hồi cảm nhận thấp, cần xem xét các yếu tố như độ phức tạp cảm nhận, khả năng học và mức độ tự tin trước khi quyết định thay đổi.

Benchmark cũng phải được sử dụng có điều kiện. So sánh với phiên bản trước của cùng công cụ hoặc một công cụ phục vụ nhiệm vụ tương đương thường có ý nghĩa hơn việc đặt cạnh một sản phẩm thuộc bối cảnh hoàn toàn khác. Tính phụ thuộc vào bối cảnh chính là lý do Brooke cảnh báo rằng việc so sánh usability giữa những hệ thống phục vụ mục đích khác nhau có thể gây hiểu lầm.

Cuối cùng, cần tách khả năng sử dụng khỏi độ giá trị và độ tin cậy khoa học của một công cụ nghiên cứu. Một bảng hỏi có thể rất dễ hoàn thành nhưng vẫn không đo đúng cấu trúc nghiên cứu cần đo; ngược lại, một công cụ có nền tảng đo lường tốt vẫn có thể gây khó khăn khi thao tác. Đánh giá usability trả lời câu hỏi công cụ có thể được sử dụng hiệu quả trong bối cảnh xác định hay không, chứ không thay thế việc kiểm định chất lượng khoa học của chính công cụ.

Đánh giá khả năng sử dụng công cụ nghiên cứu vì thế nên bắt đầu bằng bối cảnh sử dụng, sau đó đo hiệu quả, hiệu suất và sự hài lòng bằng cả dữ liệu hành vi lẫn dữ liệu cảm nhận. Các chỉ báo như khả năng học, lỗi, phục hồi và sự phù hợp với nhóm người dùng giúp giải thích nguyên nhân của những kết quả chưa đạt. Một kết luận đáng tin cậy không đến từ việc công cụ “có vẻ dễ dùng” hoặc đạt một điểm SUS nhất định, mà từ việc các nhiệm vụ quan trọng được hoàn thành đúng, với nguồn lực chấp nhận được và trải nghiệm phù hợp trong chính bối cảnh mà công cụ sẽ được sử dụng.