语音交互——GUI界面设计
编辑导语：在语音交互设计中，GUI界面设计是语音交互设计中的环节之一，其中包括了GUI容器、语音助手、播报内容与ASR内容显示等方面。本篇文章里，作者总结了语音交互设计中的GUI界面设计原则，一起来看一下。
语音交互的GUI设计相对简单，需要设计的对象主要包括了语音助手的GUI容器、语音助手和用户之间的对话流、语音助手的当前状态和播报内容，以及显示用户说话内容的ASR区域。
01总的来说，无论是手机、带屏智能音箱、智能电视或者车载系统，显示语音交互任务的GUI容器分为两种设计方式，分别是占满全屏和不占满全屏，以iOS13和iOS14的Siri为示例，请看图1：
图1iOS13（左）和iOS14（右）
图1的左侧两张图中，iOS13的Siri占据了整个屏幕大小，该设计被笔者称为“应用级语音交互”。
语音交互容器占据整个屏幕的好处是语音交互流程和其他界面分隔开，实现逻辑相对简单，同时能有更多的空间显示语音播报内容和对话流。在2018年以前的大部分智能手机和带屏智能音箱的语音助手都采用了该设计方式，还有本书出版前的蔚来汽车、荣威汽车等车载系统的语音助手也是如此。
图1的右侧两张图中，iOS14的Siri占据了屏幕的一部分显示相关内容，它的好处是比占满全屏的语音助手看起来轻量得多，但是它跟后者没有本质差别，因为它还是和其他的界面分隔开，双方的数据和交互任务基本做不到互通。
最早采用该设计方式的设备是大屏设备和电脑设备，例如AndroidTV上的GoogleAssistant和MacOS上的Siri，因为语音助手显示的内容较少，无需占满整个屏幕，相关细节请看下图2和图3。
由于绝大部分的语音交互任务无需显示太多信息，所以截至本书出版前，iOS14的Siri、Android10版本以上的GoogleAssistant、MIUI12版本以上的小爱同学以及带屏智能音箱的小度在家和天猫精灵都采用了该设计方式。
图2位于AndroidTV底部的GoogleAssistant
图3位于MacOS右上角的Siri
02是否需要展示用户和语音助手的对话流会直接影响语音助手的当前状态、播报内容和显示用户ASR内容的界面布局。
最常见的对话流设计是社交应用常用的左右结构布局，即界面左右两侧分别显示对方输出的内容以及用户自己输入的内容；而最新消息显示在界面底部，包括用户即将输入的内容，以图4GoogleAllo中的GoogleAssistant为例。
图4GoogleAllo中的GoogleAssistant（左）和用户（右）的对话流
在GoogleAllo中，GoogleAssistant的播报内容显示在左侧，用户敲打键盘或者语音转换的文字显示在界面的右侧，如果需要用户交互或者确认的内容例如选项列表，则通过另外一种显示形式穿插在双方的对话历史中，该显示方式更多是单张卡片或者由多张卡片组合而成的列表。
另外一种对话流的设计可以参考iOS13的Siri设计。
Siri可以通过上下滑动的方式查看历史对话记录，但整个设计弱化了“你问我答”的方式，并强调Siri给出的对话结果；即使对话结果不需要一屏展示，Siri也会将上一轮对话内容顶上去，如图5所示。
这样设计的好处是对话结果有更大的面积展示，同时减少上一轮对话对当前的干扰，但缺点也很明显，如果上一轮对话和当前对话处于同一任务中，两轮对话之间的关联会被削弱，如图6所示，图6-1和图6-2之间的关系明显不如图6-1和图6-3。该问题在iOS14中尤其明显，因为在iOS14中，Siri的容器不占满全屏，同时Siri会将上一轮对话出现的卡片直接消失，如图7所示。
图5iOS13Siri对话流1
图6iOS13Siri对话流2
图7iOS14Siri对话流
这里有个细节需要注意的是，前文提到语音交互是线性不可逆的，所以一般而言对话流只做对话历史展示，没有其他作用。
如果双方进行了好几轮对话后，用户回过头对之前的ASR或者某个卡片进行编辑和选择，整个对话的上下文很可能发生改变，后续的对话内容会直接作废，所以读者在设计对话流时需要考虑是否将对话流中的操作选项置灰并且设置不可操作。
03语音助手的状态类型包括唤醒状态、聆听状态、网络等待状态、语音播报状态、长连接通信状态和结束至默认状态，具体的视觉和动效设计请参考Siri、GoogleAssistant、小爱同学等语音助手的设计。
手机、电视的语音助手当前状态一般显示在界面底部，这能降低状态切换时动画效果对用户的干扰，让用户保持良好的阅读体验；相反，车载系统的语音助手当前状态一般放在对司机来说一眼就能看到的区域，例如蔚来汽车的语音助手除了在中控屏幕上方显示当前状态，还会在座舱前方中央放置一个实体机器人Nomi；而小鹏汽车G3和P7的语音助手小P也会显示在中控屏幕的上方。
如果不考虑对话流，语音助手显示在顶部或者底部都没问题，一旦考虑对话流，语音助手显示在顶部会存在一个问题：对话流中的最新内容是从上往下排序，还是从下往上排序？
一般而言，用户在社交应用的界面底部输入内容，从就近原则来说，刚发出去的内容显示在对话流底部以及输入框的附近比较符合用户的心理预期。
现有绝大部分语音助手的状态显示会和ASR在位置上强绑定，因此它们相当于一个输入框。如果输入框显示在上方，而最新的内容显示在底部，用户很有可能会觉得困扰。如果最新内容显示在输入框的下方，最新内容从上往下排序，这样的设计很有可能不符合用户的心理预期，因为笔者暂时没有看到有这样的对话流设计。
目前只有新闻的信息流会将最新信息显示在界面顶部，但概念上和对话流有着较大的差异。因此，笔者不建议将语音助手的当前状态和ASR内容显示在界面顶部的同时加入对话流的设计。
在2021年以前，无论是手机、带屏智能音箱、电脑、电视或者车载系统，绝大部分的语音助手附近都会显示ASR内容，除了iOS14的Siri以及苹果历代Carplay中的Siri。
是否一定要显示ASR内容？答案是否定的，因为不带屏的智能音箱没办法显示ASR内容也能正常使用。
在带屏设备上，显示ASR内容是否会更佳？笔者认为是的，主要原因如下：
用户能更清晰地知道对话上下文是什么，详情请对比图6和图7。当语音交互任务无法如愿完成，用户检查ASR可以知道问题出自哪。如果ASR和用户说的内容不一致，说明有可能是自己的发音或者环境噪音的问题导致语音识别出错，用户可以重新发起语音或者直接编辑ASR中的内容；如果ASR和用户说的内容一致，说明是语音助手自身的问题，与用户无关。
因此，在带屏设备上显示ASR内容有利于对话的推进。在界面设计时，通常做法会在语音助手的状态显示附近预留1-2行的位置显示ASR内容，如果内容超出了预留空间，系统会自动对ASR的前面内容做截断处理。
以图8为例，我们参考一下GoogleAssistant是如何设计ASR的。
当用户激活GoogleAssistant时，由于用户还没开始说话所以ASR内容为空。
从体验和商业两个维度进行考虑，这时候为用户提供一些提示词是有好处的；而且提示词也属于用户想说的内容，所以提示词可以直接利用显示ASR的区域，如图8中的第一张图。
当用户不点击提示词而开始说话的时候，ASR区域内的提示词会自行消失并实时显示用户说的内容，如第二张图。
当发现用户停止说话时，系统会将ASR内容和搜索结果一并显示在第三张图中，此时ASR区域会清空文字并显示相关的提示词引导用户发起下一轮对话。
图8GoogleAssistant的ASR设计
语音助手播报的内容分为两种类型，第一种类型是播报并跳转到其他应用，后续交互流程由该应用承接；第二种是在语音容器中播报并显示内容，它们分别为纯文本、图片、图文并排的内容、选项列表和网页五种形式。
iOS13的Siri通过卡片样式承载了图片、图文并排的内容、选项列表和网页四种内容，有效统一了容器中整体的设计风格，视觉效果如图9所示。
图9iOS13Siri的对话以纯文本和卡片的形式展示结果
有些语音交互的GUI设计还会考虑其他细节，例如智能座舱的语音交互存在双音区、四音区和全音区三种概念。
双音区是指语音助手识别到语音交互发起人为驾驶员时，车内的麦克风阵列会将拾音方向设定为左侧方向，这时候即使右侧的副驾和后排乘客发出指令，麦克风也无法获取他们的声音。四音区是指车内的麦克风阵列会锁定主驾、副驾、后排左侧和后排右侧四个方向，锁定后其他用户无法发出指令。全音区是指麦克风不会锁定某个方向，所有乘客都能发起语音指令。双音区和四音区能有效避免其他乘客或者车外环境产生的噪音对当前语音交互流程的影响，但有些时候其他乘客想加入到对话过程中却无法进行对话，这会引起该用户的困扰，因为这种定向声场对他们来说是无形的。
为了解决该问题，小鹏汽车P7在语音交互过程中，界面底部的左、右两侧和中间分别显示蓝色波浪效果，以表示当前处于锁定左、右音区和不锁区即全音区的状态，效果如图10所示。
除此之外，当语音助手小P完成一系列交互任务后，如果头顶上还显示着拾音图标和“继续说”时，说明小P仍处于聆听状态，这时候用户无需通过唤醒词即可继续发起新一轮语音对话。
图10小鹏P7语音交互流程展示
以上是公众号发布关于语音交互的所有内容，内容较多需要读者的慢慢消化。
总体而言，语音交互除了考虑对话的设计，还需要考虑语音助手的人设、声音、GUI等问题，设计师需要思考的问题和设计的内容远多于移动互联网应用。
无论是国内还是国外，当前语音交互处于发展前期，现阶段仍有太多问题需要探索和解决，所以它对设计师的综合素质要求较高。如果读者对语音交互感兴趣，不妨多了解这方面的知识和设计，为后续基于多模交互的体验设计提前做好准备。
#专栏作家#薛志荣，微信公众号：薛志荣，人人都是产品经理专栏作家。畅销书《AI改变设计-人工智能时代的设计师生存手册》作者，全栈开发者，专注于交互设计和人工智能设计。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
专栏作家
薛志荣，微信公众号：薛志荣，人人都是产品经理专栏作家。畅销书《AI改变设计-人工智能时代的设计师生存手册》作者，全栈开发者，专注于交互设计和人工智能设计。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
聊一聊语音交互以及语音助手
编辑导语：随着科技的不断发展，如今语音助手也频繁的出现在我们的日常生活中，比如手机的语音助手、智能音箱等等，语音助手的出现也很大程度上提高的一些效率问题；本文作者分享了关于语音交互的理解，我们一起来看一下。
“语音交互是一种简单、自然的人机交互方式，也是人类最基本的沟通方式。”
说起语音交互、语音助手，我相信大家一定不陌生。
2011年，Siri跟随iPhone4s一同发布；2014年，亚马逊发布Alexa；2018年，天猫精灵、小爱同学、小度等音箱开启疯狂补贴……如今，各种科技公司、互联网公司、车企，甚至是房地产企业都在做语音助手；你已经很难找到一台新发布，且不带语音助手的手机or汽车了。
我最早感受到语音交互的魅力是在16年，当时在做全屋智能的产品经理，公司调研产品买了一台亚马逊的echo，第一次体验到远场的语音交互，很惊艳，远场语音交互技术给了居家场景太多的想象空间。
后来国内陆续出了小爱同学、天猫精灵、小度音箱…我基本都是第一时间买回了家。
18年5月，我去了猎户星空做服务机器人“豹小秘”，机缘巧合的负责起了它的对话能力，有幸伴随它从需要“一字不差的吼着交互”，到在全国各地的落地，我可能是最清楚它的对话能力是怎么做起来的人。
19年8月，我去了滴滴，一年多过去了，也算是从0到1做了一个给司机用的语音助手（遗憾是还没有做到全国全量…）。
到现在我也算是行业老兵了，想结合过往的经历和思考，跟大家聊一聊语音交互。
这次主要想聊下面几个话题：
语音交互是什么？做一款语音助手的难点是什么？//为什么Siri、天猫精灵、小爱同学总被人说智障？可能的解决路径又是什么？//如何打造一个不傻屌的语音助手？一、语音交互是什么？交流是人们与生俱来的本能，人类大约在二岁学会说话，说话也是人与人之间主要的交互方式。
我们可以试着想一下，假如人与人之间不能说话，只能通过触摸固定的区域来交流，那世界会怎么样？我相信，你一定很难想象这会是什么样的世界；而事实上，我们现在与计算机交流的方式就是这样。
语音交互是一项人机交互技术，可以通过说话跟计算机交互来获取信息、服务等，语音交互也不是要替代触控交互，而是在一些场景中让人与计算机交互变的更简单、自然。
二、做一款语音助手的难点是什么？说起难点，我先抛几个现状：
从Google、苹果、微软、亚马逊，到国内的BAT、华为等巨头公司都有做语音助手的团队；大多用户眼中，Siri、小度、天猫精灵、小爱同学等语音助手仍然是“人工智障”；使用过语音助手的人很多（19年光智能音箱出货7200W台，城镇住房渗透率20%），但但用户活跃度低，使用过的功能也寥寥可数，主要是：听歌、查天气、订闹钟等；为什么这么多顶尖的公司，投入了顶尖的资源、顶尖的人才都没做出一款C端用户满意的语音助手？为什么在很多用户眼中都是“人工智障”？语音助手的难点又是什么？
这些问题很大，值得从业者们一起思考，这里聊聊我的思考；我认为，导致人们经常说语音助手“智障”的原因是：用户预期与实际助手能力的gap过大。
就像这张图，用户预期与语音助手能力的交集少的可怜。那么有没有可能变成下面这张图的状态？
按这个思路，问题的难点还可以继续拆解：
1.问题1：如何让用户知道语音助手能干什么？语音助手背后的技能、内容其实都已小具规模（在19年，Alexa集市就已经有了8万多个技能），但很多用户也就只会使用听歌、查天气、订闹钟这么几个技能（有屏音箱里充满了各种引导、推荐，就是试图在解决这个问题）。
而我认为这个问题最根本的原因是，大多语音助手还没有打透一个刚需场景。
像90年代初的互联网，大家也不知道互联网能干嘛，马云到处推销互联网还被骂是骗子；而随着互联网解决的刚需场景越来越多（BBS解决了社交需求、门户网站解决了获取信息的需求），也激发了更多的人去了解互联网能干什么。
所以，大多用户们不了解语音助手能干什么，本质还是语音助手没有找到一个刚需场景并打透（没有找到刚需场景，或者说没有在一个刚需场景中创造显著的体验差）。
2.问题2：如何让语音助手连接更多的服务、内容？想要回答这个问题，需要从场景深度和广度两个维度来看。
深度方面，单一场景要打通的链路很长，体验闭环难。
案例1：以家庭智能音箱的听歌场景为例，受限于音箱背后的音乐版权，而音箱没有，这会很大的影响体验；比如小爱同学，因为它连接的歌曲资源是QQ音乐，而我就没办法听自己在网易云收藏的歌单了。
案例2：在家庭照明场景，想通过语音助手随意的控制家庭灯光，需要连接整个家庭灯光照明设备，这甚至得打通装修环境，在装修时就考虑。
广度方面，用户在跟语音助手交互时，会有非常多的碎片化小需求。
案例：在滴滴的司机语音助手中，除了大家可以想到的导航场景，司机还会有各种各样的长尾问题，例如：“网约车考试的题目在哪里？”、“飞机场那边的排队区在哪里”、“帮我查一下我的预约单”等等，这些都是司机自发的问语音助手的碎片化小需求。
3.问题3：如何管理用户预期？导致用户预期过高也有两方面的原因：
一方面，用语言交流时，某种程度上人们会不自觉把“语音助手”与真实的人比较，尝试用人脑的思考习惯去理解“语音助手”，这必然会导致很多时候用户会觉得人机对话的结果不符合预期；因为目前的AI的原理和真正的人脑原理差的还很远（根本原因是科学对人脑的了解也还很初级…），再加一些科幻电影，还有媒体对人工智能概念的鼓吹…
另一个方面是语音无法设定交互边界，设计GUI交互时，我们可以定义出清晰的交互路径和边界（eg：首页只提供一个按钮）；但是语音交互你无法限制用户说什么，就像人与人的对话中，你永远无法避免别人问到你不会的问题。
4.小结用户预期与实际助手能力的gap过大，导致很多用户认为语音助手“智障”，而导致gap过大的难点是：
当前语音助手的功能普遍太鸡肋，没有找到一个刚需场景并打透，用户都懒懒得去了解它；单一场景要打通的链路很长、体验闭环难，且碎片化小需求太多；某种程度上用户的预期过高，且语音交互难以设定的交互边界。三、可能的解决路径想打造一个不傻屌的语音助手，不仅仅是打磨技术本身，有落地时对无数细节的打磨、把控，还有语音助手背后的生态…
这些都不是一蹴而就的事情，需要有清晰的目标、解决路径，然后耐心的持续投入、细心打磨。
1.找到刚需场景，打造出显著的体验差我们希望它像钢铁侠的贾维斯一样可以帮忙主人完成各种各样的任务，它就得连接到各种各样的服务，也会是一个allinone的入口。
所以，第一步也是最重要的一步，一定是找到刚需场景，打造出显著的体验差。
说到这里，想先聊聊什么是流量“入口”，举一个智能家居行业的例子，业内一直有人在讨论智能家居的入口是什么。
早期有人说是路由器、电视，后来智能音箱出现，阿里、百度、小米等公司纷纷开启补贴大战，被不少人称为“智能家居入口之争”，现在又有人讨论智能音箱作为“智能家居入口”这个命题是否成立。
我认为，决定是否能成为“入口”的不是形态，而是刚需场景中的用户体验：
互联网早期，Yahoo因为在获取信息这个刚需场景做的好，成为了一个流量“入口”；后来，Google在获取信息这个刚需场景下的体验更好，逐渐替代Yahoo为了一个流量“入口”；智能手机也是因为在通讯社交、获取信息、娱乐这些刚需场景的体验更好，才能成为移动互联网的“入口”；如果有一种新的产品形态，能比智能手机在通讯社交、获取信息、娱乐这些刚需场景中整体体验更好，那就有可能取代智能手机这个产品形态，成为新的“入口”。
再说为什么智能音箱补贴了几百亿，一年有几千万的销量，都还没成“入口”？
因为光买一台智能音箱回家它也就只能听歌、查天气、订闹钟，对于大部分用户这都不算是刚需场景；对于少部分音乐爱好者，以市面上智能音箱的音质、内容资源又无法满足需求，做不到体验闭环。
反过来再举一个例子，如果你同时买了整套的小米智能家居产品（米家电动窗帘、米家吸顶灯、米家智能空调、米家扫地机器人…..），控制灯光遮阳、控制温度是刚需，通过小爱同学控制也确实体验更好，那么在满足这个条件家庭中，小爱同学就可以成为一个“入口”。
再举一个滴滴司机的工作场景中的例子，滴滴的服务和产品模式，导致司机不得不一边开车一边操作手机（eg：要操作手机接单、要给乘客发消息、平台还时不时push一张卡片让司机点击），随着滴滴要求司机做的事情在不断增多，司机需要做的操作也越来越麻烦。
原本，你只要会开车、认路就可以当出租车司机，现在已经变成了需要“能熟练使用智能手机”才能当滴滴司机。
就像热力学第二定律，一个独立系统的“熵”永远是在增加的。不过科技的进步，总是会有把办法来解决这个问题；就像多点触控技术和触摸屏的出现，让手机再也不需要那么多的物理按键了。
语音助手是有机会在网约车司机的工作场景中降低一些操作的复杂度，来打造出显著体验差的；把其中一两个刚需场景打透（比如给乘客发送消息），做到“有用”，那么语音助手就有机会成为连接网约车司机的一个“入口”。
在其他场景中也类似，只有找到刚需并打透，才有机会成为“入口”。
2.规模化复制，带动服务者生态的建立沿着上述思路继续说，第二步核心是要解决服务的深度和长尾的碎片化小需求。
我继续拿滴滴司机的场景举例，在我们刚上线“司机助手”时，就已经初步看到了“入口”的效应。
用户会把助手当成一个“搜索引擎”，他有各种各样碎片化需求、不知道如何处理的问题时，会尝试向助手的寻求帮助，但都是碎片化小需求；类似下面的这些意图，全部加起来也只占总交互量的5%。
“飞机场那边的排队区在哪里”“我想预约安装桔视记录仪”“怎么取消预约单”“网约车驾驶证怎么办理”“驾驶证总是审核失败无法出车”“……”这些问题背后涉及的知识、服务非常多非常多。
想要把体验做好，就一定需要很多不同的部门提供深度配合，或者找到能为司机工作场景提供服务的第三方配合。
那么，想要做到“不傻屌”的程度，就得先解决服务者生态的动机问题；对于公司内部的服务提供者来说，毕竟大家都是打工人，都要收益、要晋升；对于公司外部的服务提供者也一样，最直观的就是能不能帮助他们赚钱。
所以，这里又要强调第一步的重要性，如果可以把辅助司机的工作刚需场景打磨透，实现全国全量，那么按滴滴上百万司机和超高的使用时长（普遍每天使用App8小时以上）估算，对于很多业务都算是不小的流量。
在这一步，重点是打磨工具能力，让各种各样的服务提供方可以简单、高效的接入助手；进而促进更多的业务部门通过助手为司机提供服务，实现业务价值，也进一步让助手具备了更多的能力去服务好司机。
如果能做到这一步，语音助手才算是从“有用”开始走向了“不傻屌”。
3.打造每个属于用户自己的语音助手我们想让助手每天陪伴司机、辅助工作，第三步就要开始解决交互边界的问题，即怎么让用户知道语音助手的能力边界？有一说一，还没有一个语音助手把这个问题解决好。
我在这里也只是聊聊自己思考，抛砖引玉。
身份与关系决定了人与人的交互边界，例如：网约车司机不会咨询一名乘客为什么自己接不到单子，他会去问客服。
人机交互中也一样，目前像小爱同学、天猫精灵都是“人工智能助手”的身份，关系上类似“仆从”；这个身份对语音助手造成了不小的限制，前面的“人工智能”让用户觉得你应该很厉害，后面的“助手”让用户认为我说啥你都应该听我说。
这也叫导致用户提出各自各样的开放性需求，从讲个笑话、放个屁，到查阿里巴巴的股价、马化腾是谁等等；如果语音助手听不懂、搞不定，用户很可能就会说“这都不知道？”、“智障”、“不聪明呀”…
那有没有一种理想的身份，可以能让用户的知道边界，同时又不有保留一定的拓展性？
超能陆战队大白的设定似乎可以满足这个条件，大白的设定是一个机器人，默认可以通过安装不同的芯片来实现不同的功能。
默认设置的是“私人健康助手”芯片，在电影中为了给主人公的哥哥报仇，被换上了“空手道”芯片；在动画版本中，还有“跳舞”芯片，放入后大白就拥有了跳舞能力。
这些不同的“芯片”，其实就像iPhone中的不同“App”，每个用户可以决定自己的手机上安装哪些App。
这个思路，也许可以解决语音助手交互边界的问题；我认为，语音助手跟传统的App产品不一样，不用非得保持一个固定的身份定位，可以根据不同场景提供不同的基础服务包，让用户自己决定它应该拥有哪些的技能。
早期围绕刚需场景，它可以是地图导航助手、司机工作助手等，在服务逐渐增多后，也可以由用户确定他自己的语音助手应该拥有哪些技能。
这也是为什么我在解决路径中，把找到刚需场景打透放在了第一步，把确定助手的定位放在了第三步。
4.最后，还有一个前提：对打磨技术细节的耐心和投入语音助手在落地中，有无数的细节需要把控。
我拿一个大家可能都用过的定闹钟举一个例子：
1）语义的泛化需要打磨
“定一个8点的闹钟”“提醒我9点上课”“15分钟后叫醒我”“我再睡五分钟”……想让语音助手可以准确的响应用户自然表达，就需要不断的标注、分析用户真实表达，去打磨语义理解模块。
2）回复的话术、逻辑也需要打磨
用户在早上8点说“定个9点的闹钟”，该定上午9点还是晚上9点？该怎么回复？用户在早上10点说“定个9点的闹钟”，该定晚上9点还是次日早上9点？该怎么回复？用户在凌晨2点说“定个明天8点的闹钟”，该定明天8点还是今天8点？该怎么回复？…这些case在平时生活中很常见，如果我是对老婆说，我不会特意强调是“早上”还是“下午”，她也不会纠结、不会反问我，因为她了解我的生活作息。
但语音助手需要积累，通过分析各种的用户case去制定最优的策略。
如果想要语音助手贴心一点，最好还能在不同场景给出不同的回复。例如：凌晨2点定早上8点的闹钟，最好贴心的补充说一句“不早了，早点休息”
这些都是细节，需要一点点的耐心打磨。
如果一个语音助手的负责人，只谈行业趋势、产品架构、技术架构，我会觉得很难做成；因为一个语音助手在落地的时，会有无穷多的细节问题需要把控，不仅要仰望星空，还要脚踏实地。
5.总结想打造一个聪明的语音助手，需要一个前提、三步路径。
一个前提：
对打磨细节拥有足够的耐心和投入
三步路径：
找到刚需场景，打造出显著的体验差，才有机会做到“有用”；规模化复制，带动服务者生态的建立，做到“不傻屌”；个性化，给用户属于自己的语音助手，做到“聪明”。四、其他，一些感性的故事。后面，我想分享一些与语音交互相关的感性经历。
我觉得能做一款“有头有脸”、“能说话”的产品真的特别有趣。
做豹小秘时，随着它一点一点的变好，真的会有一种看着自己“孩子”长大的感觉，每次去商场遇到它也都很亲切，会过去跟“它”打个招呼。
2020年9月我在老家办婚礼，刚好遇到一个伴娘临时有事来不了，我找了豹小秘给来当伴娘。
给你们看看婚礼现场它的照片。
婚礼当天，在门口帮忙迎宾
和伴郎伴娘们一起登台
代表伴娘发言
在滴滴做司机助手“小滴”也是一段特别的经历。
当时去滴滴面试，一面时聊了聊，发现滴滴业务场景中有很多的问题值得去解决，觉得充满了机会，很嗨。
入职后，有一个新员工培训叫“在树上”，过程中要求每一位同学都发现并提交一个体验问题发布至内网。
我就提交了一个可以用语音交互解决的体验问题。
培训的最后，每个小组需要挑一个体验问题演成“小品”，我就忽悠组员们一起用这个案例演了小品。
最后发言时，我还信誓旦旦的给大家说，这个问题我正在解决，年底（19年底）就会和大家见面；后来发现，我完全低估了要从0把语音助手落地到一个成熟业务中的难度，需要和太多的部门沟通、拉齐。
还好的是，2020年5月终于把这个功能上线并且做到全国全量了，它也是语音交互第一次在滴滴业务场景的大规模落地。
功能全量之后，我每一次打车我上车都跟司机聊天，问他知不知道、用没用过，有一次碰到个司机夸了一路这个功能好，然后我下车就给司机加了一个红包。
随着这个功能取得了不错的用户反馈，给完整司机助手也开始推进、落地，它的推进难度更大；因为它的价值难以量化，业务增长也并不需要这样一个东西。
2020年7月2日，“小滴”第一次灰度上线，那天刚好还是我的生日。
12月，因为一系列的原因，我决定了提出离职。
临走前，我也跟“小滴”说了声再见。
没有把“小滴”做到全国全量是我的遗憾，滴滴的经历也让我有些挫败。
不过回头想想，过程中也慢慢找到了自己的愿意坚持的产品理念：“不放弃对生活的热爱和执着”。
本文@常超原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。