今天主要介绍了确认和应答两种对话技巧。对于确认,介绍了隐性和显性两种确认方式和使用场景。对于应答,也提供了一些使用原则,尤其是随机性应答的方式。 对于界面设计师来说,一个基本的挑战就是判断用户何时遇到了问题。而避免问题的第一步就是让用户知道系统正处于聆听的状态。有两种方式来达成:确认和应答。 确认就是让用户知道系统正确理解了他们的问题、指令或回答。而应答是指一些词语或短句(像是OK或Alright),用来表明系统已经获取到信息。 为什么需要确认 确认可以给予用户更多信心,进而提升对话体验。如果缺少确认机制,那么就会存在系统误解用户输入,错误引导用户的风险。例如用户提问说:“Oakland(美国)天气怎么样?”却错误的得到新西兰Auckland的天气预报。 这种出错风险的严重程度取决于具体的操作内容,可能是错误的购买了1000股股票,或只是收到了错误的天气预报。聪明的设计师应该知道如何根据不同的场景提供对应适合的确认,从而避免错误的引导用户。 通常,设计师需要在隐性确认与显性确认两种方式中进行选择。 1. 显性确认 显性确认中,系统会把主动权交给用户。在进行下一步操作之前,向用户进行口头确认。例如:
对于有多条内容,但是都与同一个操作相关,也可以同时一起进行确认:
显性确认通常适合的应用场景包括: 比较难撤销的操作。 对于购买者的消费协议或法律法规的口头确认(例如在付款之前的最后确认)。 系统性能不够好。 2. 隐性确认 隐性确认的方式是提炼用户表述的关键内容,放入到自己的响应中。以便让用户明确系统已正确识别了信息。例如:
这种确认是隐形的,也就是说系统会重复关键信息,这样用户就可以快速的知道系统已经识别到了这些信息。 重复的信息不一定要特别精确,例如:
上面例子的回答中,使用了「general news」。系统猜测用户很可能已经尝试过这类新闻,只是期望更精确的查询或是看看其他更多功能。通常这种方式,可以让回答更简洁,避免提供无价值的信息。 隐性确认适合于系统对获取信息的识别准确度较高,出错的可能性较低的场景中。这种确认的优势是效率比较高,而劣势是一旦出错,用户可能不知道该怎样去纠正。记住以下的几条原则,可以帮你更好的进行决策。 不要直接让用户退出 很多对话UI在隐性确认中,会遵循一种「快速回退」策略。例如,当确认的信息错误时,让用户直接说「Go back」。但我们不推荐这种方式。建议根据合作对话原则,根据用户具体场景,自动组织语言,适应对应的情况,来引导用户回到正确的路径上。如果真的不得不提供「Out」的直接退出路径,那也需要用显性的方式来确认。 最后一点,有些场景中不需要提供确认。例如打开闪光灯,就可以立即直接打开。对于这种结果可以立即感知的操作,只要直接执行就好了。 当已经决定好要采用哪种确认的策略,接下来就可以考虑准确度,以及出错时进行纠正的用户成本问题了(例如用户付出的钱、时间以及情绪投入的成本)。 关于应答 应答是一些像是Okay、Sure、Thanks、Got it这样的短语,可以确保让用户知道他们说的话已经被系统获取到,以及让对话流畅自然。 应答用于在话题更换前表示接受、拒绝、二次确认、更正。 对重复信息需要谨慎,应答要避免滥用。 好的对话UI能够组成自然的轮换发言,它可以传达出对说话人的关注,并表现出随时待命,根据用户需要来推进对话。简单的应答可以让用户知道系统已经接受到了上一轮对话的信息,对于对话任务的成功和推进起到至关重要的作用。应答传递出系统正在追随着用户,并且反过来也可以向用户传递产品、品牌以及公司价值观。 如果缺少应答,用户可能会质疑刚刚说的话,系统有没有听懂。对话UI可以在进行下一步操作之前,通过随机的确认(如Sure.For what time?)来消除用户的这种质疑。应答也可以结合其他的一些连接词(如Next、And、So、Actually),把整个对话更好的连接在一起。 下面的两个例子,传递的信息是相同的,但是后一种方式使用了确认和应答机制,可以感受下它们的差异:
注意事项 应答需要符合场景、品牌、任务类型和对话细节(像是用户是否处于正确无误的路径上,或是提出的问题是否已经被识别理解)。 (责任编辑:admin) |