Mở đầu — vì sao bài này quan trọng
Có một tình huống mà gần như nhà nghiên cứu UX nào cũng từng rơi vào: sếp hoặc Product Manager chạy đến bàn bạn và nói "Anh cần em nghiên cứu người dùng gấp trong tuần này". Câu hỏi mà một người làm nghề non tay sẽ hỏi ngay là "Nghiên cứu bằng phương pháp gì?". Nhưng câu hỏi mà một chuyên gia thực thụ sẽ hỏi trước tiên lại là: "Chúng ta đang cố khám phá điều chưa biết, hay đang cố kiểm chứng một thứ đã có?".
Đây chính là trục phân loại nền tảng nhất trong toàn bộ nghề nghiên cứu UX: sự khác biệt giữa Generative Research (nghiên cứu tạo sinh — để khám phá) và Evaluative Research (nghiên cứu đánh giá — để kiểm chứng). Nếu bạn xác định sai loại ngay từ đầu, thì mọi thứ phía sau — chọn phương pháp, chọn người tham gia, viết câu hỏi, phân tích dữ liệu — đều lệch theo. Bạn có thể chạy một buổi usability test rất chỉn chu nhưng lại trả lời sai câu hỏi kinh doanh, hoặc phỏng vấn sâu 15 người rất tốn kém nhưng cuối cùng chỉ để xác nhận một nút bấm có dễ dùng hay không — một việc lẽ ra chỉ cần 5 người là đủ.
Bài học này không dạy bạn từng phương pháp cụ thể (các phương pháp như phỏng vấn sâu, contextual inquiry, A/B testing, card sorting sẽ được đào sâu ở các bài riêng). Ở đây, chúng ta học tư duy phân loại — cái la bàn giúp bạn quyết định khi nào dùng loại nghiên cứu nào, và quan trọng hơn, làm sao để khớp loại nghiên cứu với đúng giai đoạn của vòng đời sản phẩm.
Khái niệm cốt lõi
Generative Research — nghiên cứu để khám phá
Generative Research (đôi khi gọi là discovery research hoặc foundational research) tồn tại để trả lời những câu hỏi mở, khi bạn chưa biết vấn đề thật sự là gì.
- Mục đích: khám phá, làm lộ ra vấn đề, nhu cầu, hành vi và bối cảnh chưa biết của người dùng.
- Giai đoạn (phase): diễn ra trước khi bạn có giải pháp, hoặc trước khi bạn cam kết vào một hướng đi cụ thể.
- Câu hỏi điển hình: "Người dùng đang thực sự gặp khó khăn gì?", "Họ đang làm việc này như thế nào ngoài đời thật?", "Có nhu cầu nào chưa được đáp ứng mà chúng ta chưa nhìn thấy?".
- Output (đầu ra): insight (sự thấu hiểu sâu), jobs-to-be-done (công việc người dùng cần hoàn thành), các opportunity (cơ hội), pain points, personas, journey map ở dạng khám phá.
- Tính chất dữ liệu: thường là định tính, số lượng người tham gia ít nhưng đào sâu. Bạn tìm ý tưởng và giả thuyết mới, không tìm con số thống kê.
Evaluative Research — nghiên cứu để kiểm chứng
Evaluative Research tồn tại để trả lời câu hỏi: "Thứ chúng ta đang làm/đã làm có tốt không?".
- Mục đích: đánh giá, đo lường, kiểm chứng một giải pháp, thiết kế hoặc giả thuyết đã có sẵn.
- Giai đoạn: diễn ra khi đã có một bản thiết kế, prototype, hoặc sản phẩm đang chạy.
- Câu hỏi điển hình: "Người dùng có hoàn thành được tác vụ này không?", "Phiên bản A hay B chuyển đổi tốt hơn?", "Thiết kế mới có làm giảm lỗi so với thiết kế cũ không?".
- Output: điểm usability, tỷ lệ thành công của tác vụ (task success rate), thời gian hoàn thành, danh sách lỗi cần sửa, quyết định go/no-go.
- Tính chất dữ liệu: có thể định tính (usability test 5 người) hoặc định lượng (A/B test hàng nghìn người), nhưng luôn hướng tới phán xét một thứ cụ thể.
Trục thời gian: Double Diamond giúp bạn định vị
Cách dễ nhất để không nhầm là gắn hai loại nghiên cứu vào mô hình Double Diamond:
- Kim cương thứ nhất (Discover → Define): đây là lãnh địa của Generative. Bạn phân kỳ để khám phá vấn đề, rồi hội tụ để định nghĩa vấn đề đúng.
- Kim cương thứ hai (Develop → Deliver): đây là lãnh địa của Evaluative. Bạn phân kỳ để tạo giải pháp, rồi hội tụ bằng cách test và tinh chỉnh.
Bảng đối chiếu nhanh
| Tiêu chí | Generative | Evaluative |
|---|---|---|
| Mục đích | Khám phá vấn đề | Kiểm chứng giải pháp |
| Khi nào | Trước khi có giải pháp | Khi đã có thiết kế/sản phẩm |
| Câu hỏi | "Vấn đề là gì?" | "Cái này có tốt không?" |
| Đầu ra | Insight, JTBD, cơ hội | Điểm số, lỗi, quyết định |
| Rủi ro nếu bỏ qua | Làm sai thứ cần làm | Làm hỏng thứ đúng |
Tình huống thực tế
Ví dụ 1 — Ứng dụng gọi xe: khi test đúng nhưng hỏi sai câu
Một startup gọi xe công nghệ tại TP.HCM (gọi tên giả định là "ViGo") thấy tỷ lệ tài xế rời bỏ ứng dụng trong 3 tháng đầu lên tới 42%. Đội sản phẩm phản ứng ngay bằng một loạt usability test trên màn hình nhận cuốc: họ mời 8 tài xế vào phòng lab, đo xem tài xế bấm nút "Nhận cuốc" có nhanh không, có nhầm lẫn gì không. Kết quả rất đẹp: task success rate 96%, thời gian phản ứng dưới 2 giây. Nhưng tỷ lệ rời bỏ vẫn không giảm.
Diễn giải: Đội ViGo đã chọn nhầm loại nghiên cứu. Họ dùng Evaluative (đánh giá màn hình đã có) để giải một bài toán vốn cần Generative (khám phá vì sao tài xế bỏ đi). Khi cuối cùng họ chạy 12 buổi phỏng vấn sâu và đi thực địa cùng tài xế (contextual inquiry), họ phát hiện vấn đề thật chẳng nằm ở màn hình nào cả: tài xế bỏ đi vì cảm thấy cách tính thưởng cuối tuần không minh bạch và họ không tin phần mềm chia cuốc công bằng. Đây là một insight mà không một usability test nào phát hiện ra được, vì usability test không đặt câu hỏi đó.
Bài học: Khi bạn thấy một chỉ số kinh doanh xấu (churn, drop-off, doanh thu) mà chưa biết nguyên nhân, đó gần như luôn là tín hiệu cần Generative trước, Evaluative sau. Đừng dùng đánh giá để trả lời câu hỏi khám phá.
Ví dụ 2 — Sàn thương mại điện tử: dùng generative đúng lúc
Tiki (bối cảnh giả định hóa cho mục đích minh họa) muốn ra tính năng mới cho nhóm khách hàng bán hàng nhỏ lẻ. Thay vì lao vào thiết kế ngay, đội nghiên cứu chạy một đợt diary study kéo dài 2 tuần với 10 nhà bán hàng, kết hợp 6 buổi phỏng vấn sâu. Họ phát hiện một job-to-be-done bất ngờ: người bán không cần "thêm công cụ marketing", họ cần "biết chắc chắn khi nào tiền về tài khoản để xoay vòng vốn nhập hàng". Insight này mở ra một cơ hội (opportunity) hoàn toàn khác với ý tưởng ban đầu của đội.
Sau đó, khi đã có một prototype bảng theo dõi dòng tiền, đội mới chuyển sang Evaluative: usability test với 5 người bán để xem họ có hiểu bảng số liệu không, rồi A/B test hai cách hiển thị "ngày dự kiến nhận tiền" trên nhóm lớn để chọn phiên bản có tỷ lệ tương tác cao hơn.
Bài học: Đây là trình tự lý tưởng: Generative để tìm đúng vấn đề và cơ hội, rồi Evaluative để làm đúng cách. Hai loại nghiên cứu không cạnh tranh — chúng nối tiếp nhau trong dòng chảy sản phẩm.
Ví dụ 3 — Ngân hàng số: khi Evaluative là lựa chọn đúng và tiết kiệm
Một ngân hàng số tại Đông Nam Á chuẩn bị đổi luồng mở tài khoản eKYC. Vấn đề ở đây đã được biết rõ: luồng cũ có 7 bước, tỷ lệ bỏ dở ở bước chụp ảnh CCCD là 31%. Đội thiết kế đã có 3 phương án luồng mới. Ở tình huống này, chạy generative là lãng phí — họ không cần khám phá thêm vấn đề, họ cần chọn phương án tốt nhất.
Họ dùng đúng Evaluative: unmoderated remote testing với 60 người cho từng phương án để so sánh tỷ lệ hoàn thành, cộng với 5 buổi moderated test để hiểu tại sao người dùng vấp ở bước nào. Kết quả chọn được phương án giảm drop-off từ 31% xuống 12%.
Bài học: Khi vấn đề đã rõ và bạn đang phải chọn giữa các giải pháp cụ thể, Evaluative là lựa chọn đúng, nhanh và rẻ hơn. Chạy generative "cho chắc" trong tình huống này chỉ tốn thời gian và làm chậm quyết định.
Hướng dẫn từng bước
Đây là quy trình 6 bước để quyết định dùng loại nghiên cứu nào cho một yêu cầu bất kỳ:
- Viết ra câu hỏi nghiên cứu ở dạng thô. Ghi lại đúng thứ mà bên yêu cầu (PM, sếp, designer) muốn biết. Ví dụ: "Vì sao người dùng không dùng tính năng X?".
- Kiểm tra: bạn đang có giải pháp trong đầu chưa? Nếu câu hỏi giả định một giải pháp đã tồn tại ("nút này có dễ bấm không") → nghiêng về Evaluative. Nếu câu hỏi mở, không gắn với giải pháp cụ thể ("người dùng cần gì") → nghiêng về Generative.
- Định vị trên vòng đời sản phẩm. Chúng ta đang ở giai đoạn nào? Chưa có ý tưởng / đang tìm hướng → Generative. Đã có prototype / sản phẩm đang chạy → Evaluative.
- Phân biệt "why" và "what/how well". Câu hỏi bắt đầu bằng tại sao / cái gì đang xảy ra thường cần Generative. Câu hỏi cái này tốt đến đâu / phương án nào thắng cần Evaluative.
- Chọn phương pháp phù hợp với loại đã xác định (chi tiết từng phương pháp ở các bài sau). Generative → phỏng vấn sâu, contextual inquiry, diary study, ethnography. Evaluative → usability testing, A/B testing, benchmark metrics, heuristic evaluation.
- Xác định tiêu chí thành công trước khi chạy. Với Generative: "chúng ta muốn hiểu được điều gì?". Với Evaluative: "ngưỡng nào để coi là đạt?" (ví dụ task success ≥ 85%). Nếu không định nghĩa được tiêu chí, khả năng cao bạn đang nhầm loại.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng Evaluative để trả lời câu hỏi Generative. Đây là lỗi phổ biến nhất (như ví dụ ViGo). Triệu chứng: bạn test một giao diện rất kỹ nhưng chỉ số kinh doanh không nhúc nhích, vì vấn đề thật nằm ngoài giao diện. Mẹo: khi nguyên nhân còn mơ hồ, luôn khám phá trước.
Lỗi 2 — Chạy Generative khi vấn đề đã rõ. Một số nhà nghiên cứu "yêu" phỏng vấn sâu đến mức dùng nó cho mọi thứ. Khi bạn chỉ cần chọn giữa hai layout, phỏng vấn sâu 15 người là lãng phí ngân sách và thời gian. Mẹo: tôn trọng nguyên tắc "phương pháp nhẹ nhất trả lời được câu hỏi".
Lỗi 3 — Đòi kết luận định lượng từ nghiên cứu định tính (và ngược lại). Đừng nói "80% người dùng ghét tính năng này" khi bạn chỉ phỏng vấn 5 người — generative không cho bạn con số đại diện. Ngược lại, đừng mong A/B test giải thích tại sao B thắng — nó chỉ nói B thắng.
Lỗi 4 — Nhầm số lượng người tham gia. Generative thường cần ít người nhưng đào sâu (5–15). Evaluative định tính (usability test) nổi tiếng với "5 người phát hiện ~85% vấn đề". Evaluative định lượng (A/B test, survey) lại cần cỡ mẫu lớn để có ý nghĩa thống kê. Chọn nhầm cỡ mẫu là chọn nhầm loại.
Mẹo vàng — Hai loại nghiên cứu là một vòng lặp, không phải lựa chọn một lần. Vòng đời khỏe mạnh là: Generative (khám phá) → thiết kế → Evaluative (kiểm chứng) → phát hiện vấn đề mới → Generative lần nữa. Đừng nghĩ theo kiểu "chọn một loại rồi xong".
Mẹo — Ranh giới đôi khi mờ. Một số phương pháp có thể phục vụ cả hai mục đích tùy cách dùng (ví dụ khảo sát mở có thể generative, khảo sát đóng thường evaluative). Điều quyết định không phải công cụ, mà là ý định và câu hỏi nghiên cứu của bạn.
Bài tập thực hành
Bài tập 1 — Phân loại nhanh. Với mỗi tình huống dưới đây, hãy ghi rõ Generative hay Evaluative và giải thích trong 1–2 câu:
a) "Tỷ lệ hoàn thành thanh toán mới đạt 60%, hãy tìm cách tăng lên." (đã có luồng thanh toán, biết vấn đề) b) "Chúng ta muốn làm sản phẩm cho người cao tuổi ở Việt Nam nhưng chưa biết bắt đầu từ đâu." c) "Layout mới của trang chủ có làm tăng thời gian ở lại trang không?" d) "Vì sao khách hàng doanh nghiệp gia hạn hợp đồng ít hơn năm ngoái?"
Bài tập 2 — Chuyển hóa câu hỏi. Sếp đưa bạn yêu cầu: "Nghiên cứu xem tính năng chat AI của mình có ổn không." Hãy tách yêu cầu mơ hồ này thành: (1) một câu hỏi Generative để khám phá nhu cầu thật, và (2) một câu hỏi Evaluative để đánh giá tính năng hiện có. Ghi rõ với mỗi câu hỏi bạn sẽ dùng nhóm phương pháp nào.
Bài tập 3 — Vẽ vòng lặp. Chọn một sản phẩm bạn đang dùng hằng ngày (app ngân hàng, app đặt đồ ăn...). Phác một vòng lặp nghiên cứu gồm ít nhất 2 chặng generative và 2 chặng evaluative cho một tính năng của nó, sắp theo đúng trình tự thời gian. Với mỗi chặng, ghi câu hỏi nghiên cứu và đầu ra kỳ vọng.
Gợi ý chấm điểm: Đáp án bài 1: (a) Evaluative, (b) Generative, (c) Evaluative, (d) Generative — vì (d) hỏi "tại sao" và nguyên nhân chưa rõ.
Tóm tắt
- Generative Research khám phá điều chưa biết: dùng trước khi có giải pháp, trả lời "vấn đề là gì", cho ra insight, jobs-to-be-done, cơ hội. Nó "làm đúng thứ cần làm".
- Evaluative Research kiểm chứng điều đã có: dùng khi đã có thiết kế/sản phẩm, trả lời "cái này tốt đến đâu / phương án nào thắng", cho ra điểm số, danh sách lỗi, quyết định. Nó "làm thứ đó đúng cách".
- Định vị bằng Double Diamond: kim cương đầu (Discover/Define) là Generative, kim cương sau (Develop/Deliver) là Evaluative.
- Lỗi tốn kém nhất là dùng Evaluative để trả lời câu hỏi Generative — test rất kỹ một thứ không ai cần. Khi nguyên nhân còn mơ hồ, hãy khám phá trước.
- Câu hỏi vàng để phân loại: "Nếu kết quả xấu, ta sẽ làm gì?" — nghĩ lại vấn đề (Generative) hay sửa/chọn thiết kế (Evaluative).
- Hai loại không loại trừ nhau; chúng là một vòng lặp liên tục xoay quanh vòng đời sản phẩm. Người làm nghiên cứu giỏi biết khi nào chuyển từ khám phá sang kiểm chứng, và ngược lại.