Bài 5 — Generative vs Evaluative Research

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa được giao nhiệm vụ làm research cho một ứng dụng giao đồ ăn mới. Bạn hào hứng lên kế hoạch, mời người dùng tới văn phòng, mở sẵn bản prototype và hỏi: "Anh/chị thấy nút đặt hàng này dễ dùng không?". Buổi test diễn ra suôn sẻ, mọi người gật gù, bạn báo cáo "sản phẩm dễ dùng". Nhưng ba tháng sau khi ra mắt, người dùng… không đặt món. Vì sao? Vì ngay từ đầu bạn đã hỏi sai loại câu hỏi. Bạn đi validate (kiểm chứng) một thiết kế trong khi điều cần làm là discover (khám phá) xem người Việt thực sự muốn gì khi đói bụng lúc 11 giờ trưa ở văn phòng.

Đây chính là lý do bài học này quan trọng. Trong nghề UX Research, một trong những quyết định nền tảng nhất — quyết định ảnh hưởng đến toàn bộ phương pháp, câu hỏi, cách tuyển người tham gia và cách diễn giải kết quả — là: bạn đang làm Generative research hay Evaluative research? Hai loại này không phải "tốt hơn / kém hơn" mà phục vụ hai mục đích hoàn toàn khác nhau, ở hai thời điểm khác nhau trong vòng đời sản phẩm.

Nếu bạn nhầm lẫn hai loại này, bạn sẽ tiêu tốn ngân sách và thời gian để trả lời sai câu hỏi — một sai lầm rất tốn kém mà rất nhiều bạn researcher mới (và cả các team product non kinh nghiệm) mắc phải. Nắm vững sự phân biệt này là bước đầu để trở thành một researcher biết chọn đúng công cụ cho đúng vấn đề.

Khái niệm cốt lõi

Hai loại research, hai mục đích

UX Research có thể được chia theo nhiều cách, nhưng cách phân loại theo mục đích là cơ bản và thực dụng nhất. Theo trục này, có hai nhóm lớn:

Generative Research (nghiên cứu khám phá / sinh ra hiểu biết): Mục đích là khám phá — tìm ra những điều bạn chưa biết là mình chưa biết. Trong tiếng Anh, người ta gọi đây là việc đi tìm "unknown unknowns" (những ẩn số mà bạn thậm chí không ngờ chúng tồn tại). Generative research giúp bạn hiểu người dùng là ai, họ sống và làm việc thế nào, vấn đề thực sự của họ là gì, nhu cầu chưa được đáp ứng nằm ở đâu. Loại research này thường diễn ra trước khi bạn xây dựng sản phẩm — khi bạn còn đang định hình bài toán.

Câu hỏi điển hình của Generative research:

• "Người dùng đang gặp khó khăn gì trong cuộc sống/công việc của họ?"
• "Họ hiện đang giải quyết vấn đề này bằng cách nào?"
• "Có nhu cầu nào chưa ai phục vụ không?"

Evaluative Research (nghiên cứu đánh giá / kiểm chứng): Mục đích là đánh giá một giải pháp đã có — kiểm tra xem nó hoạt động tốt đến đâu. Đây là việc trả lời "known unknowns" (những ẩn số mà bạn biết mình cần làm rõ). Bạn đã có một thiết kế, một prototype, hoặc một sản phẩm đang chạy, và bạn muốn biết: nó có dễ dùng không? Người ta có hoàn thành được tác vụ không? Chỗ nào gây vướng? Loại research này diễn ra sau khi bạn đã có một thứ gì đó cụ thể để đánh giá.

Câu hỏi điển hình của Evaluative research:

• "Người dùng có hoàn thành được quy trình thanh toán không?"
• "Thiết kế A hay thiết kế B hiệu quả hơn?"
• "Chỗ nào trong giao diện khiến người dùng bối rối?"

Một phép so sánh dễ nhớ

Hãy nghĩ về việc xây nhà. Generative research giống như bước khảo sát trước khi vẽ bản thiết kế: gia đình có mấy người, họ nấu ăn nhiều không, có nuôi thú cưng không, thói quen sinh hoạt thế nào. Nếu bỏ qua bước này, bạn có thể xây một căn nhà đẹp nhưng không ai muốn sống trong đó. Evaluative research giống như việc đi kiểm tra ngôi nhà sau khi xây: cửa có kẹt không, ánh sáng đủ chưa, đường ống có rò không. Nó không thay đổi bản chất ngôi nhà, nó giúp bạn sửa những lỗi cụ thể.

