Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa cùng team thiết kế một màn hình thanh toán mới cho ứng dụng đặt đồ ăn. Trên Figma, mọi thứ trông gọn gàng, đẹp mắt, ai trong phòng họp cũng gật gù. Nhưng khi sản phẩm lên thật, tỷ lệ bỏ giỏ hàng ở bước thanh toán lại tăng vọt. Câu hỏi nhức nhối là: vì sao một thiết kế ai cũng khen lại khiến người dùng bỏ đi?
Câu trả lời gần như luôn giống nhau: chúng ta thiết kế bằng trực giác của người đã hiểu sản phẩm quá rõ, còn người dùng thật thì gặp sản phẩm lần đầu với một bộ não hoàn toàn khác. Usability Testing (kiểm thử khả năng sử dụng) chính là cây cầu nối khoảng cách đó. Đây là phương pháp bạn đưa một người dùng thật ngồi trước sản phẩm, giao cho họ một nhiệm vụ cụ thể, rồi quan sát họ làm — không phải hỏi họ nghĩ gì, mà nhìn họ thật sự làm gì.
Trong toàn bộ khóa học này, Usability Testing là một trong những kỹ năng "xương sống" mà bất kỳ UX Researcher nào cũng phải thành thạo. Nó rẻ một cách đáng ngạc nhiên, cho ra insight nhanh, và có sức thuyết phục cực mạnh trong phòng họp — vì không gì làm một stakeholder im lặng nhanh bằng việc xem video một người dùng thật loay hoay không tìm ra nút "Đặt hàng". Bài này tập trung vào nền tảng của Usability Testing: nó là gì, ba hình thức chính (Moderated, Unmoderated, Guerrilla), và cách bạn tổ chức một buổi test từ đầu đến cuối. Các bài sau (14, 15) sẽ đào sâu hơn vào từng kỹ thuật moderated và unmoderated; ở đây chúng ta xây nền móng.
Khái niệm cốt lõi
Usability Testing thực sự là gì
Usability Testing là việc quan sát người dùng đại diện thực hiện các nhiệm vụ thực tế trên sản phẩm (hoặc bản prototype) để phát hiện những điểm gây khó khăn, nhầm lẫn hoặc thất bại. Điểm mấu chốt cần khắc cốt ghi tâm: bạn đang test sản phẩm, không phải test người dùng. Khi một người không tìm ra chức năng nào đó, đó là lỗi của thiết kế, không phải lỗi của họ.
Một định nghĩa kinh điển từ Jakob Nielsen: usability gồm năm thành tố — dễ học (learnability), hiệu quả (efficiency), dễ nhớ (memorability), ít lỗi (errors), và mức độ hài lòng (satisfaction). Usability Testing là cách trực tiếp nhất để đo cả năm.
Cần phân biệt rõ: usability test khác với phỏng vấn người dùng. Phỏng vấn hỏi về ý kiến, mong muốn, trải nghiệm trong quá khứ. Usability test thì im lặng quan sát hành vi trong hiện tại. Người dùng rất hay nói một đằng làm một nẻo — họ bảo "giao diện này dễ dùng lắm" trong khi vừa mất 90 giây mới tìm thấy nút bạn nghĩ là hiển nhiên. Hành vi mới là sự thật.
Ba hình thức chính
Moderated (có người điều phối). Một facilitator (người điều phối) ngồi cùng người dùng — trực tiếp hoặc qua video call — dẫn dắt buổi test, giao nhiệm vụ và đặt câu hỏi đào sâu khi cần. Ưu điểm lớn nhất là bạn có thể hỏi "Lúc nãy bạn dừng lại ở đây, bạn đang nghĩ gì vậy?" ngay khoảnh khắc nó xảy ra. Nhược điểm: tốn thời gian, khó tổ chức với số lượng lớn, và facilitator dễ vô tình "mớm" đáp án.
Unmoderated (không người điều phối). Người dùng tự làm một mình, thường qua các công cụ remote như Maze, UserTesting, Lookback hay PlaybookUX. Hệ thống ghi lại màn hình, giọng nói, đường di chuột. Ưu điểm: rẻ, nhanh, thu được nhiều người trong thời gian ngắn, người dùng tự nhiên hơn vì không bị ai nhìn. Nhược điểm: không thể hỏi sâu khi có điều bất ngờ xảy ra, và bạn phải viết hướng dẫn cực kỳ rõ ràng vì không ai ở đó để gỡ rối.
Guerrilla (du kích). Test nhanh, không chính thức, chi phí gần như bằng không. Bạn cầm điện thoại có prototype ra một quán cà phê, mời người lạ thử trong 5 phút đổi lấy ly nước. Ưu điểm: nhanh khủng khiếp, hợp giai đoạn đầu khi ý tưởng còn thô. Nhược điểm: người tham gia không được sàng lọc nên có thể không đại diện cho khách hàng thật, và môi trường ồn ào khó kiểm soát.
Bao nhiêu người là đủ
Đây là câu hỏi mọi người mới đều hỏi. Nghiên cứu nổi tiếng của Nielsen chỉ ra rằng chỉ cần 5 người dùng là bạn đã phát hiện được khoảng 85% các vấn đề về khả năng sử dụng. Lý do là các vấn đề usability có xu hướng trùng lặp: người thứ sáu, thứ bảy thường gặp lại đúng những lỗi mà năm người đầu đã bộc lộ. Vì vậy, thay vì test một lần với 20 người, hãy test ba vòng mỗi vòng 5 người, sửa giữa các vòng. Đó là tư duy "test nhỏ, lặp nhanh".
Think-aloud — kỹ thuật quan trọng nhất
Trong moderated test, kỹ thuật "think-aloud" (nghĩ thành tiếng) là vũ khí chính. Bạn yêu cầu người dùng nói ra mọi suy nghĩ trong lúc làm: "Tôi đang tìm nút giỏ hàng… ờ, nó ở đâu nhỉ… à chắc ở góc trên". Những câu lẩm bẩm này cho bạn thấy mô hình tư duy của họ — vì sao họ kỳ vọng nút ở chỗ này mà không ở chỗ kia.
Tình huống thực tế
Ví dụ 1 — Tiki và bài học từ 5 người dùng
Giả định một team sản phẩm tại một sàn thương mại điện tử lớn của Việt Nam (lấy bối cảnh kiểu Tiki) chuẩn bị ra mắt tính năng "mua lại đơn cũ" để người dùng đặt lại nhanh các sản phẩm đã từng mua. Team tự tin tính năng này quá rõ ràng nên định bỏ qua test. Một researcher đề nghị làm một buổi moderated test guerrilla nội bộ với chỉ 5 đồng nghiệp ở phòng ban khác (không phải dân thiết kế).
Kết quả gây sốc: 4 trong 5 người không tìm thấy nút "Mua lại" vì nó nằm sâu trong trang lịch sử đơn hàng, trong khi mọi người đều bản năng vào trang "Đơn của tôi" và mong nút nằm ngay cạnh từng đơn. Có người còn nhầm "Mua lại" với "Đánh giá lại sản phẩm". Buổi test kéo dài chưa tới một giờ.
Bài học: Chỉ 5 người và chưa tới một tiếng đồng hồ đã cứu team khỏi việc ship một tính năng mà người dùng không tìm ra. Đáng chú ý, vấn đề không phải là tính năng tồi mà là vị trí và cách đặt tên — những thứ chỉ lộ ra khi nhìn người thật thao tác.
Ví dụ 2 — Unmoderated test cho app gọi xe ở Đông Nam Á
Một startup gọi xe khu vực Đông Nam Á (bối cảnh kiểu Grab/Gojek) muốn thử nghiệm luồng đặt xe ghép (carpool) mới nhưng đội ngũ research mỏng, không đủ người để ngồi moderated từng buổi. Họ chọn unmoderated test qua công cụ Maze: tạo một prototype tương tác, viết 4 nhiệm vụ rõ ràng ("Hãy đặt một chuyến xe ghép từ điểm A đến điểm B với mức giá rẻ nhất"), rồi gửi link cho 30 người dùng đã sàng lọc qua màn hình screener.
Trong 48 giờ họ thu được 30 phiên ghi màn hình kèm dữ liệu định lượng: tỷ lệ hoàn thành nhiệm vụ chỉ 53%, và bản đồ nhiệt (heatmap) cho thấy nhiều người bấm nhầm vào nhãn "Tiết kiệm" tưởng đó là nút chọn, nhưng thực ra nó chỉ là chữ trang trí. Vì là unmoderated, họ không thể hỏi ngay "vì sao bạn bấm chỗ đó", nhưng số lượng lớn dữ liệu giúp họ tự tin rằng đây là vấn đề hệ thống chứ không phải cá biệt.
Bài học: Unmoderated mạnh ở quy mô và tốc độ. Khi bạn cần con số có sức nặng để thuyết phục và không có điều kiện ngồi cùng từng người, đây là lựa chọn tối ưu — miễn là nhiệm vụ được viết đủ rõ để người dùng tự xoay xở.
Ví dụ 3 — Guerrilla test ở quán cà phê cho một fintech
Một nhóm sinh viên làm sản phẩm ví điện tử trong một cuộc thi khởi nghiệp ở TP.HCM không có ngân sách thuê người tham gia. Họ áp dụng guerrilla test: ra một quán cà phê đông sinh viên, mời 8 người lạ thử prototype luồng "nạp tiền vào ví" trong 5 phút, đổi lại một phiếu giảm giá đồ uống.
Họ phát hiện ngay rằng từ "Top-up" (giữ nguyên tiếng Anh trên nút) khiến nhiều bạn bối rối — không chắc nó là nạp tiền hay rút tiền. Khi đổi thành "Nạp tiền vào ví", người sau đó thao tác trơn tru hơn hẳn. Toàn bộ buổi test tốn khoảng 200 nghìn đồng tiền nước.
Bài học: Guerrilla test không cho dữ liệu hoàn hảo, nhưng ở giai đoạn ý tưởng còn thô, nó cực kỳ đáng giá. Đặc biệt với bối cảnh Việt Nam, những lỗi về ngôn ngữ (thuật ngữ tiếng Anh người dùng không hiểu) thường lộ ra cực nhanh qua kiểu test này.
Hướng dẫn từng bước
Bước 1 — Xác định mục tiêu test. Trước khi làm gì, hãy viết ra một câu: "Tôi muốn biết liệu người dùng có thể ___ hay không". Ví dụ: "liệu người dùng có thể tự hoàn tất thanh toán bằng QR code trong lần đầu". Mục tiêu rõ thì test mới có hướng.
Bước 2 — Chọn hình thức phù hợp. Giai đoạn ý tưởng thô, cần nhanh và rẻ → Guerrilla. Cần hiểu sâu "vì sao" → Moderated. Cần số liệu quy mô và đã có prototype tương tác → Unmoderated. Đừng dùng dao mổ trâu để giết gà.
Bước 3 — Viết kịch bản nhiệm vụ (task scenario). Mỗi nhiệm vụ phải là một tình huống thực tế, có ngữ cảnh, và không tiết lộ đáp án. Sai: "Hãy bấm vào nút Giỏ hàng ở góc trên". Đúng: "Bạn vừa chọn xong một đôi giày và muốn xem lại những món đang định mua trước khi trả tiền". Nhiệm vụ thứ hai để người dùng tự tìm đường, đó mới là điều bạn cần quan sát.
Bước 4 — Tuyển người tham gia. Chọn người càng giống khách hàng thật càng tốt. Với moderated/unmoderated, dùng screener survey để lọc (sẽ học kỹ ở Bài 8). Với guerrilla thì linh hoạt hơn nhưng vẫn nên nhắm đúng nhóm — đừng test app cho người cao tuổi bằng cách hỏi sinh viên.
Bước 5 — Chạy buổi test. Mở đầu bằng việc trấn an: "Hôm nay chúng ta test sản phẩm chứ không test bạn, không có câu trả lời đúng sai, bạn cứ thoải mái". Với moderated, nhắc người dùng nghĩ thành tiếng. Khi họ bí, kìm nén bản năng muốn giúp — hãy đếm thầm vài giây và hỏi "Bạn đang nghĩ gì lúc này?" thay vì chỉ chỗ.
Bước 6 — Ghi nhận và tổng hợp. Ghi lại: tỷ lệ hoàn thành nhiệm vụ, thời gian, số lần nhầm, và quan trọng nhất là những khoảnh khắc người dùng do dự hay bực bội. Sau đó nhóm các vấn đề lại, xếp theo mức độ nghiêm trọng (severity), và đề xuất hướng sửa.
Lỗi thường gặp & mẹo
Lỗi: Mớm đáp án cho người dùng. Đây là lỗi phổ biến nhất của người mới điều phối. Câu "Bạn thử nhìn lên góc phải xem" giết chết toàn bộ giá trị của buổi test. Mẹo: trước buổi test, tự nhắc mình quy tắc "im lặng là vàng" — để khoảng lặng kéo dài hơn bạn thấy thoải mái.
Lỗi: Hỏi câu dẫn dắt (leading question). "Nút này dễ thấy đúng không?" sẽ luôn nhận được cái gật đầu lịch sự. Hãy hỏi trung lập: "Bạn vừa làm gì ở bước đó?" hoặc "Bạn kỳ vọng điều gì sẽ xảy ra khi bấm vào đây?".
Lỗi: Tin vào lời nói hơn hành vi. Khi người dùng khen "đẹp, dễ dùng" nhưng vừa mất 2 phút mới làm xong, hãy tin vào 2 phút đó. Hành vi không biết nói dối.
Lỗi: Viết nhiệm vụ quá dài hoặc nhồi nhét. Một buổi test nên có 3–5 nhiệm vụ, mỗi cái đủ ngắn để hoàn thành trong vài phút. Quá nhiều sẽ làm người dùng mệt và dữ liệu cuối buổi kém chất lượng.
Mẹo: Luôn làm pilot test. Trước buổi chính, chạy thử với một đồng nghiệp để phát hiện nhiệm vụ viết mơ hồ, prototype lỗi, hay câu hỏi khó hiểu. Một pilot 15 phút tiết kiệm cho bạn cả buổi test hỏng.
Mẹo: Ghi hình lại (có xin phép). Một đoạn clip 30 giây người dùng loay hoay có sức thuyết phục stakeholder mạnh hơn mười trang báo cáo chữ.
Bài tập thực hành
- Viết task scenario. Chọn một app bạn đang dùng (ví dụ MoMo, Shopee, hay Zalo). Viết 3 task scenario theo đúng nguyên tắc ở Bước 3: có ngữ cảnh thực tế, không tiết lộ đáp án. So sánh với phiên bản "sai" để thấy khác biệt.
- Chạy một guerrilla test mini. Nhờ 3 người quen (không làm cùng ngành thiết kế) thử một trong các nhiệm vụ bạn vừa viết. Yêu cầu họ nghĩ thành tiếng. Bạn chỉ quan sát và im lặng, ghi lại mọi khoảnh khắc họ do dự.
- Tổng hợp. Sau khi test, liệt kê các vấn đề tìm được, đánh số mức độ nghiêm trọng từ 1 (vặt vãnh) đến 4 (chặn hoàn toàn việc hoàn thành nhiệm vụ), và viết một đề xuất sửa cho vấn đề nghiêm trọng nhất.
- Tự phản tư. Bạn có vô tình mớm đáp án hay hỏi câu dẫn dắt nào không? Ghi lại để rút kinh nghiệm cho lần sau.
Tóm tắt
Usability Testing là việc quan sát người dùng thật thực hiện nhiệm vụ thật để phát hiện điểm khó trong sản phẩm — bạn test sản phẩm, không test người dùng. Có ba hình thức chính: Moderated (có người điều phối, hiểu sâu "vì sao"), Unmoderated (tự làm qua công cụ remote, mạnh về quy mô và tốc độ), và Guerrilla (nhanh, rẻ, hợp giai đoạn ý tưởng thô). Chỉ cần 5 người là đã lộ ra phần lớn vấn đề, nên hãy test nhỏ và lặp nhanh thay vì làm một lần thật lớn.
Quy trình gồm: xác định mục tiêu, chọn hình thức, viết task scenario không tiết lộ đáp án, tuyển đúng người, chạy buổi test với kỹ thuật think-aloud, rồi tổng hợp theo mức độ nghiêm trọng. Tránh các bẫy kinh điển như mớm đáp án, hỏi câu dẫn dắt, và tin lời nói hơn hành vi. Như ba ví dụ đã thấy — từ sàn thương mại điện tử, app gọi xe đến ví điện tử của sinh viên — sức mạnh của Usability Testing nằm ở chỗ nó rẻ, nhanh, và cho bạn bằng chứng không thể chối cãi về cách người dùng thật sự trải nghiệm sản phẩm của bạn.