“94岁老人被抱起做人脸识别”,产品经理又该来背锅了

“94岁老人被抱起做人脸识别”,产品经理又该来背锅了

风笛
2020-11-24 / 0 评论 / 226 阅读 / 正在检测是否收录...

近日,一段“94岁老人被抱起做人脸识别”的视频火了。

kzzdau9m.png

网友们看到,对于“人脸识别”这种产品也“火了”。有网友表示:“说好的人性化服务呢?94岁老人因社保卡未激活,被抬到银行人脸识别!科技的进步是给别人方便,如今却成了给老人添堵的工具,我只想问问,那些发明人脸识别的人,你们不老吗?你们一辈子,就那么顺吗?”

kzzdb3ws.png

有的网友表示:“智能化发展的缺失问题”

kzzdb9sd.png

有的网友表示:“人性点好吧,怎么又难为老年人呢”;还有的网友表示:“问一下银行,你们的那个摄像头挪动一下比94岁的老人的挪动还困难么”。

kzzdbgx2.png

做互联网产品经理的伙伴,或许在心里嘀咕:在公司里面,或许这又是产品经理背的锅了。

不考虑用户场景,不考虑用户体验,过度依赖机器,这不是产品经理的锅吗?

前几天,我也遇到过银行APP产品的糟糕体验:

身份证信息需更新,光大银行发了3次信息过来,最后一次还提醒“最后一次提醒”,于是我就赶紧登陆银行的APP更新身份证信息了。第一次登陆APP更新身份证信息是在晚上,提示:“尊敬的客户,请于每日7:30至19:00之间登陆手机银行更新身份证,感谢您的配合!”第二次登陆APP更新信息是在白天,更新身份证信息的操作是,用摄像头对着身份证正反面,系统进行智能识别(其实是OCR功能),手提着手机正对着身份证,举了半天也识别不成功,找客服也不处理,就智能放弃了。

产品的学问,往往体现在生活的细节当中。“94岁高龄老人被抱起做人脸识别”也好,“更新身份信息失败”也罢,都脱离不了产品经理需要关注的几个关键知识点:场景、用户体验、异常流。

产品经理做需求分析的时候,应该以场景为出发点,并基于场景来做产品。因为产品是要解决各种场景所遇到的问题的,不基于场景来做的产品就只是产品经理(或者领导们)自己一厢情愿、自以为是而已,做不出解决用户痛点,让用户满意的产品。

如果把产品经理当作小说的作者,产品是我们所写的小说,那么小说的三要素“人物、情节、环境”就是我们需要思考的。

人物,即什么样的人,也就是产品的用户群。

情节,即故事发展的过程,也就是产品的业务流程。

环境,即人物所处的环境,也就是产品用户群的使用场景。

此外,敏捷开发里面的故事板所体现的思路亦类似:作为一名<某种类型的用户>,我希望<达成某些目的>,这样可以<开发的价值>。

1、以“94岁老人被抱起做人脸识别”为例:

用户:老人
场景:行动不便、人脸干扰因素较多(例如,皱纹、老年斑、轮廓)

2、以“银行的个人信息更新”为例:

用户:所有用户
场景:因智能识别技术或其他原因无法识别

作为产品经理,我们需要考虑的就是“让相应的用户,在相应的场景下,能够流畅地达成其目的”,为用户提供解决方案。

例如,第一个例子,我们可以这样考虑:既然老人行动不便,人脸干扰因素较多,分析一下数据这样的用户群体多不多,用户不多的情况下,将这种场景归为“异常场景”(异常流)。系统可以“忽略”这部分用户群体,直接人工介入(做产品,切勿过度依赖机器),这样既省了工作量,也避免因为满足异常场景而导致产品更加复杂和冗余,这时候,我们的产品可以做一个属性标记,标记为“老人”(这部分用户特殊处理),不采集老人的人脸数据(一旦过度依赖人脸识别,日后如果因衰老或者其他干扰因素导致无法识别,将会引发新的问题,吃力不讨好),可以通过其他信息的补充来弥补这个缺陷。在这类型的用户很多的情况下,将这种场景归为“普通场景”(普通流),这时候可以考虑做“手持移动设备”,方便上门服务;而人脸干扰因素的问题,则可以考虑采集“监护人”的人脸数据,由监护人辅助完成相应的业务办理……

再如,第二个例子,我们可以这样考虑:机器识别技术无法达到100%的准确率,那就不能过度依赖技术的力量,毕竟技术是提高效率的,而不是完全替代的,正如机器人无法完全替代人一样。我们可以提供拍照,然后作OCR识别。OCR识别技术,用于将图像信息转化成文字信息存储到系统,而照片则可以存储下来,以便核对。

上面的例子只是提供一种思路,没有考虑到更深的细节场景,仅供参考。

--END--

0

评论 (0)

取消