Trong từ điển Anh Việt, chúng ta không có từ dịch ngang hàng cho “Heuristic”, nhưng chúng ta có thể hiểu những vấn đề đã được công nhận thông qua kinh nghiệm, nghiên cứu tích lũy, gọi là Heuristic. Ví dụ trong thiết kế đồ họa, một trong số những heuristic của việc xử lý chữ đó là, để đảm bảo khả năng đọc cũng như nối giữa dòng chữ của một đoạn văn sử dụng ký tự latin, một dòng chỉ nên chứa từ 45 – 75 ký tự. Tối ưu nhất là 66 ký tự trong một dòng.
Tôi sẽ cố gắng sử dụng Tiếng Việt nhiều hết mức có thể, nhưng vì sự đan xen giữa Tiếng Việt và các thuật ngữ chưa dịch chính xác được trong bài viết sẽ khá là dày đặc, khiến cho tôi có thể sử dụng Tiếng Anh một cách không thật cần thiết. Nếu điều đó xảy ra, mong độc giả thông cảm.
Bài viết này mang dày tính chất học thuật, tôi sẽ cố gắng sử dụng từ ngữ tự nhiên trong những phần nhận định để làm cho trải nghiệm đọc của bạn vui hơn, nhưng bạn vẫn nên suy xét trong việc lấy một lon redbull, tìm một chỗ ngồi thoải mái, vì bài viết này sẽ tương đối căng não 😀
Heuristic Evaluation (Sẽ được viết tắt là HE) là hoạt động khảo sát và đánh giá sự tuân thủ của một giao diện với bộ nguyên tắc về tính khả dụng đã được công nhận, được thực hiện bởi một nhóm nhỏ bao gồm các chuyên gia về thiết kế giao diện người dùng.
— Định nghĩa bởi Jacob Nielsen vào ngày 1 tháng 11 năm 1994
Trước khi đi sâu vào các bước trển khai của phương pháp, tôi thấy cần phải nhấn mạnh rằng, trong thời điểm hiện tại, khi các giao diện người dùng tràn ngập với vô vàn các sản phẩm phần mềm, được tạo mới với tốc độ nhanh hơn bao giờ, việc sử dụng Heuristic thay cho các hoạt động tốn kém hơn như usability testing cần được ưu tiên thực hiện trong tất cả các giai đoạn có thể của việc phát triển sản phẩm.
Ngay khi có những thiết kế đầu tiên cho giao diện người dùng, nhóm phát triển sản phẩm đã hoàn toàn có thể bắt tay thực hiện HE để đảm bảo việc phát hiện sớm các lỗi về độ khả dụng của sản phẩm. Đặc biệt nếu nhóm thiết kế sản phẩm của bạn có đủ nguồn lực để thực hiện kiểm thứ tính khả dụng của sản phẩm trên người dùng thật, việc thực hiện HE xen kẽ giữa các lần release của sản phẩm sẽ giúp nhóm sản phẩm có thể “clean up” lỗi và khiến cho việc thực hiện usability testing hiệu quả hơn và đỡ tốn kém hơn. Hiện này, hầu hết các nhóm phát triển sản phẩm hoạt động với mô hình agile, quá trình phát triển sản phẩm được chia thành các giai đoạn nước rút gọi là Sprint. Mỗi sprint có thể bao gồm một release hoặc một vài sprint thành một release, nhưng cách tích hợp về cơ bản, ở cuối mỗi sprint, nhóm được chỉ định làm HE nên thực hiện một session để đánh giá tất cả các thiết kế đã hoàn thành trong sprint đó.
🤔 ờm …. Ok, nhưng mà làm sao chúng tôi có thể tích hợp được việc thực hiện HE nhiều lần nếu luôn cần phải có sự tham gia của một nhóm chuyên gia, dù là nhỏ???? Đừng lo, tôi sẽ trả lời câu hỏi này sau khi trình bày với bạn tất cả các bước thực hiện.
Các bước thực hiện Heuristic Evaluation bao gồm:
Bây giờ tôi sẽ cùng bạn đi sâu vào từng bước thực hiện phương pháp đánh giá này.
Phương pháp đo lường này dựa vào kinh nghiệm cũng như những tiêu chuẩn đã được cộng đồng phát triển phần mềm công nhận sau nhiều thập kỷ hoạt động. Theo thống kê thì các tiêu chuẩn cho tính khả dụng được sử dụng trong tất cả các bộ checklist có khả năng áp dụng cho hầu như tất cả các sản phẩm phần mềm vì dù sao chăng nữa, tất cả những đầu mục trong check list đều nhằm phục vụ việc đánh giá khả năng đảm bảo 5 yếu tố cơ bản của tính khả dụng (xem bài viết tổng hợp về tính khả dụng và trải nghiệm người dùng tại đây). Mặc dù vậy, sau thời gian phát triển lâu dài, các công ty với đặc thù về phần mềm khác nhau dần dần đều xây dựng cho mình những bộ Usability Heuristics riêng ví dụ Apple xây dựng thành bộ “apple human interface guidelines” hay Google có Material design guidelines…
Trong thời đại hiện nay khi các ứng dụng ngoài việc đảm bảo các yếu tố về usability thì việc trở nên khác biệt cũng vô cùng quan trọng, thế nên, không phải lúc nào bạn cũng có thể sử dụng hoàn toàn các guideline của các nền tảng nêu trên đặc biệt khi hệ thống UI của bạn có độ phức tạp trung bình đến cao. Vì tôi muốn giới thiệu đến các bạn bộ Usability Heuristic Checklist của Nielsen Norman Group. Tổ chức này là một tổ chức về trải nghiệm người dùng độc lập nên bộ checklist của họ có tính tùy biến cao, và có khả năng áp dụng được cho hầu như tất cả các sản phẩm trên thị trường hiện nay. Guidelines của Apple thời đầu cũng được phát triển bởi chính founder của tổ chức này. Bộ Checklist này của Nielsen Norman Group được chia làm 10 mục chính sau:
#1: Visibility of system status – Độ hiện diện của trạng thái hệ thống.
#2: Match between system and the real world – Sự tương đồng giữa hệ thống và thế giới thực
#3: User control and freedom – Khả năng kiểm soát của người dùng và tự do trong cách thực hiện
#4: Consistency and standard – Tính đồng nhất và tiêu chuẩn
#5: Error prevention – Khả năng ngăn chặn lỗi
#6: Recognition rather than recall – Nhận biết thay vì phải ghi nhớ
#7: Flexibility and efficiency of use – Tính linh hoạt và hiệu quả trong sử dụng
#8: Aesthetic and minimalist design – Thiết kế có tính thẩm mỹ và tinh gọn
#9: Help users recognize, diagnose, and recover from error – Giúp người dùng nhận biết, hiểu nguyên nhân và khắc phục lỗi.
#10: Help & Documentation – Trợ giúp và tài liệu hướng dẫn
10 Usability Heuristic này đã trở thành cẩm nang của cộng đồng UX thế giới trong một vài năm gần đây và bản thân tôi cũng đã có một buổi chia sẻ về chính 10 Heuristic này, nên tôi sẽ không giải thích quá sâu vào phần này nữa. Bạn có thể tải bản checklist Chúng tôi đang trong quá trình xây dựng ở đây. Một trong số nhứng dự án On-going của OLabs
🔗 OLabs Usability Heuristics Checklist
Sau khi chọn bộ checklist phù hợp, chúng ta cần lên kế hoạch để thực hiện HE, Kế hoạch thực hiện rất quan trọng vì nếu không lên kế hoạch để tích hợp phương pháp này vào trong quy trình của bạn một cách nghiêm túc, rất dễ dẫn đến việc kết quả HE bị bỏ qua, hoặc không chuyên tâm hay evaluator bị bias khiến cho kết quả HE không chính xác.
Hiện tại OLabs mới chỉ có kinh nghiệm khoảng 6 tháng thực hiện phương pháp này nên việc lên kế hoạch vẫn chưa có một phương pháp cụ thể, nhưng chúng tôi cũng có một vài đúc kết như sau để bạn tham khảo:
Tham khảo thêm một số bộ usability standard khác:
Iso’s 7 dialogue principles: Suitability for the task, suitability for learning, suitability for individualization, conformity with user expectations, self descriptiveness, controllability, error tolerance.
Schneiderman’s 8 golden rules of interface design: Strive for consistency, cater to universal usability, offer informative feedback, design dialogs to yield closure, prevent errors, permit easy reversal of actions, support internal locus of control, reduce short-term memory load.
Arnie Lund’s “Expert Ratings of Usability Maxims”
Bruce Tognazzini’s “Principles of Interaction Design”
Phương pháp HE là phương pháp tương đối rẻ và nhanh so với các phương pháp kiểm thử, đo lường sử dụng số liệu (Empirical methods), nhưng vẫn không hề nhẹ hàng, trong những năm đầu của ngành, để evaluate được một hệ thống giao diện, đôi khi cần đến hàng chục expert ở các lĩnh vực khác nhau để có thể trao đổi và đánh giá, dĩ nhiên là thời đó ngay cả chính những phương pháp như thế này vẫn còn đang được đưa lên bàn cân để đánh giá độ hiệu quả. Một chuyên gia khó có thể chỉ ra hết được các vấn đề về usability, đặc biệt là trong những hệ thống phức tạp, nó tốn rất nhiều năng lượng tư duy. Theo nghiên cứu của Nielsen Norman Group thì một chuyên gia thông thường sẽ tìm thấy 35% các vấn đề về Usability trong các giao diện. Đồng thời, nhiều người đánh giá khác nhau có xu hướng tìm ra các vấn đề khác nhau, có thể đạt được hiệu suất tốt hơn đáng kể bằng cách tổng hợp các đánh giá từ một số người đánh giá.
Hình bên trên cho thấy tỷ lệ các vấn đề về Usability được tìm thấy khi ngày càng có nhiều người đánh giá được thêm vào. Có vẻ hợp lý khi đề xuất sử dụng khoảng 5 người đánh giá, nhưng chắc chắn ít nhất là 3. Số lượng người đánh giá chính xác sẽ sử dụng sẽ phụ thuộc vào phân tích lợi ích chi phí.
Đối với một dự án, giả sử rằng mất 15.000$ để tìm ra mỗi vấn đề về Usability, con số được tạo ra bởi Nielsen và Landauer (1993) từ một số nghiên cứu được công bố. Hình bên dưới cho thấy tỷ lệ khác nhau của lợi ích so với chi phí cho số lượng người đánh giá khác nhau trong mỗi dự án. Trong ví dụ này, một bản đánh giá heuristic với bốn người đánh giá sẽ tốn 6.400$ và sẽ tìm thấy các vấn đề về Usability trị giá 395.000$. Đồ thị cho thấy số lượng người đánh giá tối ưu trong ví dụ này là 4, xác thực cho đánh giá ở trên rằng đánh giá heuristic sẽ hiệu quả nhất với từ 3 đến 5 người đánh giá.
Ngoài ra, với tinh thần là sự đa dạng trong đội ngũ evaluator sẽ tăng tính chính xác của HE, thế nên ngoài số lượng, chúng tôi cũng khuyến cáo nhóm phát triển sản phẩm sử dụng một team gồm có chuyên gia về các chuyên môn khác nhau trong thiết kế giao diện, ví dụ một UX researcher, một Interaction designer, product designer hay thậm chí là một senior front-end developer… Về việc như thế nào thì đạt tiêu chuẩn thì OLabs đề xuất chuyên gia nên có tối thiểu 5 năm trong ngành và trong trường thông thường thì có bằng kỹ sư phần mềm, ngành thiết kế đa phương tiện- có môn thiết kế tương tác hoặc về tâm lý học hay khoa học hành vi.
Chuyên gia về usability không có nghĩa là họ biết mọi thứ, ngay kể cả checklist này. Những người đã làm lâu năm trong ngành, tiếp xúc và xây dựng với nhiều giao diện khác nhau hay nghiên cứu sâu vào một chủ đề trong thiết kế giao diện như interaction design đều có thể được coi là usability expert. Khi xác định được phạm vi đánh giá đồng thời thành lập được một nhóm evaluators thì bạn cần phải training lại cho các thành viên của nhóm về các thành phần của checklist, cách ghi chú các lỗi xác định được trong quá trình thực hiện, nhất là nếu trong quy trình phát triển sản phẩm của team có tiêu chuẩn riêng cho việc log lỗi cũng như các bước thực hiện. Một buổi meeting với tất cả mọi người sẽ đảm bảo việc training được truyền tải một cách hiệu quả, những câu hỏi được đưa ra trong qúa trình training cũng sẽ giúp nội dung của buổi training rõ ràng hơn.
Tùy vào trạng thái của sản phẩm mà có thể môi trường đánh giá sẽ khác nhau, nhưng nhìn chung, phương pháp này không cần phải thực hiện tại một địa điểm cụ thể như phòng labs. Có một điểm quan trọng là trong quá trình thực hiện HE, các evaluators không được tham khảo ý kiến hay xem kết quả của nhau, điều này nhằm đảm bảo tránh bias trong quá trình thực hiện. Cụ thể trong quá trình thực hiện HE sử dụng bộ Checklist được phát triển bởi Nielsen Norman Group, mỗi evaluator sẽ khảo sát các tính năng được yêu cầu và so sánh với bản tiêu chí đánh giá gồm có 10 thành phần usability heuristic đã đề cập bên trên.
Trong tài liệu hoặc công cụ được lựa chọn để ghi chú những lỗi về tính khả dụng của sản phẩm, với mỗi một lỗi hoặc hơn, tương ứng với một trong số 10 đầu mục được nêu trên, evaluator sẽ đánh giá độ nghiêm trọng của lỗi đó. Mức độ nghiêm trọng của lỗi được chia làm 5 mức độ
Mức độ nghiêm trọng của vấn đề được đánh giá dựa trên 3 tiêu chí:
Mức độ 0: Không phải vấn đề về khả dụng
Đôi khi có những vấn đề mà evaluator muốn chỉ ra mặc dù nó không liên quan đến tính khả dụng của sản phẩm, ví dụ vấn đề xảy ra do lỗi hệ thống.
Mức độ 1: vấn đề bề mặt (cosmetic)
Những sai sót nhỏ trong việc thiết kế, ví dụ như thừa dấu cách, dấu phẩy, Icon khi vẽ bị lệch căn trái hay bị nhòe, nhưng vẫn nhận dạng được. Sửa khi có thời gian trong dự án.
Mức độ 2: Minor usability problem – Vấn đề nhỏ
Độ ưu tiên thấp khi lên kế hoạch sửa.
Mức độ 3: Major usability problem – Vấn đề lớn
Ưu tiên sửa trước vì nó có thể ảnh hưởng mạnh đến trải nghiệm người dùng.
Mức độ 4: Usability catastrophe – khủng hoảng
Không nên release nếu sản phẩm của bạn vẫn còn đang mắc lỗi ở mức độ này.
Về cơ bản, các cấp độ của lỗi usability nghe rất đơn giản, nhưng khi chúng ta đặt con số và tên gọi cho nó, việc giao tiếp giữa các thành viên trong dự án sẽ được thực hiện một cách trơn chu hơn rất nhiều, đồng thời củng cố tầm quan trọng của usability trong quá trình phát triển sản phẩm.
Sau khi hoàn thành việc đánh giá, các bản đánh giá của các evaluator sẽ được thu thập và tổng hợp, lúc này chúng ta có thể review tập thể để có thể cùng đồng thuận về việc vấn đề usability gặp phải hoặc chọn một chuyên gia để tổng hợp thành một kết quả cuối cùng để tạo ra một bản thành phẩm cho nhóm phát triển sửa và cải thiện sản phẩm. OLabs gọi là bản danh sách lỗi khả dụng
Ngoài tài liệu bàn giao đó, nhóm thực hiện cũng nên review về trải nghiệm phương pháp, đồng thời có thể đưa ra một bản thống nhất về guideline thực hiện các phiên HE sau này.
Giai đoạn này cũng chính là giai đoạn để nhóm sản phẩm có thể dần đưa ra một quy chuẩn về usability phù hợp nhất với sản phẩm của nhóm. và đồng thời trả lời câu hỏi đã được đưa ra từ phần trước của bài viết, làm sao để tích hợp được HE vào trong quy trình phát triển sản phẩm theo phương pháp agile và có thể làm HE được nhiều lần trong quá trình phát triển mà không bị quá phụ thuộc vào nhóm chuyên gia. Thực ra mình cũng không có câu trả lời hoàn hảo cho câu hỏi này, nhưng mình sẽ đưa ra một số những gợi ý như sau:
Không quan trọng sản phẩm công nghệ bạn đang phát triển là gì, quy trình phát triển và quản lý trải nghiệm người dùng như thế nào, phương pháp HE là một phương pháp vô cùng hiệu quả và nên được thực hiện một cách linh hoạt. Hy vọng bài viết này sẽ giúp bạn và team sản phẩm của bạn release những sản phẩm chất lượng tối ưu nhất ra thị trường.
Cập nhật những thông tin mới nhất về UX mỗi ngày.
