Mở đầu — vì sao bài này quan trọng
Hãy hình dung tình huống này: bạn dành ba tuần thu thập yêu cầu, viết user story chi tiết, vẽ wireframe đẹp, dev code xong, QA test pass hết. Mọi người ăn mừng. Rồi sản phẩm lên production và bộ phận chăm sóc khách hàng ngập trong ticket: "Tôi không tìm thấy nút thanh toán", "Form báo lỗi mà không biết sửa thế nào", "Không hiểu bước tiếp theo phải làm gì". Tất cả requirement đều đúng — nhưng người dùng vẫn không dùng được.
Đây chính là khoảng trống mà usability testing (kiểm thử khả năng sử dụng) lấp đầy. Trong vai trò BA, bạn không chỉ chịu trách nhiệm "phần mềm làm đúng những gì đã định nghĩa" (đó là việc của QA — verification). Bạn còn phải trả lời câu hỏi sâu hơn: "liệu thứ chúng ta định nghĩa có thực sự giúp người dùng hoàn thành công việc của họ không?" (validation). Usability testing là công cụ rẻ nhất, nhanh nhất để bạn validate điều đó trước khi đổ tiền vào phát triển — hoặc để chứng minh một giả định sai đang ẩn náu trong requirement.
Điểm quan trọng cần phân biệt ngay: bài này không dạy bạn làm prototyping (Bài 31–33 lo việc tạo bản mẫu), cũng không phải usability testing kiểu nghiên cứu UX hàn lâm. Đây là protocol — quy trình chuẩn, nhẹ, lặp lại được — để một BA tự chạy được một buổi usability test, thu thập bằng chứng hành vi thật, và biến nó thành yêu cầu được điều chỉnh. Bạn không cần là chuyên gia UX research mới làm được; bạn cần một quy trình kỷ luật.
Khái niệm cốt lõi
Usability testing là gì và không phải là gì
Usability testing là việc quan sát người dùng thật cố gắng hoàn thành các tác vụ thật trên sản phẩm (hoặc prototype), trong khi bạn ghi nhận họ vấp ở đâu, bối rối chỗ nào, và hiểu sai điều gì. Trọng tâm là hành vi, không phải ý kiến. Người dùng nói "giao diện này đẹp đấy" không có giá trị bằng việc bạn thấy họ click nhầm ba lần mới tìm ra nút Đăng xuất.
Nó khác với những thứ dễ nhầm:
- Không phải khảo sát (survey): survey hỏi người dùng nghĩ gì; usability test xem họ làm gì.
- Không phải A/B testing: A/B test đo định lượng trên số đông để biết phương án nào thắng; usability test đào sâu định tính trên số ít để biết tại sao người dùng vấp.
- Không phải UAT: UAT (Bài 57) là nghiệm thu xem hệ thống có đáp ứng yêu cầu nghiệp vụ không, do người dùng nghiệp vụ thực hiện gần cuối dự án. Usability test có thể chạy rất sớm, ngay trên giấy.
Quy tắc "5 người dùng" của Jakob Nielsen
Nguyên tắc nổi tiếng nhất trong lĩnh vực này đến từ Jakob Nielsen: chỉ cần 5 người tham gia là bạn đã phát hiện khoảng 80–85% lỗi usability của một giao diện. Lý do toán học: nếu mỗi lỗi có xác suất khoảng 31% bị một người dùng bất kỳ gặp phải, thì sau 5 người, hầu hết lỗi nghiêm trọng đã lộ ra ít nhất một lần. Người thứ 6, 7, 8 chủ yếu lặp lại những gì bạn đã biết — lợi ích biên giảm dần rất nhanh.
Hệ quả thực tế cho BA: thay vì test 15 người một lần rồi sửa, hãy test 5 người, sửa, rồi test 5 người khác trên bản đã sửa. Hai vòng nhỏ luôn tốt hơn một vòng lớn, vì bạn bắt được cả lỗi mới sinh ra sau khi sửa. Con số thực dụng cho BA Việt Nam: 5–8 người mỗi vòng, khớp với đúng persona mục tiêu.
Bốn thành phần của một protocol
Một usability test protocol nghiêm túc luôn có bốn phần. Thiếu một phần là buổi test mất giá trị bằng chứng:
- Participants (người tham gia): phải khớp persona thật. Test app cho tiểu thương bán hàng online mà mời nhân viên IT vào test thì kết quả vô nghĩa.
- Tasks (tác vụ): 3–7 kịch bản đại diện cho những việc quan trọng nhất user phải làm. Viết dưới dạng mục tiêu, không phải hướng dẫn từng bước.
- Metrics (chỉ số): cách bạn đo "có dùng được không" một cách khách quan.
- Facilitation protocol (quy tắc điều phối): cách bạn hỏi, im lặng, và không gợi ý, để không làm nhiễu kết quả.
Các chỉ số usability cần biết
BA không cần đo phức tạp, nhưng nên nắm bốn chỉ số cốt lõi:
- Task success rate — tỷ lệ hoàn thành tác vụ. Phân loại: thành công hoàn toàn / thành công có vấp / thất bại. Đây là chỉ số quan trọng nhất.
- Time on task — thời gian hoàn thành. Hữu ích khi so sánh giữa các vòng test hoặc các phương án thiết kế.
- Error rate — số lần click sai, đi nhầm đường, nhập sai.
- SEQ (Single Ease Question) — sau mỗi tác vụ, hỏi một câu: "Tác vụ vừa rồi dễ hay khó?" trên thang 1–7. Cực rẻ mà cực giá trị.
Moderated vs Unmoderated
- Moderated (có điều phối): bạn ngồi cùng (trực tiếp hoặc qua Zoom/Meet), quan sát, đặt câu hỏi đào sâu. Sâu, linh hoạt, nhưng tốn thời gian.
- Unmoderated (không điều phối): người dùng tự làm task qua công cụ như Maze, UserTesting, Lookback, hệ thống ghi lại màn hình. Rẻ, nhanh, chạy số đông, nhưng không hỏi sâu được.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT thời trang ở TP.HCM phát hiện giả định sai
Một startup TMĐT thời trang (gọi là StyleVN) chuẩn bị tung tính năng "phối đồ AI": người dùng chọn một món rồi hệ thống gợi ý cả set. BA viết requirement cẩn thận, dev đã code 70%. Trước khi hoàn thiện, BA quyết định chạy một usability test trên prototype Figma với 6 người dùng là nữ 22–30 tuổi mua sắm online thường xuyên — đúng persona.
Tác vụ: "Bạn vừa thích chiếc váy này, hãy tìm cách xem các món đi kèm để có một bộ hoàn chỉnh." Kết quả gây sốc: 5/6 người không nhận ra nút "Phối đồ AI" vì nó nằm dưới phần mô tả sản phẩm, lẫn vào các nút chia sẻ. Họ cuộn qua, bỏ lỡ, và tự đi tìm món khác thủ công. SEQ trung bình chỉ 2.8/7.
Bài học: requirement không sai về chức năng, nhưng sai về vị trí và mức độ nổi bật, một thứ không bao giờ lộ ra trong tài liệu. BA cập nhật acceptance criteria: nút phối đồ phải nằm ngay cạnh nút "Thêm vào giỏ", có nhãn rõ "Xem set đồ gợi ý". Vòng test thứ hai với 5 người khác: tỷ lệ phát hiện nút lên 5/5, SEQ 6.2/7. Chi phí: hai buổi chiều và vài chục nghìn đồng tiền cà phê cảm ơn người tham gia — rẻ hơn nhiều so với việc tính năng flop sau khi launch.
Ví dụ 2 — Ngân hàng số và bẫy "test với chính nhân viên"
Một ngân hàng số tại Việt Nam làm lại luồng mở tài khoản tiết kiệm trên app. Đội đầu tiên test nội bộ: mời 8 nhân viên phòng sản phẩm thử luồng. Ai cũng làm được trong 90 giây, kết luận "ngon, deploy". Sau khi lên production, tỷ lệ bỏ dở (drop-off) ở bước nhập kỳ hạn lên tới 41%.
BA mới vào dự án nghi ngờ và tổ chức một usability test đúng chuẩn: 7 khách hàng thật, độ tuổi 35–55, không rành công nghệ — đúng nhóm khách hàng tiết kiệm chủ lực. Phát hiện: trường "kỳ hạn" hiển thị dạng "3M / 6M / 12M". Nhân viên hiểu ngay là tháng, nhưng 4/7 khách hàng tưởng M là... triệu đồng, hoặc bối rối không dám chọn. Hai người bỏ luôn giữa chừng.
Bài học rút ra có hai tầng. Thứ nhất: không bao giờ test với người quá quen sản phẩm — họ đã bị "lời nguyền kiến thức" (curse of knowledge), mắt họ tự lấp đầy chỗ trống mà khách hàng thật vấp phải. Thứ hai: lỗi usability thường nằm ở ngôn ngữ và ký hiệu, thứ mà BA rất dễ bỏ qua khi viết requirement. Đội sửa nhãn thành "3 tháng / 6 tháng / 12 tháng" và thêm gợi ý lãi suất tương ứng; drop-off giảm còn 12% trong tháng sau.
Ví dụ 3 — Think-aloud cứu một form đăng ký SaaS
Một công ty SaaS B2B ở Singapore phục vụ doanh nghiệp SME Đông Nam Á có form onboarding 4 bước. Số liệu analytics cho thấy nhiều người dừng ở bước 2 nhưng không biết tại sao — đây là lúc usability test phát huy, vì analytics cho biết "ở đâu" còn usability test cho biết "tại sao".
BA chạy moderated test với 5 chủ doanh nghiệp SME, áp dụng kỹ thuật think-aloud (nghĩ thành lời): yêu cầu người dùng nói ra suy nghĩ trong lúc thao tác. Ở bước 2, một người lẩm bẩm: "Mã số thuế à... mình đang ở văn phòng, giấy tờ ở nhà, giờ phải bỏ ngang sao?". Đây là khoảnh khắc vàng — một câu nói tiết lộ rằng yêu cầu mã số thuế ngay tại onboarding là rào cản, không phải lỗi giao diện.
Bài học: think-aloud biến những vấp váp im lặng thành lý do rõ ràng. BA đề xuất chuyển trường mã số thuế thành tùy chọn "điền sau", có thể bổ sung khi tạo hóa đơn đầu tiên. Tỷ lệ hoàn thành onboarding tăng từ 58% lên 79%. Không một dòng requirement nào "sai" — chỉ là thứ tự thu thập thông tin chưa khớp với hoàn cảnh thật của người dùng.
Hướng dẫn từng bước
Đây là quy trình 7 bước để bạn tự chạy một usability test với tư cách BA:
Bước 1 — Xác định mục tiêu test. Viết một câu rõ ràng: "Tôi muốn biết liệu người dùng có hoàn thành được [tác vụ X] mà không cần trợ giúp không." Mục tiêu càng hẹp, kết quả càng dùng được. Đừng test "cả app" trong một buổi.
Bước 2 — Tuyển 5–8 người đúng persona. Bám sát persona đã định nghĩa (Bài 42). Tuyển qua khách hàng hiện có, nhóm Facebook ngành, hoặc dịch vụ tuyển panel. Loại tuyệt đối: đồng nghiệp, người nhà, người đã biết sản phẩm. Chuẩn bị một sàng lọc nhanh (screener) 3–4 câu để xác nhận họ đúng nhóm.
Bước 3 — Viết 3–7 task scenario. Viết dưới dạng mục tiêu thực tế, có ngữ cảnh, không chứa từ khóa trên giao diện. Sai: "Click nút Thanh toán rồi chọn Momo". Đúng: "Bạn đã chọn xong hàng và muốn trả bằng ví điện tử, hãy hoàn tất đơn." Ưu tiên task theo mức độ quan trọng và rủi ro.
Bước 4 — Chuẩn bị metrics và kịch bản điều phối. Tạo một bảng ghi: mỗi task một dòng, cột success/vấp/fail, cột time, cột SEQ, cột ghi chú quote. Viết sẵn lời mở đầu trấn an: "Chúng tôi test sản phẩm chứ không test bạn, không có câu trả lời sai, bạn cứ làm tự nhiên và nói to suy nghĩ giúp tôi."
Bước 5 — Chạy buổi test. Mỗi người 30–45 phút. Bật think-aloud. Vàng nhất là kỷ luật im lặng: khi người dùng vấp, đừng cứu. Đếm thầm tới 10. Nếu họ hỏi "nút này ở đâu?", trả lời bằng câu hỏi: "Bạn nghĩ nó nên ở đâu?". Ghi lại quote nguyên văn — câu nói thật giá trị hơn mọi diễn giải của bạn.
Bước 6 — Tổng hợp phát hiện. Ngay sau mỗi buổi, viết note nóng. Cuối vòng, gom các vấn đề, đếm tần suất (mấy người gặp), xếp mức nghiêm trọng: nghiêm trọng (chặn hoàn thành task) / vừa (gây chậm, bực) / nhẹ (thẩm mỹ). Dùng affinity mapping (Bài 24) nếu nhiều dữ liệu.
Bước 7 — Chuyển phát hiện thành requirement. Đây là phần BA tạo ra giá trị thật. Mỗi vấn đề nghiêm trọng phải biến thành một thay đổi cụ thể: cập nhật acceptance criteria, sửa user story, hoặc tạo defect. Gắn bằng chứng (quote, số liệu success rate) để thuyết phục stakeholder và dev.
Lỗi thường gặp & mẹo
Lỗi 1 — Test với sai người. Mời đồng nghiệp hoặc người nhà cho "tiện". Như ví dụ ngân hàng, điều này che giấu mọi lỗi thật. Mẹo: thà ít người đúng persona còn hơn nhiều người sai persona.
Lỗi 2 — Gợi ý, dẫn dắt, "cứu" người dùng. BA hay sốt ruột khi thấy người ta vấp, buột miệng chỉ chỗ. Mỗi lần bạn gợi ý là một bằng chứng bị xóa. Mẹo: ngồi lùi lại, tay rời chuột, học cách chịu đựng sự im lặng.
Lỗi 3 — Viết task chứa từ khóa trên màn hình. "Hãy bấm nút Xác nhận" biến bài test thành bài tìm chữ, không phải test khả năng hiểu luồng. Mẹo: dùng ngôn ngữ của người dùng, mô tả mục tiêu, không nhắc nhãn UI.
Lỗi 4 — Hỏi ý kiến thay vì quan sát hành vi. "Bạn có thích giao diện này không?" cho ra câu trả lời lịch sự vô dụng. Mẹo: thay câu hỏi ý kiến bằng task quan sát; lịch sự là kẻ thù của dữ liệu trung thực.
Lỗi 5 — Test quá muộn. Đợi code xong mới test thì sửa rất đắt. Mẹo: test trên prototype giấy hoặc Figma càng sớm càng tốt — lúc đó sửa một mũi tên rẻ hơn refactor code gấp trăm lần.
Lỗi 6 — Không kết nối phát hiện với requirement. Chạy test rất hay rồi báo cáo "vui vui" mà không ai sửa gì. Mẹo: mọi vấn đề nghiêm trọng phải gắn với một hành động cụ thể trong backlog, có người chịu trách nhiệm.
Mẹo bonus — Mời stakeholder và dev ngồi quan sát. Một dev xem trực tiếp khách hàng vấp ở nút mình code sẽ tự nguyện sửa, không cần bạn tranh luận. Quan sát trực tiếp thuyết phục mạnh hơn mọi báo cáo.
Bài tập thực hành
Hãy thực hành trên một app bạn quen (ví dụ một app đặt đồ ăn hoặc ví điện tử bạn đang dùng):
- Viết mục tiêu test trong một câu cho luồng "thanh toán đơn hàng đầu tiên".
- Soạn 3 task scenario đúng chuẩn: có ngữ cảnh, không chứa từ khóa trên giao diện. Tự kiểm: nếu task của bạn chứa đúng tên nút trên app, hãy viết lại.
- Thiết kế bảng ghi metrics với các cột: Task / Success-Vấp-Fail / Time / SEQ (1–7) / Quote. Chuẩn bị cho 5 người.
- Tuyển 1 người thật (không phải dân IT, không quen app) và chạy thử một buổi 20 phút với think-aloud. Ghi lại ít nhất 3 quote nguyên văn và 2 điểm vấp.
- Chuyển 1 phát hiện nghiêm trọng thành acceptance criteria mới theo định dạng "Given/When/Then" hoặc một dòng yêu cầu rõ ràng, kèm bằng chứng (quote + số người gặp).
Tóm tắt
- Usability testing là cách rẻ và nhanh nhất để BA validate rằng yêu cầu không chỉ đúng mà còn dùng được, trọng tâm là quan sát hành vi chứ không phải hỏi ý kiến.
- Quy tắc Nielsen: 5 người đủ tìm ~80% lỗi; chiến lược tối ưu là test 5–8 người, sửa, rồi test vòng tiếp theo.
- Một protocol đủ bốn phần: participants đúng persona, 3–7 task theo mục tiêu, metrics khách quan (success rate, time, error, SEQ), và kỷ luật điều phối (think-aloud, im lặng, không gợi ý).
- Lỗi chết người nhất: test với người quá quen sản phẩm và tự "cứu" người dùng khi họ vấp — cả hai đều xóa sạch bằng chứng.
- Giá trị thật của BA nằm ở bước cuối: biến mỗi phát hiện nghiêm trọng thành một thay đổi cụ thể trong requirement/backlog, có bằng chứng kèm theo.