|
用户在查询信息的时候，除了语音播报，还会有界面的反馈，比如查询天气，会把天气信息展示出来。但是反馈界面不应该一直停留，这会让用户感觉交互没有结束，会不自觉地关注反馈界面，进而产生紧张感，这种紧张感对用户很不友好，尤其是在驾车过程中。项目管理者联盟
但语音界面也不应该不分场合地立即销毁，因为有一些反馈，用户可能会需要进一步查看更多的细节。因此，我们建立了一种语音界面销毁的范式，在不同的场景可以定义不同的销毁时间。主要分为三种情况：项目管理者联盟
立即销毁。例如35×78的结果，在TTS播报结束后，语音界面同步销毁。项目管理者联盟
延迟3秒钟销毁。例如查询天气，用户在TTS播报结束后，可能还会瞄一眼具体的信息，因此停留3秒钟让用户有机会查看。项目管理者联盟
延迟10秒钟销毁。例如打开后视镜Wi-Fi热点，在结果界面上会展示热点名称和密码，用户需要查看和记忆，界面就需要停留更久。项目管理者联盟
有一些车载产品，为了秀多轮会话的技术肌肉，将交互模式设计为全局多轮会话，用户的请求已经得到满足，但是语音交互仍然持续，并持续监听用户的语音输入，这会给用户造成极大的心理压力，也可能大概率误触发交互造成困扰。项目管理者联盟
第二个例子是列表界面的选择机制。项目管理者联盟
导航目的地、拨打电话这些场景，都避免不了会让用户从查询到的多个结果中做二次选择。要识别用户的选择，在语音实现上，有两种可选机制。bbs.mypm.net
ASR模式，即识别用户的命令在字面上是什么意思，整个过程是将声音转化成文字，再比对文字内容是否击中明确的选择项，进而触发选择。项目管理者联盟
Voice trigger模式，即把列表选择的标准说法“第一个、第二个”作为唤醒词，只需要在声音模型上满足触发的条件，就触发相应的选择。项目管理者联盟
ASR模式的好处是对用户的说法限制少，用户自由度高，同时当用户给出了错误指令时，能够针对指令的内容进行更加细致的错误引导或转到别的场景处理用户的请求。但是ASR模式的响应时间较长，尤其是在车载环境下，基于移动网络采用在线ASR，整个处理过程至少要1.5秒以上。项目管理者联盟
Voice
trigger模式的优点是离线处理，速度可以缩短到500毫秒内，不足之处是需要用户使用标准的说法，如果用户说错了，就只能给出一个标准的错误提示。转自项目管理者联盟
看起来支持更加自由的说法是更友好的做法，但是在车载场景，500毫秒和1.5秒，在用户体验上，存在巨大的差别，因为车辆在快速移动。按照80公里时速，1.5秒的时间车已经开出33米。如果一个请求，需要在跑出三四十米之后才能得到反馈，用户肯定会觉得系统响应很缓慢。因此，在这种用户记忆标准说法的困难度并不高的特定场景，选择处理速度有明显优势的Voice
trigger模式，更有助于提升用户体验。项目管理者联盟
上面的两个例子，都是从非常细微的地方，考验产品经理对用户体验的把握。training.mypm.net
用逻辑能力避免埋坑项目管理者联盟
逻辑能力也是重要的产品经理素质，事实上在踩过几次坑后，招聘时我已经把逻辑能力作为考量产品经理的首要因素，逻辑差的同学直接淘汰掉。因为逻辑能力不足的产品经理可能给产品埋下难以弥补的巨坑，导致产品甚至公司的败亡。项目管理者联盟
在车载产品中，因为声音、温度、供电、网络等外部环境都多变且不稳定，产品需要考虑的异常逻辑也特别多，这时就需要依靠产品经理的逻辑在产品设计阶段考虑到各种可能的路径，以及在出现错误的时候定位和诊断问题。项目管理者联盟
例如行车记录功能，在产品逻辑中就需要充分考虑用户可能使用的各种TF卡可能导致的问题，以及设计合理的方法进行规避。如何判断TF卡的老化、如果检测容量虚标的TF卡、如何判断TF卡内有异常文件且不影响初始化的速度、如何避免供电抖动导致TF卡mount失败...项目管理者联盟
在解决这些问题的过程中，产品经理面对了很多挑战，因为所有问题都不像表面那么简单，在解决表面问题时可能牵出更多问题或埋下新的坑。例如用遍历比对的方式检查TF卡内的异常文件，就可能导致mount
TF卡的时间增加数倍，并且在车辆启动供电抖动的情况下增大mount失败的概率。项目管理者联盟
360°无死角死磕项目管理者联盟
在我看来，经历了前面那些阶段，也就意味着产品经理在一个产品开发过程中最享受的阶段过去了。有人做产品经理时很享受产品经理的控制感，产品定义出来后，设计、结构、堆叠、生产、UI、开发、测试所有人都在按照自己的想法行动，感觉自己就是宇宙中心。项目管理者联盟
但是，产品进入开发实现那一刻，也是优秀产品经理与平庸产品经理的分水岭。因为产生好的想法、创意、思路，并不是最困难的，最困难的是不打折扣地将之实现。回头想想最经典的两个产品大神，乔布斯和马斯克，我们在谈论他们的时候，最津津乐道的是他们糟糕的性格、不讲道理的严苛、给开发团队施加超越极限的压力。这背后其实就是一次又一次与自己、与别人、与产品的死磕。真正做过产品的人会知道，哪怕最微不足道的改进，也不会是信手拈来，背后可能会有想不到的艰辛。项目管理者联盟
例如70迈智能后视镜遭遇的导航冻屏事件，整个问题的解决就持续了9个月左右时间，这中间经历了数不清的路测、数据采样、讨论分析和产品优化。在最后一次和地图合作伙伴攻坚的时候，甚至让晚上就要飞泰国三位同学临时取消行程，加入两个星期的workshop。项目管理者联盟
在解决问题过程中，不仅仅发现了我们自己的硬件、软件、供应链的很多问题，也帮助芯片供应商发现和解决了他们的定位算法问题，也帮助地图合作伙伴发现了他们代码架构的问题。这些努力不仅仅解决了我们自己的问题，也推进了整个行业的进步。芯片和地图合作伙伴的patch将会让更多的智能后视镜产品受益。项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