Một cách diễn đạt khác mà giới UX hay dùng: Generative trả lời "chúng ta nên xây cái gì?", còn Evaluative trả lời "chúng ta đã xây đúng chưa?"

Bảng đối chiếu nhanh

Lưu ý quan trọng: đây không phải lựa chọn một-mất-một

Nhiều bạn mới hiểu lầm rằng phải "chọn phe". Thực tế, một sản phẩm trưởng thành sẽ luân phiên giữa hai loại theo vòng lặp: Generative để mở ra hướng đi → thiết kế → Evaluative để tinh chỉnh → ra mắt → lại Generative để tìm cơ hội mới. Đây là nhịp thở tự nhiên của một product team. Việc của bạn là biết hiện tại team đang ở giai đoạn nào để chọn đúng loại research.

Cũng cần phân biệt rõ: Generative/Evaluative là cách chia theo mục đích, khác với cách chia theo dữ liệu (định tính/định lượng — sẽ học ở bài sau). Một nghiên cứu Generative thường định tính, nhưng cũng có thể có yếu tố định lượng; tương tự với Evaluative. Đừng gộp hai trục này làm một.

Tình huống thực tế

Ví dụ 1 — MoMo và bài toán "vì sao người dùng không dùng tính năng đầu tư"

Giả định một bối cảnh quen thuộc: đội sản phẩm của một ví điện tử lớn tại Việt Nam (gọi là ví A, lấy cảm hứng từ MoMo) vừa ra mắt tính năng "Đầu tư tích lũy" cho phép người dùng bỏ vào quỹ từ 10.000đ. Sau một tháng, chỉ 2% người dùng hoạt động chạm vào tính năng. Ban đầu, team lao ngay vào Evaluative: họ làm usability test, phát hiện vài lỗi nhỏ ở luồng đăng ký, sửa xong, tỷ lệ vẫn không nhúc nhích.

Vấn đề là họ đã chọn sai loại research. Câu hỏi thật sự không phải "luồng đăng ký có dễ dùng không" (known unknown) mà là "vì sao người dùng không muốn đầu tư qua ví ngay từ đầu" (unknown unknown). Khi chuyển sang Generative — phỏng vấn sâu 12 người dùng tại TP.HCM và Cần Thơ — họ phát hiện một insight bất ngờ: phần lớn người dùng không tin tưởng để tiền đầu tư trong một ứng dụng họ vốn coi là "ví để tiêu", và họ sợ "lỡ tay tiêu mất tiền tiết kiệm". Đây là rào cản về niềm tin và mô hình tâm lý, không phải về giao diện.

Bài học: Khi một chỉ số kém, phản xạ "sửa giao diện" (Evaluative) thường vô ích nếu gốc rễ nằm ở việc bạn chưa hiểu vấn đề (cần Generative). Hãy hỏi: ta đang thiếu một insight hay đang có một lỗi?

Ví dụ 2 — Tiki và việc redesign trang chi tiết sản phẩm

Một sàn thương mại điện tử (lấy cảm hứng từ Tiki) muốn thiết kế lại trang chi tiết sản phẩm. Lần này họ làm đúng trình tự. Giai đoạn Generative (3 tuần): họ thực hiện 15 buổi phỏng vấn và quan sát người dùng đang mua hàng thật trên điện thoại. Phát hiện: người mua Việt Nam đọc phần đánh giá (review) và phần "hỏi đáp" trước cả khi xem mô tả sản phẩm, vì họ quan tâm "hàng có thật không, ship có nhanh không" hơn là thông số kỹ thuật. Đây là một insight Generative — không ai trong team ngờ tới.

Dựa trên insight đó, team thiết kế lại, đưa review và Q&A lên cao hơn. Sau đó họ bước vào giai đoạn Evaluative: chạy usability test với 8 người trên prototype mới, đo thời gian tìm thấy thông tin tin cậy. Kết quả: thời gian giảm 35%, và 7/8 người nói "trang này đáng tin hơn". Cuối cùng, sau khi ra mắt một phần, họ chạy A/B test trên lưu lượng thật và thấy tỷ lệ thêm vào giỏ tăng 8%.

