Xác nhận

Xác nhận cung cấp cho người dùng phản hồi về cách hiểu đầu vào của họ. Điều này không chỉ giúp người dùng sửa lỗi ngay lập tức mà còn giúp họ yên tâm về mặt xã hội và giao tiếp bằng cách thiết lập cơ sở chung. Ngoài ra, các thông báo xác nhận giúp duy trì chuỗi trao đổi trong cuộc trò chuyện bằng cách duy trì ngữ cảnh.

Xem thêm Bạn có thể nói lại điều đó: Vai trò của việc lặp lại trong thiết kế cuộc trò chuyện của James Giangola, Trưởng nhóm thiết kế cuộc trò chuyện và cá tính @ Google

Bạn cần xác nhận 2 loại nội dung:

Các thông tin chính được nói hoặc ngụ ý.
Ví dụ: giày chạy bộ nam (kiểu giày), xanh dương và xanh neon (màu)

Nội dung mà Trợ lý sắp hoàn thành hoặc đã hoàn thành.
Ví dụ: Thêm một phiên vào lịch biểu của người dùng

Và có 3 cách xử lý chúng:
Yêu cầu người dùng trả lời để xác nhận (“Tôi đã hiểu đúng tin nhắn chưa?”. Thường là có/không hoặc một số từ đồng nghĩa.
Không yêu cầu phản hồi từ người dùng, mặc dù người dùng có thể đưa ra câu trả lời nếu họ muốn chỉnh sửa (“không, 3 người”). Bạn chỉ cần xác nhận (“dành cho 2 người ngồi cùng nhau”) và tiếp tục. Trong ví dụ này, bước tiếp theo là xác nhận rõ ràng việc mua những người dùng cụ thể này.
Không có xác nhận công khai (của mã zip).

Mức sử dụng

Một số loại xác nhận thường xuyên hơn nhiều so với các loại khác. Dưới đây là danh sách cách sử dụng xác nhận, từ các trường hợp phổ biến nhất đến ít phổ biến nhất:

Trong hầu hết các trường hợp, không phải để xác nhận dữ liệu đầu vào của người dùng, mà để xác nhận các thông số đã nói hoặc ngụ ý. Người dùng cần có ngữ cảnh thì mới hiểu được phản hồi.

Nên.

Việc xác nhận số dự đoán đảm bảo cho người dùng đã hiểu chúng và giúp đưa ra dự đoán tiếp theo của họ.

Không nên.

Đừng trả lời xác nhận bằng cách tập trung vào nội dung Hành động của bạn đã nghe hoặc những gì người dùng nói.

Xác nhận rằng một hành động đã được hoàn thành (trừ khi hành động đó hiển thị).

Nên.

Xác nhận rằng thông tin chi tiết đã được gửi và cho người dùng biết họ đã gửi ở đâu.

Không nên.

Người dùng có thể không tin tưởng rằng các thông tin đã được đặt.

Sử dụng khi hành động/phản hồi thể hiện rõ ràng rằng bạn hiểu người dùng. Điều này đúng với các lệnh chung như “dừng” hoặc “hủy”.

Nên.

Theo mặc định, Hành động của bạn sẽ rời khỏi cuộc trò chuyện. Xem lần thoát ứng dụng.

Không nên.

Hành động của bạn không thể buộc người dùng tiếp tục cuộc trò chuyện.

Không xác nhận nếu thông tin đầu vào đơn giản và thường được nhận dạng với độ tin cậy cao, chẳng hạn như có/không có ngữ pháp.

Nên.

Xin lưu ý rằng câu trả lời của người dùng là "có" chưa được xác nhận.

Không nên.

Không xác nhận ngữ pháp có/không, tức là “Ok, có”.

Kiểm tra kỹ với 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 tất giao dịch, v.v.

Nên.

Xác nhận một cách rõ ràng trước khi xóa dữ liệu người dùng. (Ngoài ra, xin lưu ý rằng việc không huỷ gói thành viên này đã hoàn toàn được xác nhận, vì vậy không có sự không rõ ràng.)

Không nên.

Sẽ rất khó để khôi phục từ một lỗi ở đây. Việc tạo tài khoản thành viên mới sẽ tốn thời gian và thông tin liên kết với tài khoản sẽ bị mất.

Sử dụng một cách tiết kiệm, chỉ khi chi phí hiểu nhầm người dùng cao, ví dụ như tên, địa chỉ, văn bản sẽ được chia sẻ thay mặt người dùng.

Nên.

Xác nhận chính xác thông báo sẽ được gửi trước khi gửi vì người dùng không thể sửa thông báo sau khi gửi.

Không nên.

Ở đây, người dùng không rõ nội dung của thông báo. Nếu xảy ra lỗi, người dùng sẽ không bao giờ biết được trừ khi Lola (người nhận) nói điều gì đó.


Số tiền điều chỉnh

Dự kiến người dùng sẽ thực hiện chỉnh sửa sau các xác nhận rõ ràng và ngầm hiểu khi có sự hiểu lầm hoặc hiểu sai ý của họ. Giúp người dùng có cơ hội thực hiện thay đổi ngay cả khi không có sai sót.

Đề nghị người dùng sửa đổi tuân theo Nguyên tắc cộng tác bằng cách nói "không", theo sau đó là sửa của họ (ví dụ: "Không, 7 giờ sáng"). Đây được gọi là chỉnh sửa một bước.

Nên.

Cho phép người dùng thực hiện chỉnh sửa theo một bước.

Không nên.

Câu trả lời của người dùng bị hiểu sai thành “không” đối với câu hỏi “Liệu tất cả có giống như vậy không?”

Cho phép người dùng thay đổi bất kỳ thông số nào (những thông tin chính được nói hoặc ngụ ý).

Nên.

Phân biệt những gì người dùng muốn sửa và yêu cầu thông tin mới.

Không nên.

Không hủy và buộc người dùng bắt đầu lại hộp thoại, trong trường hợp này bằng cách tạo một bó hoa tùy chỉnh mới.