Mở đầu — vì sao bài này quan trọng
Có một sự thật phũ phàng mà ít ai nói thẳng với bạn khi mới vào nghề nghiên cứu UX: phần lớn các dự án nghiên cứu thất bại không phải vì phương pháp sai, không phải vì thiếu ngân sách, cũng không phải vì người tham gia không hợp tác. Chúng thất bại ngay từ dòng đầu tiên — khi câu hỏi nghiên cứu (research question) được đặt ra một cách cẩu thả, mơ hồ hoặc thực ra là một quyết định đã có sẵn được ngụy trang thành câu hỏi.
Hãy hình dung câu hỏi nghiên cứu như la bàn của cả cuộc hành trình. Nếu la bàn lệch một độ, đi càng xa bạn càng lạc. Một câu hỏi tồi sẽ kéo theo việc chọn sai phương pháp, tuyển sai người tham gia, thu thập sai dữ liệu, và cuối cùng bạn ngồi trước một đống insight nhưng không biết diễn giải chúng để làm gì. Ngược lại, một câu hỏi tốt tự nó đã gợi ý cho bạn nên dùng phỏng vấn hay khảo sát, nên quan sát hay đo lường, và khi có kết quả thì bạn biết chính xác nó trả lời cho điều gì.
Ở các bài trước, chúng ta đã bàn về sự khác biệt giữa nghiên cứu generative và evaluative, về mixed methods. Bài này đi vào một kỹ năng nền tảng hơn tất cả những thứ đó: cách đặt ra câu hỏi nghiên cứu đúng đắn. Đây là kỹ năng phân biệt một researcher thực thụ với một người chỉ biết chạy công cụ. Bạn có thể thuê ai đó điều phối một buổi usability test, nhưng việc biết nên hỏi điều gì thì không thể thuê ngoài.
Khái niệm cốt lõi
Research question là gì và không là gì
Câu hỏi nghiên cứu là phát biểu rõ ràng về điều bạn muốn tìm hiểu, được diễn đạt sao cho có thể trả lời được bằng dữ liệu thực nghiệm. Nghe đơn giản, nhưng ba yếu tố "rõ ràng", "có thể trả lời được" và "bằng dữ liệu" chính là nơi hầu hết mọi người vấp ngã.
Trước hết, cần phân biệt ba tầng khái niệm thường bị nhầm lẫn:
- Mục tiêu kinh doanh (business goal): điều tổ chức muốn đạt được, ví dụ "tăng tỷ lệ hoàn tất thanh toán trên app". Đây không phải câu hỏi nghiên cứu.
- Câu hỏi nghiên cứu (research question): điều bạn cần hiểu để phục vụ mục tiêu đó, ví dụ "Điều gì khiến người dùng bỏ giỏ hàng ở bước nhập địa chỉ giao hàng?".
- Câu hỏi phỏng vấn/khảo sát (interview/survey question): câu chữ cụ thể bạn hỏi người tham gia, ví dụ "Bạn hãy kể lại lần gần nhất mua hàng trên app mà không hoàn tất — chuyện gì đã xảy ra?".
Các loại câu hỏi nghiên cứu
Không phải mọi câu hỏi nghiên cứu đều cùng bản chất. Phân loại chúng giúp bạn biết ngay nên hướng về phương pháp nào.
Câu hỏi mô tả (descriptive) — bắt đầu bằng "Cái gì / Ai / Khi nào / Ở đâu / Như thế nào". Chúng vẽ ra bức tranh về hiện trạng. Ví dụ: "Người dùng thực hiện những bước nào để đặt lịch khám tại phòng khám?". Loại này thường dẫn tới quan sát, contextual inquiry, hoặc phân tích hành trình.
Câu hỏi giải thích/nguyên nhân (explanatory / causal) — bắt đầu bằng "Tại sao". Chúng đào tìm động cơ, rào cản, nguyên nhân. Ví dụ: "Tại sao người dùng ưu tiên gọi hotline thay vì chat trong app?". Loại này đòi hỏi phương pháp định tính sâu vì "tại sao" hiếm khi đo được bằng con số.
Câu hỏi so sánh (comparative) — "Phương án A hay B tốt hơn với người dùng?". Dẫn tới A/B testing hoặc usability test có điều kiện.
Câu hỏi đánh giá (evaluative) — "Thiết kế hiện tại có giúp người dùng hoàn tất tác vụ không, và ở đâu họ gặp khó?". Dẫn tới usability testing.
Câu hỏi quan hệ/định lượng (relational) — "Có mối liên hệ nào giữa số bước đăng ký và tỷ lệ bỏ cuộc không?". Dẫn tới khảo sát quy mô hoặc phân tích dữ liệu hành vi.
Điều quan trọng cần nhớ: loại câu hỏi quyết định phương pháp, chứ không phải ngược lại. Nếu bạn thấy mình đang cố nhét một câu hỏi "tại sao" vào một khảo sát trắc nghiệm, đó là dấu hiệu bạn đã đảo ngược trật tự.
Tiêu chí của một câu hỏi tốt: khung FINER-UX
Trong y khoa người ta có khung FINER để đánh giá câu hỏi nghiên cứu. Tôi điều chỉnh nó cho UX như sau — một câu hỏi tốt nên:
- Feasible (khả thi): bạn có đủ người tham gia, thời gian, công cụ để trả lời không? "Người dùng ở toàn bộ Đông Nam Á nghĩ gì?" là bất khả thi trong một sprint hai tuần.
- Interesting & Actionable (đáng quan tâm & hành động được): câu trả lời có dẫn tới một quyết định thiết kế cụ thể không? Nếu dù trả lời cách nào team cũng làm y hệt, thì đừng nghiên cứu.
- Novel (mới): điều này đã biết chưa? Đừng tốn nghiên cứu cho thứ dữ liệu analytics đã trả lời sẵn.
- Ethical (đạo đức): câu hỏi có buộc bạn thu thập dữ liệu nhạy cảm không cần thiết không?
- Relevant & Right-scoped (liên quan & đúng phạm vi): đủ hẹp để trả lời trọn vẹn, đủ rộng để đáng làm.
Câu hỏi trung lập, không giả định trước câu trả lời
Một cái bẫy tinh vi: câu hỏi nghiên cứu chứa sẵn giả định hoặc thiên kiến của người viết. "Tính năng thông báo phiền phức của chúng ta khiến người dùng khó chịu ở mức nào?" đã giả định thông báo là phiền và người dùng khó chịu. Nó không phải câu hỏi, nó là một lời buộc tội đi tìm bằng chứng. Phiên bản trung lập: "Người dùng phản ứng thế nào với các thông báo hiện tại của app?".
Tình huống thực tế
Tình huống 1 — Tiki và câu hỏi bị "đội lốt" quyết định
Một nhóm product tại một sàn thương mại điện tử lớn ở Việt Nam (gọi là bối cảnh kiểu Tiki) muốn thêm nút "Mua ngay bằng một chạm". Họ giao cho researcher yêu cầu: "Nghiên cứu xem người dùng có thích nút Mua-một-chạm không".
Nghe thì có vẻ là câu hỏi nghiên cứu, nhưng thực ra quyết định đã được đưa ra — họ chỉ muốn tìm sự đồng thuận. Researcher tinh ý đã lùi lại một bước và tái định hình: thay vì hỏi "người dùng có thích tính năng X không", cô đặt lại là "Điều gì khiến người dùng chần chừ hoặc bỏ cuộc ở bước cuối của quy trình thanh toán?".
Khác biệt là một trời một vực. Câu hỏi ban đầu chỉ có thể trả lời "thích/không thích" và dễ bị bias bởi câu hỏi dẫn dắt. Câu hỏi mới mở ra không gian khám phá. Kết quả: qua 12 buổi phỏng vấn có ghi lại thao tác, hóa ra rào cản lớn nhất không phải số lần chạm, mà là nỗi lo bấm nhầm và bị trừ tiền ngay lập tức mà không kịp xem lại đơn. Trong 12 người, 8 người nhắc tới nỗi sợ này. Nút "một chạm" nếu làm theo ý ban đầu sẽ càng khoét sâu nỗi lo đó.
Bài học: khi nhận yêu cầu dạng "nghiên cứu xem người dùng có thích X không", hãy tự hỏi — đây là câu hỏi thật hay là quyết định cần được hợp thức hóa? Tái định hình về vấn đề của người dùng, đừng nghiên cứu về giải pháp của bạn.
Tình huống 2 — Ứng dụng gọi xe và câu hỏi quá rộng
Một startup gọi xe ở khu vực Đông Nam Á (bối cảnh kiểu Gojek/Grab giai đoạn đầu) giao cho đội research một câu hỏi: "Làm sao để cải thiện trải nghiệm tài xế?".
Đây là ví dụ điển hình của câu hỏi quá rộng đến mức vô dụng. "Trải nghiệm tài xế" bao gồm hàng chục hành trình con: đăng ký, nhận chuyến, điều hướng, thu tiền, khiếu nại, rút thu nhập... Với ngân sách một tháng, không cách nào trả lời trọn vẹn.
Đội đã dùng kỹ thuật chưng cất câu hỏi. Trước hết họ nhìn dữ liệu vận hành và thấy một tín hiệu: tỷ lệ tài xế mới rời bỏ trong 30 ngày đầu cao bất thường — khoảng 40%. Từ đó họ thu hẹp thành: "Trong 30 ngày đầu, những khoảnh khắc nào khiến tài xế mới cân nhắc bỏ cuộc?". Hẹp hơn nữa, họ tách thành hai câu hỏi con: (1) "Tài xế mới gặp trở ngại gì trong tuần đầu tiên khi làm quen với app?" và (2) "Kỳ vọng về thu nhập của họ khác thực tế ra sao trong tháng đầu?".
Với câu hỏi được mài sắc như vậy, họ chọn diary study kết hợp phỏng vấn — theo chân 15 tài xế mới suốt 30 ngày. Phát hiện then chốt: cú sốc lớn nhất không phải kỹ thuật app, mà là khoảng cách giữa thu nhập được quảng cáo lúc tuyển và thu nhập thực tuần đầu khi chưa quen khu vực.
Bài học: câu hỏi quá rộng không sai về mặt ý định, nhưng không thể hành động. Hãy dùng dữ liệu sẵn có để tìm điểm nóng, rồi thu hẹp câu hỏi quanh điểm nóng đó. Một câu hỏi tốt thường đã ẩn chứa giới hạn phạm vi trong chính cách diễn đạt của nó.
Tình huống 3 — Ngân hàng số và câu hỏi trả lời được bằng analytics
Một ngân hàng số Việt Nam muốn tổ chức một nghiên cứu định tính tốn kém để trả lời: "Có bao nhiêu phần trăm người dùng bỏ dở luồng mở tài khoản trực tuyến, và họ dừng ở bước nào?".
Researcher đã can đảm nói: câu hỏi này không cần nghiên cứu định tính — nó đã nằm sẵn trong funnel analytics. Chỉ mất nửa ngày truy vấn dữ liệu, họ biết ngay 62% người dùng rơi rụng đúng ở bước chụp CCCD (căn cước công dân), cụ thể là màn hình chờ xác thực OCR.
Nhưng — và đây là điểm hay — dữ liệu định lượng nói được "ở đâu" chứ không nói được "tại sao". Vậy nên câu hỏi nghiên cứu định tính thực sự đáng làm được viết lại thành: "Tại sao người dùng bỏ cuộc ngay tại bước xác thực CCCD?". Câu hỏi này mới xứng đáng huy động phỏng vấn và usability test, và nó tiết kiệm cho ngân hàng cả tuần nghiên cứu lãng phí.
Bài học: trước khi viết câu hỏi nghiên cứu định tính, luôn tự hỏi "dữ liệu sẵn có đã trả lời phần nào chưa?". Định lượng trả lời "cái gì, bao nhiêu, ở đâu"; định tính trả lời "tại sao, như thế nào". Đặt câu hỏi đúng loại cho đúng công cụ.
Hướng dẫn từng bước
Đây là quy trình sáu bước tôi khuyên bạn áp dụng mỗi khi bắt đầu một dự án.
Bước 1 — Bắt đầu từ quyết định, không phải từ tò mò. Hỏi stakeholder: "Sau khi có kết quả, bạn sẽ đưa ra quyết định gì?". Nếu không có quyết định nào phía sau, dừng lại. Câu trả lời này neo toàn bộ nghiên cứu vào tính hành động.
Bước 2 — Viết ra câu hỏi thô, càng nhiều càng tốt. Đừng biên tập vội. Gom mọi thắc mắc từ team lên một bảng. Ở giai đoạn này số lượng quan trọng hơn chất lượng.
Bước 3 — Phân loại và gộp nhóm. Đánh dấu mỗi câu hỏi thô thuộc loại nào (mô tả, tại sao, so sánh, đánh giá, định lượng). Bạn sẽ thấy chúng gom lại thành vài chủ đề. Gộp các câu trùng lặp.
Bước 4 — Chưng cất thành một câu hỏi trung tâm và vài câu hỏi phụ. Một nghiên cứu tốt thường có một primary question và hai đến bốn secondary question bổ trợ. Nhiều hơn năm là dấu hiệu phạm vi bị phình.
Bước 5 — Kiểm định qua bộ lọc FINER-UX. Với mỗi câu hỏi, hỏi: khả thi không? hành động được không? đã biết chưa? đúng phạm vi chưa? có trung lập không? Loại bỏ hoặc viết lại những câu trượt.
Bước 6 — Ánh xạ câu hỏi sang phương pháp. Với mỗi câu hỏi cuối cùng, ghi bên cạnh phương pháp sẽ trả lời nó. Nếu một câu hỏi không ánh xạ được sang phương pháp khả thi nào, quay lại bước 4.
Một mẹo diễn đạt: dùng khuôn "Chúng tôi muốn hiểu [ai] [làm/nghĩ/cảm thấy gì] khi [bối cảnh nào], để [phục vụ quyết định gì]". Ví dụ: "Chúng tôi muốn hiểu tài xế mới gặp trở ngại gì khi làm quen app trong tuần đầu, để quyết định nên tinh giản bước onboarding nào". Khuôn này ép bạn nêu đủ đối tượng, bối cảnh và mục đích hành động.
Lỗi thường gặp & mẹo
Lỗi 1 — Câu hỏi dẫn dắt (leading). "Tính năng mới tuyệt vời của chúng ta hữu ích thế nào?" đã gài sẵn kết luận. Mẹo: đọc to câu hỏi và xem nó có ngụ ý một câu trả lời "đúng" không. Nếu có, viết lại trung lập.
Lỗi 2 — Câu hỏi hai-trong-một (double-barreled). "Người dùng thấy giao diện dễ dùng và đẹp không?" trộn hai biến vào một. Tách thành hai câu hỏi riêng.
Lỗi 3 — Câu hỏi trả lời được bằng có/không. "Người dùng có thích không?" cho bạn rất ít để hành động. Chuyển sang dạng mở: "Người dùng phản ứng thế nào và vì sao?".
Lỗi 4 — Nhầm giải pháp với vấn đề. "Người dùng có muốn thêm chatbot không?" nghiên cứu về giải pháp của bạn. "Người dùng tìm kiếm hỗ trợ như thế nào khi gặp trục trặc?" nghiên cứu về vấn đề của họ — và có thể chatbot không phải câu trả lời.
Lỗi 5 — Phạm vi phình to. Nếu câu hỏi của bạn chứa chữ "và" nối nhiều lĩnh vực, hoặc dùng từ "toàn bộ / mọi", hãy nghi ngờ. Thu hẹp.
Mẹo vàng — Kiểm tra "câu trả lời tưởng tượng". Trước khi chốt câu hỏi, hãy tưởng tượng bạn đã có câu trả lời trong tay. Hỏi: "Với câu trả lời này, team sẽ làm gì khác đi?". Nếu không nghĩ ra hành động cụ thể, câu hỏi chưa đủ tốt. Đây là bài kiểm tra một câu nhanh và tàn nhẫn nhất về tính hành động.
Mẹo — Hỏi ngược stakeholder. Khi stakeholder đưa cho bạn một "câu hỏi", hãy hỏi lại: "Nếu kết quả ngược với kỳ vọng của anh/chị, chúng ta có sẵn sàng đổi hướng không?". Nếu câu trả lời là không, đó không phải câu hỏi nghiên cứu mà là một quyết định đã chốt — và bạn nên nói thẳng để tránh lãng phí.
Bài tập thực hành
Bài tập 1 — Chưng cất câu hỏi. Lấy business goal sau: "Ban lãnh đạo muốn tăng tỷ lệ người dùng nâng cấp lên gói Premium của một app học tiếng Anh". Hãy viết ra một câu hỏi nghiên cứu trung tâm và ba câu hỏi phụ. Với mỗi câu, ghi rõ nó thuộc loại nào và phương pháp nào sẽ trả lời nó.
Bài tập 2 — Sửa lỗi. Viết lại năm câu hỏi lỗi sau thành phiên bản tốt, và chỉ rõ lỗi gì:
- "Người dùng có thấy phiên bản redesign đẹp và nhanh hơn không?"
- "Tại sao tính năng chia sẻ tuyệt vời của chúng ta lại ít được dùng?"
- "Người dùng nghĩ gì?"
- "Chúng ta nên đặt nút CTA màu cam hay màu xanh?"
- "Người dùng ở khắp Việt Nam cảm thấy thế nào về app?"
Bài tập 4 — Ánh xạ. Lập bảng hai cột: bên trái là bốn câu hỏi bạn tạo ở Bài tập 1, bên phải là phương pháp phù hợp cùng lý do một dòng vì sao phương pháp đó trả lời được câu hỏi.
Tóm tắt
Câu hỏi nghiên cứu là la bàn của mọi dự án — đặt sai một độ, đi càng xa càng lạc. Những điểm cốt lõi cần khắc ghi:
- Phân biệt ba tầng: mục tiêu kinh doanh → câu hỏi nghiên cứu → câu hỏi phỏng vấn. Đừng nhảy tầng.
- Biết loại câu hỏi (mô tả, tại sao, so sánh, đánh giá, định lượng) vì loại câu hỏi quyết định phương pháp.
- Áp dụng bộ lọc FINER-UX, trong đó tính hành động được (actionable) là tối quan trọng ở môi trường doanh nghiệp.
- Giữ câu hỏi trung lập, mở, đơn nghĩa, đúng phạm vi; tránh câu dẫn dắt, hai-trong-một, và câu nghiên cứu-về-giải-pháp.
- Trước khi chốt, dùng bài kiểm tra "câu trả lời tưởng tượng": nếu không có hành động nào phía sau, câu hỏi chưa đủ tốt.