Bài học: Generative mở ra hướng đúng (đưa review lên đầu), Evaluative xác nhận làm có tốt không và tốt bao nhiêu. Hai loại nối tiếp nhau tạo thành một chu trình hoàn chỉnh: discover → design → validate.

Ví dụ 3 — Một startup giáo dục và cú "validate quá sớm"

Một startup edtech nhỏ (giả định) ở Hà Nội tin chắc rằng học sinh cấp 3 cần một app luyện thi với "lớp học ảo có giáo viên livestream". Họ không làm Generative, nhảy thẳng vào xây prototype rồi mời 6 học sinh test. Học sinh khen "giao diện đẹp", "dễ bấm" — báo cáo Evaluative đẹp như mơ. Họ gọi vốn, xây sản phẩm thật trong 6 tháng.

Khi ra mắt, gần như không học sinh nào dùng tính năng livestream. Phỏng vấn muộn màng (cuối cùng cũng làm Generative) cho thấy: học sinh ôn thi vào ban đêm sau giờ học thêm, mỗi người một lịch khác nhau, nên không thể tham gia một buổi livestream cố định. Cái họ cần là video ghi sẵn xem lúc nào cũng được. Insight này lẽ ra phải lộ ra ngay từ tuần đầu nếu họ làm Generative trước.

Bài học: Một buổi Evaluative "đẹp" có thể đánh lừa bạn. Người dùng khen prototype dễ dùng không có nghĩa là họ sẽ dùng. Usability tốt mà giải quyết sai vấn đề thì vẫn thất bại. Đừng bao giờ dùng Evaluative để né tránh việc phải làm Generative.

Hướng dẫn từng bước

Đây là quy trình để bạn xác định mình cần loại research nào và bắt đầu đúng cách.

Bước 1 — Xác định bạn đang ở đâu trong vòng đời sản phẩm. Hỏi: "Chúng ta đã có một giải pháp cụ thể để đánh giá chưa?" Nếu chưa (còn đang định hình bài toán, mới có ý tưởng mơ hồ) → nghiêng về Generative. Nếu đã có (prototype, bản beta, sản phẩm đang chạy) và muốn cải thiện nó → nghiêng về Evaluative.

Bước 2 — Viết ra câu hỏi nghiên cứu và phân loại nó. Đọc kỹ câu hỏi của bạn. Nếu nó bắt đầu bằng "vì sao", "như thế nào", "người dùng cần gì", "điều gì đang cản trở họ" — thường là Generative. Nếu nó bắt đầu bằng "cái này có dễ dùng không", "A hay B tốt hơn", "tỷ lệ hoàn thành là bao nhiêu" — thường là Evaluative.

Bước 3 — Kiểm tra giả định ẩn. Nếu bạn định làm Evaluative, hãy tự hỏi: "Mình có chắc đây là đúng vấn đề để giải không?". Nếu câu trả lời lung lay, lùi lại làm Generative trước. Đây là chốt chặn quan trọng nhất để tránh sai lầm như ví dụ 3.

Bước 4 — Chọn phương pháp phù hợp với loại. Generative → phỏng vấn sâu, contextual inquiry, diary study (các bài 9, 10, 11 sẽ đào sâu). Evaluative → usability testing, A/B test, đánh giá heuristic (các bài 14–20). Đừng lo nắm hết bây giờ; chỉ cần biết họ phục vụ loại nào.

Bước 5 — Chọn đúng kiểu người tham gia và cách diễn giải. Với Generative, bạn cần người đa dạng để mở rộng góc nhìn, và bạn lắng nghe cởi mở. Với Evaluative, bạn cần người đại diện cho người dùng thật của sản phẩm, và bạn đo lường theo tiêu chí định trước.

Bước 6 — Khép vòng lặp. Sau Evaluative, nếu kết quả hé lộ vấn đề sâu hơn (như ví dụ 1), hãy sẵn sàng quay lại Generative. Đây là một vòng tròn, không phải đường thẳng.

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: chỉ số kém → vội test giao diện. Mẹo: khi gặp vấn đề "vì sao", hãy cưỡng lại ham muốn nhảy vào prototype.

Lỗi 2 — Hỏi ý kiến thay vì quan sát hành vi trong Generative. "Anh/chị có thích tính năng này không?" cho ra câu trả lời lịch sự, vô giá trị. Generative tốt tập trung vào họ đang thực sự làm gì và đã gặp khó ở đâu, không phải họ nghĩ gì về ý tưởng của bạn.

