文章目录[隐藏]
目录
序言
1.对话式用户界面及其重要性
2.建立友好用户界面的关键-理解对话如何进行
设计实践
3.设计原则与方法论
4.设计走查
5.设计检查表
6.用户界面工具包
最佳实践
7.像你的用户一样...有合作精神(待翻译)
8.解锁口语的力量(待翻译)
9.通过确认逐渐给用户信心(待翻译)
10.对话中是没有错误的(待翻译)
1.对话式用户界面及其重要性
我们已经进入全新并且充满希望的计算机时代,机器学习和人工智能的进步使得对话式界面和自然语言处理得以兴起,通过技术激发的对话潜能创造了一种新的交互模式。
目前,大部分识别语音输入的问题已经解决,但是怎样建立一套仿照人类自然语言的对话成为了现在新的挑战。
本网站概述了机器对话中基础且核心的设计原则,并且提供了可用于实践的用户界面工具组件,帮助你为用户建立一个具有吸引力、让用户愉悦而且能够真正帮助到用户的对话体验。
对话的基础
我们可以通过解构一些在人类自然语言中无意识遵循的规则和习俗来发现保证顺利对话的关键因素。形成良好对话的基础包括:
话轮转换
我们通过对话内容中一些微小的信号来进行轮流对话。没有有效的对话,我们将很难保持同步或者很难理解对方的意图。
[译者注:话轮是日常会话的基本单位,Nofsinger(1991)提出话轮的语言单位由任意四种不同长度的话语单位组成,分别是单词、短语、分句、句子]
贯穿交织
在自然语言中,对话中的所有元素,包括上下文和随着时间变换的对话通常都是交织联系在一起的。这种互相交织在一起的元素可以帮助我们延续对话。
借用人类自然语言与生俱来的效率
人们常常使用口头短语,是因为能够本能的理解别人所说的话。基本上,有些对话中我们可以不言而喻地领会字里行间的意思。但是这些不言而喻的语言是无法被计算的,因此基于软件系统的对话需要弥补这些看起来不合逻辑的地方。
预估多样性的用户行为
根据当时的语境和以往经验中的预期,人们常常使用不同的词汇或者不同的表达风格来讲述同一件事情,所以用户界面需要支持各种各样的情况,让所有用户都能够拥有顺畅的体验。
设计师需要在各种场景下给用户稳定的体验,即使是一些看起来错误的地方。在任何对话中都会出错,就像人们常常认识并改正自己的错误一样,设计师也必须能够帮助用户在对话中通过自然的交互方式修正错误。
在Understanding How Conversations Work: The Key to a Better UI文章中阅读更多关于对话基础的内容
理解合作行为
语言哲学家Paul Grice提出往复式的对话、语境和交织贯穿的内容都是组成合作式对话的部分。Grice称之为合作法则(Cooperative Principle)。他也曾通过观察来定义了基本的对话原则,也就是人们在与他人交流时,对话内容应该尽可能是真诚的、有益的、有意义的并且清晰的。
用户界面也需要遵循这些固有的合作式对话原则,要准备好为那些曾经在对话式界面中有过不好体验的用户服务。
在Be Cooperative...Like Your Users文章中阅读更多关于合作式对话的原则
解锁口语的力量
好的用户界面不会延续过时的设计规范,也不会基于以往按键式电话系统进行设计而导致用户只能沿着单一的路径进行操作。更不要试着通过教给用户说什么来确保不改变所谓的“愉悦路径”。
相反,用每一种语言来和用户交流,应该注意到语言直觉的力量和含义。用户界面也应该避免给用户说明或说服用户,因为用户不会感谢一台听起来比自己要聪明的机器。
在Unlocking the Power of Language文章中阅读更多关于如何建立直观的用户界面.
逐渐给用户信心
为了得到用户的信任并且增强使用时的信心,好的用户界面应该能够确认用户的输入并且管理用户的期望。
当有用户提出需求时,用户界面可以使用例如ok,sure,alright,thanks以及got it等这样的一些单词或段落来告诉用户软件正在聆听。随机地回答可以让用户拥有更加流畅自然的语音交互体验。
在回答之后,系统可以在用户说话的内容中寻找它可以理解的明确或隐晦的确认信息。明确的确认常常被用在一些有风险的事情上,例如买一张机票。在用户界面中,买机票之前会先征求用户口头上的同意。
隐晦的确认通常用在风险较小的情况中,例如播放一首歌。用户界面会把用户需求中的关键元素包含在回答中,让用户在心中默许,但是不需要用户本身口头的同意。
阅读更多:Instilling User Confidence Through Confirmations and Acknowledgements
2:建立友好用户界面的关键-理解对话如何进行
原文链接:https://developers.google.com/actions/design/how-conversations-work
“25年后,没有人会再使用点击下拉菜单这种交互方式了,但是每个人还是指着地图并且纠正彼此说话中的错误,这是人类的本能。好的信息软件应该反映人们如何处理信息,而不是电脑如何处理。”——Bret Victor
更多信息参见:http://worrydream.com/MagicInk/MagicInk.pdf
让我们看看,目前大多数的用户界面还达不到未来科幻片中呈现的那样-被人工智能包围,能够轻松地与机器人和智能家电交流。
那么我们如何才能实现呢?
在开始的时候,我们应该教给机器如何与人类交流,而不是反过来让人类学着如何与机器交流。
要认识到:对话将我们的文明推进到今天。所有人类的发明都诞生于我们口头的交流——这是一项我们演化了很久的能力,实际上已经超过100,000年。与此相比,写作大概只存在了5,000年,智能计算出现的时间则更短暂。
因此人们显然不会很快就改变他们说话的方式。不管我们能否意识到,我们在对话时,总会遵循既有的规则和习惯。如果我们能通过解构是什么构成了人类良好的对话,也许我们就能够知道怎样更好地建立关于对话的用户界面。
对话的6个步骤
话轮转换
很明显也很重要的一点是,我们的对话方式是一种话轮转换,这也包括对话中我们认为理所当然的微妙信号。是语法而不是韵律来帮助听的人预知应该何时回答,速度、音量、音调和停顿相结合都可以表明转接点要来了。人们使用这些线索将对话的接力棒在彼此之间不断传递。如果没有有效的话轮转换,我们将不能进行同步的谈话。
合作法则
语言哲学家Paul Grice的研究也可以被应用在人工智能中,人们之间需要用合作的表达方式来帮助彼此相互理解。他提出了很多合作式对话的基础原则,并称之为Grice法则。人们要根据当时的情况尽量真实的、详尽的、清楚地进行表达,同时还要表明其它与此相关的信息。
在Be Cooperative...Like Your Users文章中阅读更多关于合作式法则的内容
语义和语境
对话的意义取决于它的上下文。但通常在对话中有些我们没有说出来的部分其实也是有意义的。
例如你问一个朋友“周六有时间去一个party吗?”,她回答道”我上夜班。那么”你朋友表达的意思就是她不能同时在两个地方出现,所以你可以推断她不会来参加party。
或者在另一种对话情况中,当别人问你有几位需要预定时,你回答“oh,只有我和我丈夫”,这说明你希望对方能够知道你想在party上预定两个人的位置。
如果没有这些推测和对话法则帮助我们理解,我们的对话可能需要一些文字以外的帮助才能进行。
贯穿交织
对话中所有的内容都是紧密联系在一起的。就像喜欢冷笑话的人都知道,每轮对话中贯穿的上下文可以帮助理解整体内容的关联性。
为了做到这一点,设计师需要注意到每一个回合的对话(称之为毗邻语对),就像下面的示例:
[译者注:毗邻语对在会话过程中的话轮转换通常是指发话人的变更或指当前发话人结束发话并由受话人开始发话,而这种呼应关系因会话序列类型不同而有强弱之分,其中呼应关系最强的就是毗邻语对]
不需要问题-答案一一配对。听者也可以从毗邻语对中发出对话信号:
对刚刚所说的内容赞同或否定也是如此
如果用户界面不能提供一个良好的对话方式,那么对话很快就会进行不下去或者变得无聊。因此贯穿交织是形成一个有吸引力的体验最基础的工具,例如在这个游戏示例中这样:
在design walkthrough中查看我们如何在猜数字这个游戏示例中实践。
修复
没有共同点也会破坏彼此的对话。违反Grice合作式对话的法则有可能会出现不恰当的表意。例如,如果一个人问“你知不知道谁会参加这个party?”然后他简单的回答“是”,这就是非合作、不自然的对话,很难修正这种对话。
在Be Cooperative...Like Your Users,Unlocking the Power of Spoken Language和In Conversation, There Are No Errors中阅读更多关于修复策略的内容。
概要:对话是你用户界面的基础
对话是一种基于原则的相互协调和协商的过程。各方在丰富又有细微差别的语境下建立并达成一致。理解这一点可以帮助你根据该理论模型设计你的对话式用户界面。
3.设计原则与方法论
我们所推荐的设计过程提供了一种简单的用例思考过程,确保他们听起来很自然,并且帮你在设计语音操作时能给开发人员提供完善的参考。
主要的步骤是:
· 选择正确的用例
· 创建一个用户画像
· 编写对话
· 进行测试
· 构建和迭代
优化对话:选择正确的用例
用户决定使用对话式界面而不是传统的用户界面时会进行有意识的权衡。他们常常匆忙出门,目光需要看向别处或者手里拿满了东西,因此没有时间通过浏览网站来获取信息。
不要将现有的移动或桌面app的用户界面直接转换为对话。因为当对话基于另一种交互模式时,它的速度和简单性都容易变得复杂。
这里是一些关于哪些类型的用例可以比较好的转换为对话式交互的指导原则:
· 不经过考虑就可以回答。一些常规信息的输入操作,例如基础的用户信息、位置、时间和日期等。用户已经知道这些信息很好处理也很好保存,所以在以后用到此类信息时应尽量缩短反馈的时间。
· 快捷、强制性、有用的操作。这样的操作通常可以让用户花费较少的时间。例如,花几秒钟订餐,然后30分钟后就出现在用户面前,或者几分钟内在家门口叫到一辆出租车。其它便利的操作例如寻找答案、快速计算、记录或跟踪信息,以及各种可以为了避免因为拿出手机或一张纸而打断另一个任务的情况。
· 适合语音的操作。一些为了解放双手的情况,例如在做饭时听菜谱或者开车时做笔记。这些用例可以很好的将需要在屏幕上交互的事情转换成语音来完成。因为在屏幕上完成这些任务需要快速点击以及手势操作,而如果用户界面可以进行快速、解放双手的交互时就可以很简单的完成了。
建立用户画像
在建立您的对话界面前,先想一想你希望你的对话可以给用户带来什么样的感觉,它听起来应该是什么样的。如果你要设计一个好玩的游戏,你可能需要使用一种有意思的音调。如果你要设计的是新闻播报,那你可能需要使用更加谨慎、认真的音调。
用户画像可以帮助你设计并且编写对话,所以要尽早选择一个用户画像,它可以帮助你更容易的选择正确的词汇、语法和结构。记住,无论你是否计划使用一个用户画像,用户总会察觉到这个用户画像场景的存在。对你的品牌至关重要的是你希望用户能够体验到你希望他们感受到的,所以你要去建立这种体验而不只是靠运气。
选择你需要的声音
你可以从下列示例表格中听到虚拟助手提供的用来匹配用户画像的不同声音。在customizing TTS voice中查看更多关于怎样设定用户画像声音的信息。
在该链接中可听取示例音频:https://developers.google.com/actions/design/principles
编写对话
现在你已经选择了几个用例并且决定了用户画像,也许你想要快点开始开发,但是不要这么快地推进。
你应该拿纸笔或者其它可以用来快速记录的工具,先起草一份对话的内容。
一开始,你需要写下来一些用户可能说到的、独立的对话内容。这里是一些对话类型你可以进行参考:
1.给用户提供“愉悦路径”;不能太复杂并且能够很简单的完成。
2.其它的路径也会让用户在最后得到与“愉悦路径”一样的结果。因为每个用户的行为不一样,有的用户一次说一点信息,而有的用户一次性把信息全部说完。
3.在出现不能支持或不能理解用户的情况时,需要去修复对话。
4.当用户得到自己想知道的信息后会在中途或者最后结束对话。考虑一下怎样确认对话已结束。
5.怎样问候用户以及功能如何被唤醒。在Invocation and Discovery中查看关于用户如何唤醒功能以及各种不同方式的开场对话。
6.当你确认了系统听起来应该是怎样之后,你应该考虑一下对话如何出现在设备屏幕上。Google提供了各种不同的操作,可以使用手机上的音频和视觉组件。例如,和屏幕上的内容相比你希望你的TTS回答一些不同于屏幕上显示的内容。在必要时,你需要为带屏幕的设备创建完全不同的对话。当你使用纯音频设备时只需要一个简单的体验,这很节省时间,例如快速为近期的项目排序,但在有音频和屏幕输出的设备上可以设计一个完整的购物车使用体验。
进行测试
测试你的App实际上比你想的要简单。你需要找一些没有参与开发的人。让他们在没有任何提示和线索的情况下使用App。进行几次这个过程可以发现一些问题,例如哪些对话任务难以完成或者反馈声音与用户之间的交互如何。
之后,去了解他们个人的反馈。在哪里被卡住了?对“关闭”什么感觉?类似反馈未来将会从更多的用户那里得到,而你在发布App前就可以得到这些有价值的信息。
遵循的设计原则:
保持简短
尊重用户的时间。从核心上快速解决问题
让用户信任
人们了解语言并且知道怎样说话。避免告诉人们怎样说话,而是要更专注于如何用更自然的方式继续推进对话
相关性优化
对用户当前的需求和所处环境保持敏感,提供相关性的内容
听起来舒服且不会打扰用户思考
当加入性格特性后,要确保它不会太影响用户完成任务
同时吸引新用户和专家用户
为很多人设计并不是只满足最低水平的共同需求
轮流对话
不要着急回答。如果轮到你问用户一个问题,不要在用户正在回答问题时额外加一个指示来阻碍他们
不要猜测用户心思
告诉他们事实并且让他们自己决定
用户界面可做与不可做
4.设计走查:完善对话
这个指导将引导你通过猜数字游戏这个例子来了解设计一个对话操作时要注意的关键思路和最好的实践方式,你可以借此来建立一个更棒的体验。
在开始之前,你需要熟悉我们推荐的设计过程方法论。主要的步骤是:
· 选择正确的用户用例。对话界面通常是简单直观的,不太复杂,用例可以很顺利的完成。
· 建立用户画像。对话操作的表达方式和功能具有一致性,要有独特的品牌展示和特性
· 编写对话。走查大量编写的对话,给出最佳实践方案
· 进行测试。大声读出来对话,用我们的模拟器进行测试并且确保它听起来是健谈的。
· 构建与迭代。在API.AI或你自己的工具中使用Actions SDK。
选择正确的用例
完成游戏任务的风险较小,但是用户很容易感到厌倦,因此对游戏的用户界面吸引力期望就会很高。
猜数字游戏是很直观的对话可以作为很好的起点,因为他不需要用户有任何行业的背景知识。因此提供了探索和测试用户界面边界的机会。
建立用户画像
用户画像可以帮助你设计和编写对话,所以要尽早选择一个用户画像,它可以帮助你更容易的选择正确的词汇、语法和结构。
我们游戏的用户画像具有以下特点:
· 乐观、活泼以及令人鼓舞
· 有吸引力又诙谐可以让游戏一直进行下去,并且鼓励探索
· 不使用过于正式的语言而是使用适应各个年龄层人的简单语言
我们叫它“数字精灵”让他更加具有人性,基于用户对“魔法”的共同理解以及对猜测类游戏固有的期望。
提示:
即使你认为它不具备“人格”,要记住,无论你是否有一个用户画像,用户都会在简单的对话交互中感知到它的存在,所以我们推荐给你一些想法。在我们的对话设计技巧视频中查看建立用户画像时的具体建议。
编写对话
现在我们已经选定我们游戏的用例也决定了用户画像,我们准备开始按照对话示例的格式编写用户路径。
我们为数字精灵游戏想出以下对话作为起点。让我们一步一步从这些对话中理解并揭示我们的设计思路和最佳实践。
路径1:愉悦路径
描述了一局游戏猜了3次的典型对话
现在干什么?开始写代码?
到此为止很不错对不对?但是如果我们在这就停止然后开始构建所谓的“愉悦路径”,那这将是一个非常无聊的游戏。用户可能有99个回合的对话(或者更多,如果你猜的数字超过100),所以我们有很多机会在对话中添加趣味性,让用户沉浸其中。
路径2:两个回合的愉悦路径
描述了一个用户在两个回合中猜了很多次。
不断变化你的用户画像
想要把性格交织在对话中,需要比前面多一些来回的对话。这样做不仅能让游戏变得独特还能增加新增一些处理特殊情况的需求。
路径3:探索性的猜测
这个对话描述了用户随机猜测,然后数字精灵提供一些线索来帮助用户猜到正确的数字(在这个案例中,是23)。
让用户走上正轨
有时候用户想要尝试你系统操作的边界,想看一下边界情况是什么样的以及感觉如何。这个路径告诉我们当增加了一些变化和违反提示的情况时,应该怎样引导用户猜到最终的结果。
路径4:修复超出游戏背景的对话
修复“错误”
在Conversation Repair中阅读更多内容
路径5:修复时间耗尽时的对话
路径6:用户猜测同一个数字三次
处理“不好”的输入
因为这是个游戏,在设计中我们可以用有意思的引导方式来处理边界情况。因为我们的目标用户是这些喜欢用各种方式“挑战极限的人,所以这些边界情况都值得被尝试,比起另一种类型的操作我们可能需要更多的满足他们。你需要注意到,这种错误与路径3的情况很相似。当把这些对话转化为代码时,记录下来这些类似的类型然后看看你是否可以优化你设计代码的方式来解决这些问题,让变化表现出来。
路径7:结束游戏。用户放弃或者结束游戏
进行测试
现在你已经有一些不错的对话,试着大声把它们读出来。在之前提到的编写对话的原则中你会倾向于使用书面英文,每个对话都用这样的方式,可以帮你找到不合适使用这种方式的对话。除了大声练习,你还可以用Google Home Web模拟器来输入你的对话然后让他们读出来。模拟器也是一种很好的方式来测试文字转换为语音后听起来如何。你也许会在这一步之后再调整措辞。
使用Google Home Web模拟器
更多阅读资源
在测试完对话后,你可能为了让对话进行的更平稳而想要细化和构建场景。建立一个自然地、简单好用的对话式界面通常比看起来更困难。花时间去精细化你的界面,尽量为用户提供最好的体验。这里是一些可以帮助你着手设计的话题:
·对话式用户界面及其重要性
·设计原则与方法论
·建立友好用户界面的关键-理解对话如何进行
·像你的用户一样...有合作精神
·解锁口语的力量
·通过逐渐给用户信心
·对话中是没有错误的
5.设计检查表
这个检查表可以快速帮助你确保功能已经可以分发给用户了,也能帮助我们评估你的功能是否已经可以提交批准。我们推荐你按照这个设计流程来开始。
6.用户界面工具包
Sketch用户界面模版
使用sketch模版来设计手机端的用户界面
买卖交易参考示例
下面展示的示例可以帮助你设计你的对话。为了充分利用这些示例,可以安装Chrome插件Speak in Slides,在看用户界面的同时听一下TTS的音频。
原文链接:developers.google.com/actions/design/
- END-
译者 阿呜GXR
转载自公众号 阿呜GXR
欢迎将文章分享至朋友圈,拒绝转载~
达尔文老爷爷说,你的语音交互设计该进化了~
长按指纹 > 识别图中二维码 > 添加关注
不关注,怎么进化~
原创文章,作者:交互精选,如若转载,请注明出处:https://www.iamue.com/35327/