Cách đánh giá tính dễ sử dụng của công nghệ

Cách nhìn này phù hợp với ISO 9241-11:2018, trong đó usability được xem là kết quả sử dụng của những người dùng xác định nhằm đạt mục tiêu xác định với effectiveness, efficiency và satisfaction trong một bối cảnh sử dụng cụ thể. Vì vậy, cùng một phần mềm có thể dễ dùng với nhân viên chuyên môn nhưng khó dùng với nhân viên mới, hoặc thuận tiện trên máy tính nhưng bất tiện khi tác nghiệp trên thiết bị di động.

Doanh nghiệp nên biến khái niệm “dễ dùng” thành các nhiệm vụ có thể quan sát và đo lường. Ba câu hỏi trọng tâm là: người mới học nhanh đến đâu, quá trình thao tác tốn bao nhiêu thời gian và công sức, và người dùng có thực sự hoàn thành công việc với kết quả đúng hay không.

Xác định người dùng, nhiệm vụ và bối cảnh trước khi đo

Đánh giá usability phải bắt đầu từ công việc thực tế thay vì từ danh sách tính năng. Doanh nghiệp cần chọn những nhóm người dùng đại diện và xác định một tập nhiệm vụ đủ quan trọng để phản ánh cách giải pháp được sử dụng trong vận hành.

Chẳng hạn, với một hệ thống CRM, nhiệm vụ có thể là tạo khách hàng mới, tìm hồ sơ, cập nhật cơ hội bán hàng và xuất báo cáo. Với phần mềm kế toán, nhiệm vụ phù hợp có thể là nhập chứng từ, kiểm tra dữ liệu và hoàn tất một quy trình phê duyệt.

Bối cảnh cũng cần được giữ gần với thực tế. ISO mô tả context of use là sự kết hợp giữa người dùng, mục tiêu và nhiệm vụ, nguồn lực cùng môi trường sử dụng; môi trường có thể bao gồm yếu tố kỹ thuật, vật lý, xã hội và tổ chức.

Điều này đặc biệt quan trọng trong doanh nghiệp. Một thao tác mất 30 giây trong buổi demo chưa chắc vẫn mất 30 giây khi nhân viên phải xử lý hàng trăm giao dịch, chuyển qua nhiều màn hình, làm việc dưới áp lực thời gian hoặc sử dụng dữ liệu thật.

Vì vậy, trước khi thử nghiệm nên xác định ít nhất:

·         Nhóm người dùng đại diện

·         Những nhiệm vụ quan trọng cần hoàn thành

·         Điều kiện sử dụng và thiết bị

·         Mức kinh nghiệm ban đầu của người tham gia

·         Tiêu chí thế nào được tính là hoàn thành đúng

Các chỉ số thu được chỉ có ý nghĩa khi những điều kiện này được giữ nhất quán giữa các lần đánh giá.

Đo khả năng học qua thời gian để người mới tự thực hiện được công việc

Khả năng học không nên được đánh giá bằng câu hỏi “giao diện có dễ hiểu không?”. Chỉ số có giá trị hơn là người chưa quen hệ thống cần bao nhiêu thời gian và hỗ trợ để thực hiện thành công những nhiệm vụ cơ bản.

Có thể cho người dùng mới thực hiện cùng một nhóm nhiệm vụ qua nhiều lần và ghi nhận:

·         Thời gian đến lần hoàn thành thành công đầu tiên

·         Số lần phải hỏi người hướng dẫn

·         Số lần phải mở tài liệu trợ giúp

·         Số lỗi trong lần sử dụng đầu

·         Mức cải thiện thời gian hoặc số lỗi sau các lần lặp lại

Nếu thời gian hoàn thành giảm rõ rệt sau vài lần thực hiện và người dùng ngày càng ít cần trợ giúp, hệ thống đang thể hiện một đường học thuận lợi. Ngược lại, nếu người dùng vẫn phải ghi nhớ nhiều bước, liên tục tìm hướng dẫn hoặc thường xuyên quên trình tự, chi phí học sử dụng vẫn cao dù từng màn hình riêng lẻ trông đơn giản.

Doanh nghiệp cũng cần phân biệt học nhanh với được đào tạo kỹ. Nếu một hệ thống chỉ trở nên thuận tiện sau nhiều giờ đào tạo bắt buộc, kết quả đó không tương đương với việc người dùng có thể tự khám phá và bắt đầu làm việc nhanh.

Một phép thử hữu ích là đánh giá lại sau một khoảng thời gian không sử dụng. Người dùng có thể thực hiện tốt ngay sau buổi hướng dẫn nhưng quên quy trình sau vài tuần. Khả năng nhớ lại vì vậy giúp phát hiện những thiết kế phụ thuộc quá nhiều vào ghi nhớ thay vì cung cấp tín hiệu và hướng dẫn ngay trong quá trình thao tác.

