Usability Testing
Giao cho người dùng thật một nhiệm vụ cụ thể rồi ngồi quan sát họ làm, để tìm chỗ khó dùng. Đo bằng việc họ có làm xong không, mất bao lâu và vướng ở đâu.
Định nghĩa
Đưa sản phẩm cho một người thật, giao một việc thật, rồi ngồi im mà xem. Không hướng dẫn, không giải thích, không nhảy vào chữa cháy khi họ bấm sai. Nghe đơn giản, nhưng phần "ngồi im" mới là phần khó, vì bản năng của người làm sản phẩm là chỉ đường ngay khi thấy ai đó lúng túng.
Người dùng không bao giờ sai. Họ bấm nhầm chỗ nào thì chỗ đó thiết kế chưa ổn.
Làm thế nào cho đúng
- Chọn một mục tiêu cụ thể. Đừng đặt kiểu "xem app dùng thế nào". Hãy đặt kiểu "kiểm xem người ta có tự hoàn tất được phiếu nhập kho không".
- Viết kịch bản dạng nhiệm vụ. "Anh vừa nhận 3 thùng hàng từ nhà cung cấp X, hãy ghi nhận vào hệ thống." Tránh dùng đúng từ có trong menu — kịch bản ghi "hãy vào chức năng Nhập kho" là đã cho sẵn đáp án.
- 5 đến 8 người mỗi nhóm là đủ. Nhóm nhỏ này lộ ra phần lớn lỗi nghiêm trọng, thêm 20 người nữa chỉ lặp lại phát hiện cũ.
- Yêu cầu họ nói to suy nghĩ. "Giờ em tìm nút lưu... không thấy... hay nó ở dưới cùng nhỉ." Câu lẩm bẩm đó chính là dữ liệu.
- Ghi lại: có hoàn thành không, mất bao lâu, bao nhiêu lần đi sai đường, chỗ nào phải hỏi.
- Xếp hạng phát hiện theo mức: chặn hoàn toàn, gây chậm, khó chịu nhẹ. Không xếp hạng thì team sẽ sửa cái dễ trước và bỏ lại cái đau nhất.
So sánh với UAT
Hai thứ hay bị gộp làm một, nhất là khi lịch gấp và ai cũng muốn tiết kiệm một buổi họp.
| Tiêu chí | Usability Testing | UAT |
|---|---|---|
| Câu hỏi cần trả lời | Người ta có tự dùng được không | Hệ thống có đúng yêu cầu đã ký không |
| Thời điểm | Từ giai đoạn prototype, càng sớm càng tốt | Cuối dự án, trước go-live |
| Người tham gia | Người dùng thật, chưa được hướng dẫn gì | Đại diện nghiệp vụ, đã qua đào tạo |
| Kết quả | Danh sách chỗ khó dùng, phải sửa thiết kế | Biên bản pass/fail theo tiêu chí chấp nhận |
| Khi họ bấm sai | Đó là phát hiện quý giá | Đó là defect, hoặc là do chưa đọc tài liệu |
Đợi tới UAT mới phát hiện luồng khó dùng thì đã muộn: code xong hết rồi, sắp go-live rồi, không ai dám sửa.
Ví dụ thực tế
Người thứ nhất cầm máy tính bảng, xoay ngang xoay dọc chừng nửa phút rồi hỏi: "Quét mã ở đâu em." Người thứ hai hỏi đúng câu đó, ở đúng chỗ đó. Phần mềm là hệ thống quản lý kho cho một nhà phân phối hàng tiêu dùng, người dùng là 27 thủ kho ở các tỉnh, phần lớn ngoài 40 tuổi, thao tác trên máy tính bảng.
Team chạy test với 6 thủ kho, mỗi người 25 phút, nhiệm vụ là kiểm kê một kệ hàng. Kết quả: 5 trên 6 người không tìm ra nút quét mã vạch, vì nó là icon nhỏ ở góc phải trên và không có nhãn chữ. Bốn người quay sang gõ tay mã sản phẩm 13 số, hai trong số đó gõ sai.
Sửa: thay icon bằng nút to có chữ "Quét mã", đặt cạnh ô tìm kiếm. Vòng test thứ hai với 5 người khác, cả 5 tìm ra trong dưới 5 giây. Cái nút đó nếu không test thì sẽ lên thẳng production và biến thành 30 cuộc gọi hỗ trợ trong tuần đầu.
Lỗi hay gặp
- Biến buổi test thành buổi demo. BA ngồi cạnh giới thiệu tính năng rồi hỏi "anh thấy dễ dùng chứ". Ai cũng gật.
- Mời nhầm người. Gọi trưởng phòng vào test thay cho nhân viên nhập liệu. Trưởng phòng không thao tác hằng ngày nên phản hồi lệch hẳn.
- Cứu người test. Thấy họ loay hoay 20 giây là nhắc, trong khi chính 20 giây đó là kết quả cần đo.
- Chạy đúng một lần rồi thôi.
Không ghi lại gì thì cả buổi coi như mất. Tan buổi, mỗi người nhớ một kiểu, tuần sau lại cãi nhau xem có thật là khó dùng không. Và sửa xong vẫn phải test lại, ít nhất với vài người chưa từng thấy bản cũ.
Nếu sếp không duyệt ngân sách cho việc này, cứ làm bản tối giản: mượn hai đồng nghiệp phòng khác chưa nghe gì về dự án, 15 phút mỗi người, quay màn hình bằng công cụ có sẵn. Không tốn đồng nào ngoài 30 phút mượn người. Đội nào bảo không có ngân sách cho usability test thì thường là chưa thử cách này.
