Câu hỏi
Câu hỏi trọng tâm
Các câu hỏi được đánh giá liên tục từ trọng tâm rộng đến hẹp, dựa trên phạm vi phản hồi mà chúng tạo ra.
Khi thiết kế câu hỏi, hãy nghĩ về vị trí nên đặt câu hỏi liên tục từ trọng tâm rộng đến hẹp. Hãy xem xét các ưu và nhược điểm trong bảng bên dưới.
| Ưu điểm | Nhược điểm | |
|---|---|---|
|
Câu hỏi trọng tâm
Phù hợp nhất với các câu hỏi về những miền quen thuộc với người dùng và do đó dễ trả lời. |
|
|
|
Câu hỏi trọng tâm
Phù hợp nhất với các câu hỏi về miền phức tạp hoặc miền lạ, hoặc khi tùy chọn bị hạn chế hoặc không rõ ràng. |
|
|
Suy nghĩ về những điều người dùng có thể nói
Trước khi đặt câu hỏi, hãy nghĩ về những câu trả lời bạn có thể hỗ trợ một cách hợp lý. Không đặt câu hỏi cho người dùng nếu bạn chưa sẵn sàng xử lý câu trả lời của họ.
Vì vậy, đừng ngại đặt câu hỏi cho người dùng—không có nghĩa là bạn phải ủng hộ mọi phản ứng mà bạn có thể tưởng tượng. Cách diễn đạt câu hỏi đặt ra kỳ vọng của người dùng về những gì họ có thể nói. Cụm từ này có thể bao gồm các câu hỏi kết thúc mở hoặc trọng tâm rộng, đến các câu hỏi kết thúc mở hoặc câu hỏi trọng tâm hẹp.Điều kỳ diệu và nghệ thuật của thiết kế hội thoại tốt là người dùng cảm thấy như họ được kiểm soát và họ có thể nói bất cứ điều gì vào bất cứ lúc nào, nhưng trên thực tế, hộp thoại sẽ hướng dẫn họ dọc theo các đường dẫn được viết sẵn.
Không tiếp tục nói sau khi đặt câu hỏi
Nên.
Nhắc người dùng chỉ bằng một câu hỏi tại một thời điểm.
Không nên.
Đừng cho người dùng thấy quá nhiều lựa chọn và câu hỏi.
Các trường hợp sử dụng quan trọng cho câu hỏi có trọng tâm thấp
Xử lý lỗi
Khi đặt câu hỏi lần đầu tiên, cá tính chỉ nên đưa ra các thông tin cần thiết để tiếp tục.
Khi xảy ra lỗi, hãy thu hẹp trọng tâm của câu hỏi để hỗ trợ nhiều hơn và giúp người dùng quay trở lại đúng hướng.
Xem lỗi để biết chi tiết.
Nên.
Trợ giúp thêm khi xảy ra lỗi.
Không nên.
Không làm chậm tất cả người dùng bằng các thông tin chi tiết mà hầu hết không cần trả lời câu hỏi. Hãy nhớ, giọng nói không liên quan sẽ tốn thời gian.
Phân định
Nên.
Để giải quyết sự mơ hồ, hãy đặt cho người dùng một câu hỏi chuyên sâu.
Không nên.
Yêu cầu của người dùng không rõ ràng. Phản hồi này sẽ phù hợp nếu trước đây người dùng đã đặt mua hoa hồng hồng cho mẹ của chúng.
Xác nhận rõ ràng
Mặc dù không phổ biến, nhưng các câu hỏi xác nhận rõ ràng là cần thiết trong những trường hợp sau:
- Khi người dùng phải trả phí cao để hiểu nhầm (ví dụ: tên, địa chỉ, văn bản sẽ chia sẻ thay mặt người dùng)
- Trước khi thực hiện một hành động khó hoàn tác (ví dụ: xóa dữ liệu người dùng, hoàn thành giao dịch)
Xem xác nhận để biết chi tiết.
Nên.
Trước khi xóa dữ liệu người dùng, hãy sử dụng các câu hỏi có tiêu điểm hẹp để xác nhận.
Không nên.
Sẽ rất khó để khôi phục từ một lỗi ở đây.
Học hỏi từ những điều người dùng nói
Thông tin chi tiết thu thập được từ dữ liệu của người dùng là vô giá, giúp làm sáng tỏ cách diễn đạt tốt hơn các câu hỏi của bạn. Các công cụ phân tích và giám sát có thể giúp bạn tìm hiểu hiệu quả hoạt động của các câu hỏi. Xem lại tất cả các cách phù hợp của người dùng. Ngoài ra, hãy tìm những dấu hiệu gây nhầm lẫn cho người dùng—ví dụ: có thể người dùng không phản hồi (Không có thông tin đầu vào), họ mất nhiều thời gian để phản hồi hoặc do dự, sử dụng những từ đệm như ừm và à.
Có 3 phương pháp chính để xử lý các phản hồi không được hỗ trợ:
- Thêm từ đồng nghĩa mới vào ngữ pháp để khớp với chức năng hiện có
- Giới hạn phạm vi phản hồi mà người dùng có thể đưa ra bằng cách thu hẹp trọng tâm của câu hỏi
- Thiết kế một phương thức trò chuyện mới để hỗ trợ chức năng mà ứng dụng yêu cầu
Nên.
Diễn đạt lại các câu hỏi để làm rõ các tùy chọn.
Không nên.
Thông thường, ngữ điệu và ngữ cảnh sẽ nói rõ với người dùng rằng đây là câu hỏi/hoặc câu hỏi chứ không phải câu hỏi có/không. Tuy nhiên, nếu người dùng gặp sự cố, hãy xem xét diễn đạt lại.