Đánh giá thực nghiệm

Đánh giá theo phương pháp kinh nghiệm là một phương pháp xem xét của chuyên gia, trong đó các chuyên gia kiểm tra giao diện dựa trên một tập hợp các nguyên tắc về khả năng sử dụng đã được thiết lập và ghi lại những nơi giao diện vi phạm các nguyên tắc đó. Được phát triển bởi Jakob Nielsen và Rolf Molich vào năm 1990, phương pháp này được thiết kế như một giải pháp thay thế nhanh chóng, chi phí thấp cho thử nghiệm người dùng, có khả năng tìm ra phần lớn các vấn đề về khả năng sử dụng mà không cần tuyển dụng người tham gia.

Quy trình của phương pháp quan trọng hơn là tập hợp các quy tắc cụ thể được sử dụng. Mỗi người đánh giá xem xét giao diện một cách độc lập, thường thực hiện hai lần, một lần để làm quen với luồng hoạt động và một lần để kiểm tra một cách có hệ thống. Các phát hiện được ghi lại bao gồm nguyên tắc bị vi phạm, vị trí và ước tính mức độ nghiêm trọng dựa trên tần suất, tác động và tính dai dẳng. Chỉ sau khi tất cả những người đánh giá đã hoàn thành việc đánh giá độc lập, các phát hiện mới được kết hợp, vì việc thảo luận trong quá trình đánh giá sẽ dẫn đến sự trùng lặp và làm giảm phạm vi bao quát. Nghiên cứu của Nielsen cho thấy rằng từ ba đến năm người đánh giá có thể xác định được phần lớn các vấn đề mà một nhóm lớn hơn có thể tìm thấy, và hiệu quả sẽ giảm mạnh khi số lượng người đánh giá vượt quá con số đó.

Ưu điểm chính của phương pháp này là tốc độ và chi phí. Việc đánh giá toàn diện một quy trình quan trọng có thể được hoàn thành trong vài ngày mà không cần tuyển dụng, lên lịch hay ngân sách khuyến khích, và nó có thể được áp dụng cho cả những công việc chưa được xây dựng, bao gồm cả bản phác thảo và nguyên mẫu. Phương pháp này cũng đưa ra các phát hiện được thể hiện dựa trên các nguyên tắc đã được thiết lập, giúp chúng có cơ sở lý luận vượt ra ngoài ý kiến ​​cá nhân và dễ bảo vệ hơn trong các cuộc thảo luận với các bên liên quan.

Những hạn chế của phương pháp này cũng đã được ghi nhận rõ ràng. Các chuyên gia đánh giá không phải là người dùng: họ hiểu sâu sắc các quy ước giao diện, họ không chia sẻ sự nhầm lẫn về thuật ngữ chuyên ngành hoặc bối cảnh cảm xúc của khách hàng thực sự, và họ không thể xác định một cách đáng tin cậy các vấn đề phát sinh do sự thiếu quen thuộc với chủ đề. Phương pháp này cũng tạo ra các kết quả dương tính giả, đánh dấu các vi phạm không ảnh hưởng đáng kể đến người dùng thực, và nó có xu hướng quá chú trọng vào các vấn đề bề mặt trong khi bỏ sót các sự không phù hợp về mặt khái niệm sâu sắc hơn giữa sản phẩm và mô hình tư duy của người dùng. Chất lượng của người đánh giá quyết định kết quả: phương pháp này chỉ tốt khi người áp dụng nó tốt.

Vì những lý do này, đánh giá theo kinh nghiệm nên được hiểu là sự bổ sung cho thử nghiệm người dùng chứ không phải là sự thay thế cho nó. Trình tự thực tế hiệu quả là tiến hành đánh giá của chuyên gia trước, khắc phục các lỗi rõ ràng, sau đó đưa phiên bản được cải tiến đến tay người dùng thực tế, để các phiên thử nghiệm không bị lãng phí thời gian vào các vấn đề mà bất kỳ chuyên gia nào cũng có thể xác định được. Thực hiện theo cách ngược lại sẽ lãng phí thời gian của người tham gia vào các lỗi không cần nghiên cứu để phát hiện.

Mức độ nghiêm trọng cần được chú trọng hơn so với thường lệ, bởi vì nó quyết định liệu kết quả có thể sử dụng được hay không. Một danh sách gồm bốn mươi lỗi mà không được ưu tiên sẽ khó xử lý và thường được giải quyết theo thứ tự dễ nhất, điều đó có nghĩa là các vấn đề nhỏ được khắc phục trong khi các vấn đề nghiêm trọng vẫn còn tồn tại. Việc đánh giá từng lỗi dựa trên số lượng người dùng bị ảnh hưởng, mức độ gây cản trở và liệu có thể khắc phục được sau khi đã biết hay không sẽ tạo ra một bảng xếp hạng phản ánh tác động đến hoạt động kinh doanh. Thêm ước tính về nỗ lực khắc phục cùng với mức độ nghiêm trọng sẽ biến danh sách thành một kế hoạch, phân tách các mục có mức độ nghiêm trọng cao, nỗ lực thấp cần được khắc phục ngay lập tức khỏi các mục có mức độ nghiêm trọng cao, nỗ lực cao cần được đưa vào lộ trình phát triển.

Vì đầu ra là một danh sách các lỗi được ưu tiên theo mức độ nghiêm trọng, nên nó tương ứng trực tiếp với danh sách công việc cần khắc phục, đó là lý do tại sao nó tạo thành xương sống của hầu hết các hệ thống. Kiểm tra trải nghiệm người dùng công việc. Các phát hiện thường được chia thành các mục có thể khắc phục ngay lập tức mà không cần xác nhận, vì hành vi hiện tại đơn giản là bị lỗi, và các mục thể hiện một lựa chọn thiết kế đáng để thử nghiệm, sau đó được đưa vào danh sách các thử nghiệm cần thực hiện của một nhóm nghiên cứu. Dịch vụ CRO chương trình được đưa ra thị trường thay vì chỉ dựa vào đánh giá của chuyên gia.