Lỗi 3 — Mời "fan" của sản phẩm vào Evaluative. Test với người thân, đồng nghiệp, hoặc người đã yêu sản phẩm sẵn sẽ cho kết quả tô hồng. Hãy tuyển người đại diện thật.

Lỗi 4 — Tưởng Generative là "mơ hồ nên không cần plan". Generative cởi mở về câu trả lời, nhưng vẫn cần mục tiêu rõ ràng. Cởi mở không có nghĩa là không chuẩn bị.

Lỗi 5 — Bỏ qua một loại vì áp lực thời gian. Câu "không có thời gian làm Generative" thường dẫn tới việc xây nhầm thứ trong 6 tháng — tốn thời gian gấp bội. Một tuần phỏng vấn rẻ hơn nhiều so với một sản phẩm thất bại.

Mẹo vàng: Trước mỗi dự án research, dán một câu hỏi lên màn hình: "Tôi đang đi khám phá (discover) hay đi kiểm chứng (validate)?". Nếu không trả lời được rõ ràng, bạn chưa sẵn sàng bắt đầu.

Bài tập thực hành

Bài tập 1 — Phân loại. Đọc 6 câu hỏi sau và gắn nhãn Generative (G) hay Evaluative (E):

• "Người dùng làm gì trong 5 phút trước khi mở app ngân hàng của chúng ta?"
• "Quy trình mở thẻ mới mất trung bình bao nhiêu bước trước khi bỏ cuộc?"
• "Vì sao người bán hàng online ở chợ truyền thống ngại dùng phần mềm quản lý kho?"
• "Bản thiết kế nút 'Thanh toán' màu cam hay xanh cho tỷ lệ click cao hơn?"
• "Những lo lắng nào khiến phụ huynh chưa cho con học online?"
• "Người dùng có tìm thấy mục 'Lịch sử giao dịch' trong giao diện mới không?"

(Gợi ý đáp án: 1-G, 2-E, 3-G, 4-E, 5-G, 6-E. Hãy tự giải thích vì sao trước khi xem.)

Bài tập 2 — Chẩn đoán tình huống. Một quán cà phê chuỗi ra mắt app tích điểm nhưng chỉ 5% khách dùng. Quản lý muốn "test lại xem nút tích điểm có dễ bấm không". Hãy viết một đoạn 150–200 từ lập luận: liệu Evaluative có phải lựa chọn đúng ở đây không, hay nên bắt đầu bằng Generative? Đề xuất câu hỏi nghiên cứu cụ thể cho loại bạn chọn.

Bài tập 3 — Lập kế hoạch vòng lặp. Chọn một sản phẩm bạn dùng hàng ngày (ví dụ Grab, Shopee, Zalo). Viết ra: (a) một câu hỏi Generative để khám phá một cơ hội mới, và (b) một câu hỏi Evaluative để cải thiện một tính năng đã có. Giải thích thứ tự bạn sẽ làm chúng và vì sao.

Tóm tắt

• UX Research chia theo mục đích thành hai loại nền tảng: Generative (khám phá — đi tìm unknown unknowns, trước khi build) và Evaluative (kiểm chứng — làm rõ known unknowns, sau khi đã có thiết kế/sản phẩm).
• Generative trả lời "chúng ta nên xây cái gì?"; Evaluative trả lời "chúng ta đã xây đúng chưa?".
• Hai loại không loại trừ nhau mà luân phiên trong một vòng lặp: discover → design → validate → discover.
• Sai lầm tốn kém nhất là dùng Evaluative để né tránh Generative — usability tốt mà giải quyết sai vấn đề thì sản phẩm vẫn thất bại (như startup edtech ở ví dụ 3).
• Trước mỗi dự án, luôn tự hỏi: "Tôi đang khám phá hay đang kiểm chứng?". Trả lời được câu này là bạn đã chọn đúng nửa cuộc chơi.

Ở các bài tiếp theo, chúng ta sẽ đi sâu vào từng nhánh: cách phân biệt dữ liệu định tính và định lượng (Bài 6), cách lập một research plan bài bản (Bài 7), rồi từng phương pháp Generative và Evaluative cụ thể. Nhưng tất cả đều bắt đầu từ tư duy nền tảng của bài này: chọn đúng mục đích trước khi chọn phương pháp.