Kiểm tra khả năng sử dụng có một danh tiếng không xứng đáng là đắt tiền và chậm. Khi mọi người nghe "nghiên cứu người dùng," họ hình dung một bức kính một chiều, một người điều phối với clipboard, và một lịch trình hai tuần. Phiên bản kiểm tra đó tồn tại và có ứng dụng của nó — nhưng đó không phải là phiên bản mà hầu hết các đội sản phẩm cần hầu hết thời gian.
Phiên bản mà hầu hết các đội cần là đơn giản hơn: năm người dùng, một nguyên mẫu Figma hoặc một môi trường staging, một cuộc gọi video, và 45 phút mỗi phiên. Thực hiện tốt, điều này sẽ phát hiện hầu hết các vấn đề khả năng sử dụng nghiêm trọng trước khi chúng được phát hành. Thực hiện một cách liên tục — ngay cả một lần mỗi sprint — nó tạo ra một cải thiện ghép lũy tiến về chất lượng sản phẩm mà không có lượng phân tích sau khi phát hành nào có thể sao chép.
Đây là cách chạy nó từ đầu.
Năm người tham gia là con số phù hợp cho hầu hết các bài kiểm tra khả năng sử dụng. Nghiên cứu của Jakob Nielsen xác lập rằng năm người dùng phát hiện khoảng 85% vấn đề khả năng sử dụng, với lợi nhuận giảm dần sau đó. Chạy ba phiên năm người dùng tại các điểm khác nhau trong quá trình thiết kế có giá trị hơn một phiên với mười lăm.
Tiêu chí để tuyển dụng quan trọng hơn số lượng. Một bài kiểm tra khả năng sử dụng với năm người khớp chặt chẽ với người dùng mục tiêu của bạn sẽ tiết lộ vấn đề thực sự. Một bài kiểm tra với mười lăm người không khớp sẽ tạo ra tiếng ồn. Xác định hai hoặc ba tiêu chí sàng lọc — vai trò, bối cảnh sử dụng, mức độ thoải mái kỹ thuật — và tuân thủ chúng.
Tuyến đường tuyển dụng nhanh nhất cho hầu hết các đội là gửi email cho các người dùng hiện có đã cấp phép liên hệ. Cung cấp một sticker khiêm tốn — thẻ quà tặng £20 là đủ cho một phiên 45 phút. Nhắm mục tiêu lên lịch phiên trong cùng một tuần; khoảng cách càng dài giữa tuyển dụng và kiểm tra, tỷ lệ người không xuất hiện càng cao.
Lỗi kịch bản phổ biến nhất là viết các tác vụ dưới dạng hướng dẫn: "Nhấp vào Cài đặt, sau đó điều hướng đến Thông báo, và thay đổi ưu tiên của bạn thành..." Điều này cho người dùng biết phải làm gì, có nghĩa là bạn đang kiểm tra xem liệu họ có thể làm theo hướng dẫn không, không phải khả năng sử dụng của giao diện.
Viết các tác vụ dưới dạng kịch bản thay thế: "Tưởng tượng bạn đã nhận được quá nhiều thông báo và bạn chỉ muốn nhận cảnh báo khi ai đó đề cập đến bạn trực tiếp. Bạn sẽ làm gì?" Điều này cung cấp cho người dùng một mục tiêu thực tế và để bạn quan sát cách họ thực sự điều hướng — bao gồm nơi họ bị nhầm lẫn.
Phần khó nhất của việc điều phối một bài kiểm tra khả năng sử dụng là kháng cự sự muốn giúp đỡ. Khi một người dùng bối rối, mọi bản năng nói để bước vào và chỉ cho họ nơi cần nhấp. Nhưng sự nhầm lẫn là dữ liệu. Một người dùng đang gặp khó khăn đang nói với bạn một cái gì đó sai với giao diện — và vào lúc bạn can thiệp, bạn mất tín hiệu.
Yêu cầu người dùng suy nghĩ to trong suốt phiên: "Khi bạn đi, chỉ cần nói với tôi những gì bạn đang nhìn và những gì bạn đang suy nghĩ." Điều này tạo ra một luồng dữ liệu liên tục về mô hình tinh thần của họ. Ghi chú không chỉ lỗi mà còn cả sự ngập ngừng — một người dùng tạm dừng ba giây trước khi nhấp vào nút đúng vẫn đã tiết lộ một vấn đề thiết kế, ngay cả khi họ cuối cùng cũng thành công.
Bước tổng hợp là nơi tạo ra hầu hết giá trị — và nơi hầu hết các đội cắt góc. Ghi chú thô từ năm phiên không phải kết luận. Họ trở thành kết luận khi bạn debrief làm một đội, nhóm quan sát theo chủ đề, và gán xếp hạng mức độ nghiêm trọng.
Thực hiện debrief vào cùng ngày với các phiên, trong khi quan sát còn tươi. Nhóm vấn đề thành ba nhóm: quan trọng (người dùng không thể hoàn thành tác vụ), vừa phải (người dùng hoàn thành tác vụ nhưng gặp khó khăn hoặc lỗi đáng kể), và nhỏ (ma sát không ngăn chặn hoàn thành). Các vấn đề quan trọng cần được sửa trước khi phát hành. Các vấn đề vừa phải nên được ưu tiên trong sprint tiếp theo. Các vấn đề nhỏ đi vào backlog.
Viết kết luận trong một trang: ba vấn đề quan trọng hàng đầu, với bằng chứng từ ít nhất hai người tham gia mỗi, và một thay đổi thiết kế được đề xuất cho mỗi. Bất cứ điều gì cần nhiều khoảng không gian hơn thuộc về một tài liệu riêng biệt.