Bạn thiết kế một giao diện và thấy nó rõ ràng đến mức không thể nhầm. Nhưng người dùng thật thì lại bấm sai chỗ, cuộn lên cuộn xuống tìm nút, hoặc bỏ cuộc giữa chừng. Khoảng cách giữa “rõ với người làm ra nó” và “rõ với người lần đầu thấy” chính là thứ usability test giúp bạn nhìn ra.
Usability test khác gì các cách đo lường khác
Nhiều người gộp chung mọi cách “test” giao diện vào một rổ. Thực ra chúng trả lời ba câu hỏi rất khác nhau, và usability test trả lời câu khó nhất: tại sao người dùng vướng.
| Phương pháp | Trả lời câu hỏi | Loại dữ liệu |
|---|---|---|
| Usability test | Người dùng vướng ở đâu và vì sao | Định tính (quan sát hành vi) |
| A/B test | Phương án A hay B cho tỷ lệ chuyển đổi cao hơn | Định lượng (con số) |
| Heatmap | Người dùng bấm và cuộn tới đâu nhiều | Định lượng tổng hợp |
A/B test cần lưu lượng lớn và chỉ cho biết phương án nào thắng, không nói vì sao. Heatmap (bản đồ nhiệt) cho thấy vùng nóng nhưng không giải thích ý định. Usability test bù đúng chỗ thiếu đó: bạn ngồi xem một người thật loay hoay và hiểu được lý do. Nếu cần đào sâu hai phương pháp kia, xem cách A/B test trong thiết kế và đọc heatmap cho web.
Cần bao nhiêu người là đủ
Câu trả lời gây bất ngờ nhất với người mới: khoảng 5 người. Nielsen Norman Group chỉ ra rằng với một usability test định tính, năm người đầu tiên đã lộ ra phần lớn các vấn đề nghiêm trọng, và thêm người sau đó chủ yếu lặp lại những lỗi bạn đã thấy.
Lý do nằm ở quy luật lợi ích giảm dần: người thứ nhất cho bạn nhiều phát hiện, người thứ hai trùng một phần với người thứ nhất, càng về sau càng ít cái mới. Vài lưu ý quan trọng:
- Con số 5 chỉ đúng cho test định tính (quan sát người làm tác vụ), không áp cho test định lượng — loại đó NN/G khuyên cần khoảng 40 người để có ý nghĩa thống kê.
- Nếu sản phẩm phục vụ vài nhóm người rất khác nhau (ví dụ người bán và người mua), cần tối thiểu khoảng 3 người mỗi nhóm.
- Thà chạy nhiều đợt nhỏ 5 người, sửa giữa các đợt, còn hơn dồn một đợt 15 người rồi mới sửa.
Viết kịch bản tác vụ ra sao
Trái tim của usability test là tác vụ (task — việc cụ thể bạn nhờ người dùng làm). Một kịch bản tốt mô tả mục tiêu của người dùng, chứ không chỉ đường đi. Sai lầm phổ biến là vô tình chỉ luôn đáp án.
- Sai: “Bấm nút Giỏ hàng ở góc phải rồi chọn Thanh toán.” → Đây là tour hướng dẫn, không kiểm tra được gì.
- Đúng: “Bạn vừa chọn được một chiếc áo size M và muốn đặt mua. Hãy thực hiện đến lúc nhận xác nhận đơn.” → Cho mục tiêu, để người dùng tự mò đường.
Vài nguyên tắc khi viết kịch bản: đặt trong tình huống thực tế người dùng hay gặp; không gọi tên nút hay menu trong câu lệnh; giữ test ngắn (khoảng 3–5 tác vụ) để tránh người tham gia mệt và bỏ ngang; và chạy thử với một người trước (pilot) để bắt lỗi câu chữ trước khi mời người chính thức.
Quan sát gì khi người dùng làm
Trong lúc người dùng làm tác vụ, kỹ thuật nền tảng là think-aloud (nghĩ thành tiếng — đề nghị họ nói ra suy nghĩ khi thao tác). Bạn nghe được chỗ họ phân vân, kỳ vọng sai, hay không hiểu một nhãn. Những thứ đáng ghi lại:
- Chỗ họ dừng lại do dự, cuộn tới cuộn lui tìm thứ gì đó.
- Thao tác sai đường: bấm nhầm, đi lạc nhánh, quay lại.
- Câu hỏi tự bật ra: “Cái này là gì?”, “Bấm vào đâu giờ?”
- Tác vụ có hoàn thành được không, và mất bao lâu.
- Cảm xúc lộ ra: bực, ngạc nhiên, nhẹ nhõm.
Quy tắc khó nhất với người mới: đừng vội cứu. Khi người dùng bí, bản năng là chỉ liền. Nhưng chính lúc họ bí mới lộ ra vấn đề thiết kế. Chỉ can thiệp khi họ kẹt hẳn không nhúc nhích. Và đừng tự ái — bạn đang test giao diện, không phải test người dùng.
Moderated hay unmoderated
Hai cách tổ chức phổ biến, chọn theo mục tiêu và nguồn lực:
| Tiêu chí | Moderated (có người điều phối) | Unmoderated (tự làm, không người kèm) |
|---|---|---|
| Cách chạy | Bạn ngồi cùng (trực tiếp/online), dẫn dắt và hỏi sâu | Người dùng tự làm theo hướng dẫn ghi sẵn, công cụ thu lại |
| Hỏi thêm khi có tình huống lạ | Được, đào sâu ngay tại chỗ | Không, chỉ có dữ liệu định sẵn |
| Chi phí và tốc độ | Tốn hơn, chậm hơn, ít người | Rẻ hơn, nhanh hơn, nhiều người |
| Hợp với | Giai đoạn sớm, ý tưởng còn mơ hồ, cần hiểu “vì sao” | Deadline gấp, tác vụ rõ ràng, cần nhiều phản hồi |
Người mới nên bắt đầu với một buổi moderated nhỏ: tự ngồi xem 5 người làm, ghi chú, là đủ để mở mắt ra rất nhiều thứ mà bản thiết kế trên màn hình của bạn che mất.
Câu hỏi thường gặp
Usability test có cần phòng lab xịn không?
Không. Một cuộc gọi video chia sẻ màn hình, vài tác vụ rõ ràng và một người chịu khó ghi chú là đã chạy được. Quan trọng là chất lượng kịch bản và kỷ luật “không cứu”, không phải thiết bị.
5 người thì có đại diện cho hàng nghìn khách không?
Với mục tiêu tìm lỗi, 5 người là đủ vì lỗi nghiêm trọng lặp lại rất nhanh. Nếu mục tiêu là đo con số (tỷ lệ hoàn thành chính xác), bạn cần mẫu lớn hơn nhiều và nên dùng A/B test hoặc test định lượng.
Nên test khi nào, sớm hay muộn?
Càng sớm càng rẻ. Test ngay trên bản phác hoặc nguyên mẫu (prototype) tránh được việc code xong mới phát hiện cả luồng đi sai. Test cũng nên lặp lại sau mỗi lần sửa lớn.
Khi Web22 dựng giao diện cho web22.dev, các luồng quan trọng đều được cho người ngoài đội thử trước khi chốt — bản thiết kế đẹp trên Figma chưa chắc dễ dùng khi vào tay người thật. Nếu bạn cần một bộ giao diện vừa đẹp vừa được kiểm chứng qua người dùng, tham khảo dịch vụ thiết kế trải nghiệm người dùng của Web22.