Kiểm thử khả năng sử dụng không cần phòng lab: hướng dẫn cho người mới bắt đầu

Bởi Đội ngũ FabricLoop  ·  Tháng 5 năm 2026  ·  4 phút đọc

Kiểm thử khả năng sử dụng mang tiếng oan là tốn kém và chậm chạp. Nghe đến "nghiên cứu người dùng", người ta hình dung ra một tấm gương một chiều, một người điều phối cầm bảng kẹp giấy, và lịch trình hai tuần. Kiểu kiểm thử đó có tồn tại và có công dụng riêng — nhưng không phải thứ mà phần lớn các nhóm sản phẩm cần trong phần lớn thời gian.

Thứ mà hầu hết các nhóm cần đơn giản hơn nhiều: năm người dùng, một prototype Figma hoặc môi trường staging, một cuộc gọi video, và 45 phút mỗi buổi. Làm tốt, cách này phát hiện được phần lớn các vấn đề nghiêm trọng về khả năng sử dụng trước khi sản phẩm phát hành. Làm đều đặn — dù chỉ một lần mỗi sprint — nó tạo ra mức cải thiện chất lượng sản phẩm tích lũy mà không công cụ phân tích sau khi ra mắt nào làm được.

Dưới đây là cách làm từ đầu.

Buổi kiểm thử gồm bốn bước

Bước 1: Tuyển người tham gia — kiểm thử với ai quan trọng hơn kiểm thử với bao nhiêu người

Năm người tham gia là con số phù hợp cho hầu hết các buổi kiểm thử khả năng sử dụng. Nghiên cứu của Jakob Nielsen cho thấy năm người dùng phát hiện khoảng 85% vấn đề về khả năng sử dụng, và sau đó hiệu quả tăng thêm giảm dần. Tiến hành ba buổi với năm người dùng ở các thời điểm khác nhau trong quá trình thiết kế có giá trị hơn một buổi với mười lăm người.

Tiêu chí tuyển chọn quan trọng hơn số lượng. Một buổi kiểm thử với năm người sát với người dùng mục tiêu sẽ cho thấy những vấn đề thật. Một buổi với mười lăm người không phù hợp chỉ tạo ra nhiễu. Hãy 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 độ quen thuộc với công nghệ — và giữ vững chúng.

Cách tuyển nhanh nhất với hầu hết các nhóm là gửi email cho những người dùng hiện có đã đồng ý được liên hệ. Hãy tặng một phần thưởng vừa phải — thẻ quà tặng £20 là đủ cho buổi 45 phút. Hãy cố gắng xếp lịch các buổi trong cùng một tuần; khoảng cách giữa lúc tuyển và lúc kiểm thử càng dài, tỷ lệ vắng mặt càng cao.

Bước 2: Kịch bản — tình huống, không phải chỉ dẫn

Lỗi phổ biến nhất khi viết kịch bản là viết tác vụ dưới dạng chỉ dẫn: "Nhấp vào Cài đặt, sau đó vào Thông báo, và đổi tùy chọn của bạn thành..." Cách này nói cho người dùng biết phải làm gì, nghĩa là bạn đang kiểm tra xem họ có làm theo được chỉ dẫn không, chứ không phải giao diện có trực quan hay không.

Thay vào đó, hãy viết tác vụ dưới dạng tình huống: "Hãy tưởng tượng bạn đang nhận quá nhiều thông báo và chỉ muốn nhận cảnh báo khi có người nhắc trực tiếp đến bạn. Hãy cho tôi xem bạn sẽ làm thế nào." Cách này cho người dùng một mục tiêu thực tế và giúp bạn quan sát cách họ thực sự thao tác — kể cả chỗ họ bị rối.

Bước 3: Tiến hành — việc của bạn là quan sát, không phải giúp đỡ

Phần khó nhất khi điều phối một buổi kiểm thử khả năng sử dụng là cưỡng lại thôi thúc muốn giúp. Khi người dùng bối rối, mọi bản năng đều bảo bạn nhảy vào chỉ cho họ nhấp ở đâu. Nhưng chính sự bối rối là dữ liệu. Một người dùng đang loay hoay đang cho bạn biết giao diện có điều gì đó không ổn — và ngay khi bạn can thiệp, bạn đánh mất tín hiệu đó.

Hãy đề nghị người dùng nói ra suy nghĩ suốt buổi: "Trong lúc làm, bạn cứ nói cho tôi biết bạn đang nhìn gì và đang nghĩ gì nhé." Cách này tạo ra dòng dữ liệu liên tục về mô hình tư duy của họ. Hãy ghi lại không chỉ lỗi mà cả những lần ngập ngừng — người dùng dừng ba giây trước khi nhấp đúng nút vẫn đã cho thấy một vấn đề thiết kế, dù cuối cùng họ vẫn thành công.

Bước 4: Tổng hợp — mẫu hình, không phải trích dẫn

Bước tổng hợp là nơi tạo ra phần lớn giá trị — và cũng là nơi hầu hết các nhóm làm tắt. Ghi chú thô từ năm buổi chưa phải là phát hiện. Chúng chỉ trở thành phát hiện khi cả nhóm cùng debrief, gom các quan sát theo chủ đề và gán mức độ nghiêm trọng.

Hãy debrief ngay trong ngày diễn ra các buổi kiểm thử, khi quan sát còn mới. Chia các vấn đề thành ba nhóm: nghiêm trọng (người dùng không thể hoàn thành tác vụ), trung bình (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ẹ (trở ngại không ngăn việc hoàn thành). Vấn đề nghiêm trọng cần được sửa trước khi phát hành. Vấn đề trung bình nên được ưu tiên vào sprint tiếp theo. Vấn đề nhẹ đưa vào backlog.

Hãy viết các phát hiện trong một trang: ba vấn đề nghiêm trọng hàng đầu, mỗi vấn đề có bằng chứng từ ít nhất hai người tham gia, kèm đề xuất thay đổi thiết kế cho từng vấn đề. Bất cứ điều gì cần nhiều chỗ hơn thế nên để trong một tài liệu riêng.