Đo khả năng thao tác bằng thời gian, số bước, lỗi và mức nỗ lực

Sau khi người dùng đã biết cách sử dụng, doanh nghiệp cần kiểm tra họ phải bỏ ra bao nhiêu nguồn lực để đạt kết quả. Trong ISO 9241-11, efficiency liên quan đến nguồn lực sử dụng so với kết quả đạt được; những nguồn lực này có thể bao gồm thời gian và nỗ lực của con người.

Ở cấp nhiệm vụ, doanh nghiệp có thể ghi nhận thời gian hoàn thành, số thao tác, số lần quay lại màn hình trước, số lần nhập lại dữ liệu, lỗi phát sinh và số lần cần trợ giúp.

Không phải cứ ít cú nhấp chuột hơn là dễ dùng hơn. Một quy trình năm bước rõ ràng có thể hiệu quả hơn một quy trình ba bước nhưng khiến người dùng phải dừng lại suy nghĩ, kiểm tra lại dữ liệu hoặc sửa sai. Vì thế, số bước cần được đọc cùng thời gian, lỗi và nỗ lực nhận thức, không nên trở thành KPI độc lập.

Lỗi cũng cần được phân loại. Lỗi nhập liệu có nguyên nhân khác với lỗi chọn nhầm chức năng; việc không tìm thấy chức năng lại khác với việc hiểu sai trạng thái của hệ thống. Một chỉ số tổng như “10 lỗi” không đủ để chỉ ra vấn đề nếu doanh nghiệp không biết lỗi phát sinh ở bước nào và có thể phục hồi dễ hay không.

Khả năng phục hồi đặc biệt quan trọng đối với hệ thống nghiệp vụ. Nếu một lỗi nhỏ buộc nhân viên phải nhập lại toàn bộ biểu mẫu, liên hệ quản trị viên hoặc bắt đầu quy trình từ đầu, chi phí usability lớn hơn nhiều so với một lỗi có thể hoàn tác ngay.

Đo khả năng hoàn thành nhiệm vụ thay vì chỉ đo tốc độ

Một người thao tác rất nhanh nhưng tạo ra kết quả sai không thể được xem là sử dụng hệ thống hiệu quả. Vì vậy, chỉ số trung tâm phải là task success — người dùng có hoàn thành được nhiệm vụ theo đúng yêu cầu hay không.

ISO mô tả effectiveness qua mức độ chính xác và đầy đủ mà người dùng đạt được mục tiêu xác định. Doanh nghiệp có thể chuyển khái niệm này thành các chỉ số như tỷ lệ hoàn thành nhiệm vụ, tỷ lệ hoàn thành đúng ngay lần đầu, tỷ lệ cần trợ giúp và tỷ lệ bỏ dở.

Ví dụ, nếu 20 nhân viên thử thực hiện một quy trình và 17 người hoàn thành đúng mà không cần trợ giúp, tỷ lệ hoàn thành độc lập là 85%. Con số này có ý nghĩa trực tiếp hơn nhận xét “phần mềm khá trực quan”.

Không phải mọi nhiệm vụ đều có mức quan trọng như nhau. Một lỗi khi thay đổi ảnh đại diện không nên được đánh giá ngang với lỗi khi phê duyệt thanh toán hoặc nhập thông tin khách hàng. Doanh nghiệp nên xác định các nhiệm vụ trọng yếu và đặt yêu cầu usability nghiêm ngặt hơn cho những nhiệm vụ mà lỗi có hậu quả lớn.

Kết quả cũng cần được tách theo nhóm người dùng. Tỷ lệ hoàn thành trung bình 90% có thể che giấu trường hợp nhân viên có kinh nghiệm đạt gần như tuyệt đối nhưng người mới liên tục thất bại. Khi đó vấn đề nằm ở learnability chứ không nhất thiết ở khả năng vận hành của người đã thành thạo.

Kết hợp dữ liệu hành vi với đánh giá của người dùng

Thời gian, lỗi và tỷ lệ hoàn thành cho biết điều gì đã xảy ra; phản hồi của người dùng giúp giải thích họ cảm nhận quá trình đó như thế nào. Hai loại dữ liệu nên được sử dụng cùng nhau.

Một người có thể hoàn thành nhiệm vụ đúng nhưng phải tập trung cao độ và cảm thấy quy trình khó kiểm soát. Ngược lại, người dùng có thể nói rằng giao diện “rất dễ” dù dữ liệu cho thấy họ thường xuyên mất nhiều thời gian hoặc mắc lỗi.

