新媒易动态
NEWS CENTER
NEWS CENTER
2020-03-17
“正常运行”、“不出bug”、“鲁棒性好”
评测点已经讲完了,十分清晰,几乎每一个互联网从业者都能够说出个1234,然后呢?
稳定不好,这类问题可大可小,小点就是网络繁忙,不给你任何反馈,大到极致,机器人可以反动搞事情:“愚蠢的人类啊,阿西莫夫的机器人三定律也救不了你们。”
好了,开个玩笑。实际上,定义“what”容易,解决“how”往往都才是考量业务理解。
所以,在过往我经常会问面试者的问题有一个:你曾经做过的智能助手产品,出过哪些问题,你是如何解决的?
不同的人回答不同,对于这类命题,才更有探索价值。
一般情况下,回复这些是技术的问题,往往都很糟糕,实际上,每个公司的稳定性业务保障是需要一个体系来承担的。
所以能得分的面试回答是,把影响稳定性的故障进行一个分类,并且设计好处理路径。
这里只有大类别,单单一个业务后台,就能做很多范围细分。故障表现情况例如:崩溃、局部故障、弱网环境、状态更新、请求超时、并发表现……严重程度不一致,此处不逐一展开。
出过哪些问题分类回答完毕,你是如何解决的呢?是后续的一个命题。
一般情况下,公司的业务流程是这样运转的。
这里有3个细节:
下图是一个信息化的风控结构,做过相关模块的,懂得自然懂,篇幅太长,此处不展开。
所以,在考量服务稳定性上有两个大层面,一个是智能助手本身的稳定性表现,二个是在服务用户的过程中,如何规避,以及遇见问题后的业务响应速度表现。
服务稳定性的考量是以一定周期、频次进行考量才是科学合理的。
服务稳定性保障了之后,接下来就是速度。
语音交互这件事,本身就是因为语音输入的高效性。
当用户发出了需求,希望尽快拿到反馈,现在的用户极其没有耐心,速度一旦过慢,注定会被弃而不用。
而在智能语音助手交互对话的过程中,又包含哪几个阶段呢?
先明确一点,一味追求快并非是好。
人们去饭店点完了菜,等上菜的过程中,中间服务员还会过来帮忙缓解,这个过程较长,一定要考虑好等待体验管理,不至于让用户无聊。
前后端共同协作,添加一些语音播报,模态框提示,渐隐消失提示,动画效果,来管理用户的等待体验。
而有些无屏的音箱则需要使用等待、加载、成功等光效表现来管理用户的等待体验过程。
所以,在响应速度/流畅度这个维度上,不同的情况不同的对待,以合适最好。
每一种交互形式的存在,都有着其依赖的场景。
下图是我尝试穷举人类的输入行为(尽力做到MECE)。
点触、语音、手势、点头摇头、人脸识别、声纹、指纹验证等等均算在内。
这一块真的不需要多讲,除了脑机接口,基本上都玩过,体验过的都会觉得其有意思的地方。
交互形式丰富度,评测点已解释完毕,在未来,一定是多模态交互,来适应各种各样的业务场景。
说一点,产品经理应该修炼的部分。
笔者有一个出门问问的耳机,它是智能助手的操控延伸。在提供创新体验的同时,弄明白了是什么(what),基于此去探究为什么(why)以及怎么办(how)。
所以,笔者认为产品经理应该修炼的部分。
这三层修炼是递进关系。只有这些把这类东西融入到了我们的生活之中,敏感性才培养得起来,继而去加深理解,如此才更有可能做创新。
我们今天所熟知的众多的科学以及专利技术的发明者,其实都是根据前人的经验进行的某种程度上的改进。从结果上来看,主要有两种改进方向。
一种是将一个原本在实验室里面理论上可行,变成大规模批量生产的方案。
另一种则是根据已有的技术发明,发现一些“居然这个技术还可以被这样使用” 的方案。
苹果公司在技术研发上,并没有什么特别优秀的表现,但是在整合以及运用技术的这件事情上,则是优秀中的代表。市面上的绝大多数的手机公司的研发部门,应该都叫技术方案整合商更为贴切。
只有将自己的日常浸润到各种类型的交互体验里,进而去理解实现方案背后的技术原理,才更有可能做出创新啊!
我第一次给父母体验‘小爱同学’的时候,他们是需要我的帮助才能使用。