UX Survey là khảo sát được thiết kế để thu thập nhận thức, trải nghiệm và phản hồi của người dùng về một sản phẩm hoặc một bước trong hành trình. Khảo sát tốt không chỉ hỏi “bạn có hài lòng không”; nó giúp đội ngũ trả lời một câu hỏi nghiên cứu và đưa ra quyết định thiết kế cụ thể.
Survey phù hợp khi cần quan sát mẫu phản hồi trên nhiều người, so sánh các nhóm hoặc theo dõi một chỉ số qua thời gian. Nó không cho biết chính xác người dùng đã thao tác thế nào hoặc vì sao họ mắc lỗi. Khi cần quan sát hành vi, hãy kết hợp survey với analytics, phỏng vấn hoặc usability testing.
Bắt đầu bằng quyết định, không bắt đầu bằng danh sách câu hỏi
Trước khi mở công cụ tạo form, hãy viết một câu: “Kết quả khảo sát này sẽ giúp đội ngũ quyết định điều gì?”. Ví dụ, “xác định nguyên nhân người dùng dừng ở bước thanh toán để ưu tiên thay đổi trong sprint tới” cụ thể hơn “đo mức hài lòng với website”.
- Câu hỏi nghiên cứu: điều chưa biết nào cần được làm rõ?
- Đối tượng: ai đã thực sự trải qua hành trình cần nghiên cứu?
- Thời điểm: hỏi ngay sau tác vụ hay khảo sát định kỳ?
- Quyết định: nhóm sẽ thay đổi, giữ nguyên hoặc nghiên cứu thêm dựa trên kết quả nào?
- Bằng chứng bổ sung: dữ liệu hành vi, ticket hỗ trợ hoặc phỏng vấn nào sẽ được đối chiếu?
GOV.UK khuyến nghị biến các giả định thành câu hỏi nghiên cứu, ưu tiên câu hỏi quan trọng và chọn phương pháp phù hợp với điều cần học. Đây là nguyên tắc hữu ích để tránh khảo sát dài nhưng không dẫn tới hành động. Xem hướng dẫn lập kế hoạch user research của GOV.UK.
Chọn loại UX Survey theo nhiệm vụ
| Loại khảo sát | Nên dùng khi | Rủi ro cần kiểm soát |
|---|---|---|
| Khảo sát sau tác vụ | Muốn hiểu trải nghiệm ngay sau đăng ký, thanh toán, tìm kiếm hoặc gửi form | Làm gián đoạn luồng; chỉ hỏi sau khi tác vụ kết thúc |
| Exit survey | Muốn biết lý do rời một bước hoặc không hoàn thành | Không phân biệt được người rời vì lỗi, vì chưa sẵn sàng hay đã hoàn tất ở kênh khác |
| Intercept survey | Muốn lấy phản hồi theo URL, tính năng hoặc nhóm hành vi | Mẫu tự chọn; người phản hồi có thể khác số đông |
| Khảo sát quan hệ định kỳ | Theo dõi nhận thức tổng thể theo tháng hoặc quý | Điểm tổng hợp khó chỉ ra phần giao diện cần sửa |
| Khảo sát sàng lọc | Tuyển đúng người cho phỏng vấn hoặc usability test | Câu hỏi có thể tiết lộ đáp án mong muốn và thu hút người tham gia không phù hợp |
Không nên dùng một survey cho cả năm mục tiêu. Khi khảo sát vừa đo hài lòng, vừa nghiên cứu thương hiệu, vừa tuyển người phỏng vấn và vừa thu nhu cầu tính năng, tỷ lệ bỏ dở tăng và ngữ cảnh câu hỏi dễ ảnh hưởng lẫn nhau.
Cách chọn người nhận và thời điểm hỏi
Mẫu khảo sát cần đến từ người đã trải qua tình huống bạn muốn hiểu. Nếu nghiên cứu checkout, hãy phân biệt người hoàn tất, người gặp lỗi và người rời trước khi thanh toán. Nếu chỉ mời khách vừa mua thành công, bạn sẽ bỏ qua nhóm gặp vấn đề lớn nhất.
- Ghi nguồn mời, URL/touchpoint, thiết bị và trạng thái hoàn thành tác vụ.
- Không hiển thị khảo sát ngay khi người dùng vừa vào trang hoặc đang nhập dữ liệu.
- Giới hạn tần suất để một người không bị hỏi lặp lại.
- Đảm bảo người dùng bàn phím, trình đọc màn hình và thiết bị di động có thể trả lời.
- Nêu thời lượng, mục đích sử dụng dữ liệu và quyền riêng tư trước khi bắt đầu.
Kích thước mẫu phụ thuộc mục tiêu, mức phân nhóm, tỷ lệ phản hồi và độ chính xác cần có. Không nên áp một con số cố định cho mọi survey. Nếu dữ liệu chỉ dùng để phát hiện vấn đề ban đầu, hãy trình bày nó như tín hiệu định hướng; nếu dùng để so sánh hoặc kết luận cho toàn bộ người dùng, cần kế hoạch lấy mẫu và phân tích chặt hơn.
Viết câu hỏi trung lập và dễ trả lời
Mỗi câu nên đo một ý và sử dụng từ ngữ người dùng hiểu giống nhau. Pew Research Center lưu ý rằng cách diễn đạt, lựa chọn đáp án và thứ tự câu hỏi đều có thể ảnh hưởng đến phản hồi; pretest là bước cần thiết trước khi triển khai rộng. Tham khảo hướng dẫn viết câu hỏi khảo sát của Pew Research Center.
| Tránh | Viết lại | Lý do |
|---|---|---|
| “Quy trình thanh toán mới tiện lợi thế nào?” | “Bạn đánh giá mức độ dễ hoặc khó khi hoàn tất thanh toán?” | Câu đầu mặc định thay đổi là tiện lợi |
| “Trang có nhanh và dễ sử dụng không?” | Tách thành câu về tốc độ và câu về mức dễ sử dụng | Câu hỏi kép không biết người dùng đang đánh giá phần nào |
| “Bạn có thường xuyên gặp lỗi không?” | “Trong 30 ngày qua, bạn gặp lỗi ở bước này bao nhiêu lần?” | Có khung thời gian và đáp án cụ thể hơn |
| Chỉ có đáp án tích cực/tiêu cực | Thêm “không áp dụng”, “không nhớ” hoặc “khác” khi cần | Không ép người dùng chọn câu trả lời sai |
- Đặt câu dễ và liên quan trước; câu nhạy cảm hoặc thông tin cá nhân ở cuối nếu thực sự cần.
- Giữ thang đo cân bằng, các lựa chọn không chồng lấn và bao phủ trường hợp hợp lý.
- Không đổi cách diễn đạt nếu mục tiêu là so sánh xu hướng qua thời gian.
- Chỉ dùng một hoặc hai câu mở có chủ đích; quá nhiều ô nhập làm tăng công sức và khó phân tích.
- Test survey với một nhóm nhỏ để phát hiện từ khó hiểu, nhánh sai và thời lượng thực tế.
Mẫu UX Survey 7 câu sau khi thanh toán
Mẫu dưới đây dùng để minh họa cấu trúc. Hãy thay nội dung theo sản phẩm và không sao chép nếu quyết định nghiên cứu của bạn khác.
- Bạn đã hoàn tất việc cần làm hôm nay chưa? [Có / Chưa / Một phần]
- Bạn muốn thực hiện việc gì? [Các lựa chọn theo tác vụ thực tế / Khác]
- Bạn đánh giá mức độ dễ hoặc khó để hoàn tất? [Thang 5 mức]
- Điều gì ảnh hưởng nhiều nhất đến đánh giá trên? [Câu mở]
- Bạn gặp vấn đề ở bước nào? [Chỉ hiện khi chưa hoàn tất hoặc đánh giá khó]
- Bạn đã thử cách nào khác trước khi dừng? [Nhánh phù hợp]
- Bạn có đồng ý để đội nghiên cứu liên hệ hỏi thêm không? [Tùy chọn, kèm thông tin quyền riêng tư]
Câu đầu phân loại kết quả tác vụ; câu đánh giá cho biết mức độ; câu mở cung cấp ngữ cảnh; branching logic giúp người không gặp lỗi bỏ qua phần không liên quan. Survey vẫn ngắn nhưng tạo dữ liệu dễ phân nhóm hơn một câu “Bạn hài lòng không?”.
6 loại bias cần kiểm soát
- Selection bias: nhóm nhận hoặc chọn trả lời không đại diện cho toàn bộ người dùng.
- Non-response bias: người bỏ qua survey có trải nghiệm khác người phản hồi.
- Survivorship bias: chỉ khảo sát người hoàn tất và bỏ sót người thất bại.
- Leading bias: câu hỏi gợi ý câu trả lời mong muốn.
- Order effect: câu trước hoặc thứ tự đáp án ảnh hưởng câu sau.
- Recall bias: người dùng khó nhớ chính xác trải nghiệm đã xảy ra quá lâu.
Không thể loại bỏ hoàn toàn bias, nhưng bạn có thể ghi rõ nguồn mẫu, thời điểm, tỷ lệ hoàn thành, logic hiển thị và giới hạn của dữ liệu. Khi báo cáo, tránh dùng “người dùng nghĩ rằng…” nếu survey chỉ đại diện cho một nhóm tự chọn nhỏ.
Phân tích phản hồi thành insight có thể hành động
- Làm sạch dữ liệu: loại phản hồi thử nghiệm, trùng hoặc không đủ điều kiện theo quy tắc định trước.
- Phân nhóm hợp lý: theo trạng thái hoàn thành, hành trình, thiết bị hoặc nhóm người dùng có ý nghĩa; tránh chia quá nhỏ.
- Mã hóa câu mở: tạo nhóm chủ đề, định nghĩa từng mã và giữ trích dẫn nguyên văn làm bằng chứng.
- Đối chiếu nguồn khác: kiểm tra analytics, session replay, ticket hỗ trợ, phỏng vấn hoặc usability test.
- Viết insight: nêu nhóm người dùng, bối cảnh, vấn đề, bằng chứng và tác động; tách quan sát khỏi suy luận.
Ví dụ: “Người dùng di động chưa hoàn tất thanh toán thường nhắc đến việc không nhận ra phí giao hàng cho đến bước cuối; dữ liệu funnel cũng giảm mạnh ở bước này.” Câu này hữu ích hơn “khách hàng không thích checkout” vì cho biết nhóm, điểm xảy ra và bằng chứng cần kiểm tra tiếp.
Ưu tiên thay đổi và đóng vòng phản hồi
Đưa mỗi vấn đề vào bảng gồm tần suất, mức ảnh hưởng đến tác vụ, độ tin cậy của bằng chứng, rủi ro và công sức sửa. Ưu tiên vấn đề ngăn người dùng hoàn thành nhiệm vụ và xuất hiện trong nhiều nguồn dữ liệu. Phản hồi hiếm nhưng liên quan khả năng tiếp cận, bảo mật hoặc mất dữ liệu vẫn có thể cần ưu tiên cao.
- Chuyển insight thành giả thuyết thiết kế có thể kiểm tra.
- Gắn owner, mốc xử lý và chỉ số trước/sau.
- Thử prototype hoặc usability test khi nguyên nhân chưa rõ.
- Thông báo cho đội ngũ và, khi phù hợp, cho người tham gia biết phản hồi đã được dùng thế nào.
UX Survey là một phần của quy trình UX Research. Nếu mục tiêu là đo mức dễ sử dụng và tìm lỗi tác vụ, xem thêm cách audit Usability; survey một mình không thay thế quan sát hành vi.
Checklist trước khi gửi UX Survey
- Có câu hỏi nghiên cứu và quyết định cụ thể.
- Đúng nhóm người, touchpoint và thời điểm.
- Mỗi câu chỉ đo một ý, không dẫn dắt.
- Đáp án cân bằng, không chồng lấn và có lựa chọn phù hợp.
- Branching logic đã được test; survey hoạt động trên di động và công nghệ hỗ trợ.
- Đã nêu mục đích, thời lượng, quyền riêng tư và cách dùng dữ liệu.
- Có kế hoạch phân tích, đối chiếu và owner xử lý kết quả.
Câu hỏi thường gặp
UX Survey nên có bao nhiêu câu?
Không có số cố định. Chỉ giữ câu hỏi cần cho quyết định đã đặt ra và đo thời lượng bằng pretest. Survey tại một touchpoint nên ngắn hơn khảo sát nghiên cứu được người tham gia đồng ý từ trước.
NPS có đủ để đánh giá UX không?
Không. Một điểm tổng hợp không chỉ ra bước nào gặp vấn đề hoặc nguyên nhân. Nếu dùng NPS hay chỉ số quan hệ khác, hãy kết hợp câu hỏi mở, dữ liệu hành vi và nghiên cứu tác vụ.
Nên thưởng người trả lời khảo sát không?
Có thể khi khảo sát đòi hỏi thời gian đáng kể, nhưng cần công bố rõ, tránh phần thưởng làm sai lệch tuyển mẫu và không biến ưu đãi thành điều kiện cho phản hồi tích cực.
Kết luận
Một UX Survey tốt bắt đầu từ quyết định cần hỗ trợ, hỏi đúng người ngay sau trải nghiệm liên quan và dùng câu hỏi trung lập. Giá trị thật xuất hiện khi đội ngũ đối chiếu phản hồi với hành vi, chuyển insight thành giả thuyết và đo lại sau khi cải thiện sản phẩm.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.