Doanh nghiệp có thể sử dụng bảng hỏi chuẩn hóa như System Usability Scale (SUS) để bổ sung dữ liệu hành vi. SUS tạo một điểm số từ phản hồi chủ quan của người dùng. Một tập dữ liệu benchmark được tổng hợp từ 446 khảo sát/nghiên cứu cho thấy mức trung bình toàn bộ khoảng 68 điểm, còn nhóm phần mềm doanh nghiệp B2B khoảng 67,6 điểm. Những con số này hữu ích để tham chiếu, nhưng không nên được biến thành một ngưỡng đạt/trượt tuyệt đối cho mọi hệ thống.

Nghiên cứu của Bangor, Kortum và Miller cũng cho thấy SUS là công cụ có tính linh hoạt và độ ổn định cao cho việc đánh giá usability trên nhiều loại sản phẩm.

Nếu SUS tốt nhưng tỷ lệ hoàn thành thấp, doanh nghiệp cần tin vào dữ liệu nhiệm vụ trước khi kết luận hệ thống dễ dùng. Đánh giá chủ quan phản ánh trải nghiệm; nó không thay thế bằng chứng về việc công việc có được thực hiện chính xác hay không.

Đánh giá bằng benchmark nội bộ thay vì tìm một ngưỡng “dễ dùng” chung

Không có một con số duy nhất chứng minh mọi giải pháp công nghệ đều dễ sử dụng. Ngưỡng phù hợp phụ thuộc vào người dùng, nhiệm vụ và hậu quả khi thao tác sai.

Cách thực tế hơn là tạo benchmark cho chính bối cảnh doanh nghiệp. Khi thử nghiệm hệ thống hiện tại và giải pháp mới trên cùng nhóm nhiệm vụ, doanh nghiệp có thể so sánh trực tiếp:

So sánh như vậy giúp doanh nghiệp tránh một sai lầm phổ biến: lựa chọn giải pháp vì giao diện hiện đại hơn nhưng không chứng minh được rằng người dùng làm việc tốt hơn.

Một cải thiện cũng nên được xem xét theo từng chỉ số thay vì gộp ngay thành một điểm duy nhất. Giải pháp mới có thể giúp người dùng học nhanh hơn nhưng làm một số tác vụ thường xuyên chậm hơn. Đây là trade-off cần được nhìn thấy trước khi đưa ra kết luận.

Quy trình thử nghiệm giúp doanh nghiệp đưa ra kết luận đáng tin cậy

Một đánh giá usability có thể thực hiện theo vòng kiểm chứng tương đối gọn.

Trước hết, chọn người dùng đại diện cho các vai trò chính. Sau đó giao cho họ những nhiệm vụ thực tế với tiêu chí thành công đã xác định trước. Trong quá trình thực hiện, ghi lại việc hoàn thành, thời gian, lỗi, nhu cầu trợ giúp và những điểm người dùng bị mắc kẹt. Cuối phiên, thu thập phản hồi chủ quan bằng câu hỏi nhất quán hoặc một thang đo chuẩn hóa.

Sau đó không chỉ tính số trung bình mà phải xem từng nhóm người dùng và từng nhiệm vụ. Một quy trình duy nhất có tỷ lệ thất bại cao có thể quan trọng hơn việc điểm usability tổng thể khá tốt nếu đó là quy trình thiết yếu.

Cuối cùng, doanh nghiệp nên đặt tiêu chí chấp nhận dựa trên yêu cầu vận hành của mình. Chẳng hạn, một tác vụ thường xuyên có thể ưu tiên thời gian và số bước; tác vụ quan trọng về kiểm soát có thể ưu tiên độ chính xác và tỷ lệ hoàn thành; hệ thống dành cho lực lượng lao động thay đổi thường xuyên có thể đặt trọng số cao hơn cho thời gian học.

Cách đánh giá này biến “dễ sử dụng” từ một cảm nhận thành một đặc tính có thể kiểm chứng.

Tính dễ sử dụng của công nghệ nên được đánh giá qua hành vi của đúng người dùng trong đúng nhiệm vụ và bối cảnh. Doanh nghiệp cần xem người mới học nhanh đến đâu, người đã biết sử dụng phải bỏ ra bao nhiêu thời gian và nỗ lực, họ mắc lỗi như thế nào và cuối cùng có hoàn thành công việc chính xác hay không.

Khi kết hợp learnability, efficiency, effectiveness và phản hồi của người dùng, đồng thời so sánh các kết quả với benchmark nội bộ hoặc dữ liệu tham chiếu phù hợp, doanh nghiệp có thể xác định một giải pháp thực sự dễ sử dụng thay vì chỉ trông có vẻ dễ dùng.