Buổi 3 — Đọc kết quả usability test
PM không cần tự chạy usability test, nhưng phải biết đọc kết quả và phải ngồi xem ít nhất vài buổi.
Vì sao PM nên dự trực tiếp
Đọc báo cáo "người dùng gặp khó ở bước 3" hoàn toàn khác với ngồi xem một người thật loay hoay hai phút ở bước đó rồi bỏ cuộc.
Trải nghiệm trực tiếp thay đổi mức độ ưu tiên theo cách mà không báo cáo nào làm được. Đó là lý do nên dự, không phải vì bạn cần học phương pháp.
Năm người là đủ
Với usability test định tính, khoảng năm người cho mỗi nhóm người dùng chính sẽ phát hiện phần lớn vấn đề nghiêm trọng. Người thứ sáu trở đi chủ yếu lặp lại điều đã thấy.
Đây không phải nghiên cứu định lượng — bạn không kết luận "40% người dùng gặp vấn đề". Bạn phát hiện vấn đề tồn tại và hiểu vì sao.
Think aloud và vì sao nó quan trọng
Người tham gia được đề nghị nói to suy nghĩ khi thao tác. Không có nó, bạn chỉ thấy họ bấm gì; có nó, bạn biết họ đang mong đợi gì và vì sao họ bấm nhầm.
"Tôi tưởng cái này sẽ lưu lại" là loại thông tin không quan sát được từ bên ngoài.
Nguyên tắc cho người quan sát
Không giải thích, không hướng dẫn. Khoảnh khắc người tham gia bối rối chính là dữ liệu. Cứu họ là xoá mất dữ liệu đó.
Không hỏi "bạn có thích không". Hỏi "bạn nghĩ chuyện gì vừa xảy ra" và "bạn định làm gì tiếp theo".
Ghi lại nguyên văn, không ghi diễn giải. "Người dùng thấy khó hiểu" là kết luận của bạn; "tôi không biết cái này đã lưu chưa" là dữ liệu.
Phân loại vấn đề sau khi test
Chia theo mức nghiêm trọng, không theo thứ tự xuất hiện:
- Chặn — người dùng không hoàn thành được nhiệm vụ. Sửa trước khi ship.
- Nghiêm trọng — hoàn thành được nhưng mất nhiều thời gian hoặc phải thử nhiều lần.
- Nhỏ — gây khó chịu, không cản trở.
Cạm bẫy diễn giải
Nhầm ý kiến với hành vi. Người tham gia nói "tôi sẽ dùng cái này hằng ngày" — đó là lời nói. Việc họ vừa mất ba phút để tìm nút chính — đó là hành vi. Tin hành vi.
Sửa triệu chứng. Người dùng không tìm thấy nút, phản ứng bản năng là làm nút to hơn. Nhưng có thể vấn đề là họ không nghĩ chức năng đó tồn tại ở màn hình này — làm nút to hơn không giải quyết gì.
Bài tập
Dự một buổi usability test, hoặc xem một bản ghi. Ghi lại ba câu nguyên văn của người tham gia. Mang ba câu đó tới cuộc họp ưu tiên tiếp theo — chúng sẽ thay đổi cuộc thảo luận.
<!--les-append-->
Kịch bản một buổi 30 phút
Bạn không cần là người điều phối chuyên nghiệp để chạy được buổi cơ bản:
| Phút | Làm gì |
|---|---|
| 0–3 | Giải thích: đang kiểm sản phẩm, không kiểm bạn. Nói rõ không có câu trả lời sai. |
| 3–5 | Hỏi về bối cảnh: hôm nay họ làm việc này thế nào |
| 5–25 | Giao nhiệm vụ, rồi im lặng |
| 25–30 | Hỏi lại những chỗ họ ngập ngừng: lúc đó anh/chị đang nghĩ gì? |
Điều khó nhất: im lặng
Khi người dùng loay hoay, bản năng là giúp. Đừng. Sự loay hoay đó chính là dữ liệu bạn đến để lấy.
Nếu họ hỏi "cái này bấm vào đâu?", đừng trả lời. Hỏi ngược: "Anh/chị nghĩ nó nằm ở đâu?" Câu trả lời cho bạn biết mô hình trong đầu họ — thứ quý hơn nhiều so với việc họ bấm đúng hay sai.
Câu hỏi nên và không nên
| Đừng hỏi | Hãy hỏi |
|---|---|
| "Anh/chị thấy có dễ dùng không?" | "Anh/chị sẽ làm gì tiếp theo?" |
| "Có thích giao diện này không?" | "Lúc nãy anh/chị dừng ở đây, đang nghĩ gì?" |
| "Anh/chị có muốn thêm tính năng X không?" | "Lần gần nhất gặp việc này, anh/chị xử lý sao?" |
| "Anh/chị hiểu nút này chứ?" | "Theo anh/chị, bấm nút này thì gì xảy ra?" |
Ghi chép và phân loại
Ghi nguyên văn điều họ nói và điều họ làm, đừng diễn giải ngay. "Người dùng không hiểu" là kết luận; "người dùng bấm ba lần vào phần tiêu đề không bấm được" là quan sát.
Sau đó đếm: bao nhiêu trên năm người gặp cùng một vấn đề?
- 3+/5 → vấn đề thật, phải sửa
- 2/5 → đáng chú ý, cần thêm dữ liệu
- 1/5 → có thể là thói quen riêng
Làm ngay
Đặt lịch dự một buổi usability test trong tháng này — chỉ dự, không cần chạy. Ghi lại một chỗ người dùng ngập ngừng mà bạn không ngờ tới. <!--/les-append-->