蝶变:移动用户体验设计之道
上QQ阅读APP看书,第一时间看更新

第1章 企业用户研究方法探讨

1.1 发掘用户真实的需求

作者:邓俊杰

在谈这个话题前先分享一个小故事,这是我曾经一个同事讲述的用户需求案例。事情是这样的,他的一个朋友是外国人,有一天来公司拜访他,结束之后他送这位老外朋友出公司。老外朋友对同事说,他需要找前台借一支笔。同事就问他做什么,他说需要朋友将自己手机上显示的英文地址写成中文,然后他打到的士后就可以给司机看,这样司机就能把他带回酒店。

同事举这个例子是想告诉我们,他的朋友最原始的需求是“借一支笔”,而本质需求却是“回到酒店”,这两者相差甚远。通常原始需求都是用户自己想到的解决方案,认为可以解决自己的问题,而事实上如果能获得用户的本质需求,就可能找出更合理的方案来解决用户的问题。

在做产品时,不论是产品经理还是设计师经常能从市场或运营团队那里得到一些用户的原始需求,例如这个颜色希望变成绿色,这里的字体需要更大,急需更省电的模式等等。很多产品经理和设计师信奉用户至上,包括现如今很多声称具有互联网思维的公司都强调用户在产品设计和开发过程中的重要性,这个观点并没有错,但是如果对用户原始需求没有进行任何分析就落地到产品中,这也是对用户极不负责的行为,非常容易造成“头痛医头,脚痛医脚”的情况。

再举一个实际案例,这发生在我们自己实际的产品中。云之家是一款移动办公应用,有一个功能就是可以在手机上签到,这样员工到了公司附近就可以掏出手机在应用上打卡完成考勤,而不用走到公司的考勤机旁排队用工卡打卡。有个公司的人力资源经理就给我们提了一个原始的需求:尽快把签到提示音改为人声。

签到提示音是指在上下班时间前15分钟手机发出的声音提示,以提醒员工用手机签到。我当时回绝了这个需求,理由有两点:一是一般App的提示音都不会采用人声,因为不够优雅,例如我们在一些工作场合听到一些人声的电话铃声或是奇怪的提示音都会觉得对方不够专业一样;二是上下班时间前15分钟,员工要么在公共场合(如地铁、公交上),要么在办公环境中(如还在开会),此时手机突然有人声叫“签到啦”会引起不必要的尴尬,体验会不好。

但是这名人力资源经理并不认可,坚持认为我们的提醒声音很普通,就是要改为人声,需要给员工很强的提醒。如果仅仅从这个原始需求上来看,感觉是我们的提醒声音不够强烈或是不够特别,可能会跟诸如微信、短信等其他应用的提醒音混淆。所以我跟这个人力资源经理沟通是不是可以让员工自定义铃声,因为如果我们官方提供了一个人声提醒,那究竟是用男声还是女声,用清脆的还是磁性的,用林志玲的声音还是郭德纲的声音?这将无形中夸大个人的好恶。人力资源经理觉得让员工自定义铃声也可以,并且要求马上就要落地到版本中。但是我自己又仔细想了一下,其实用户自定义提示音的比例并不高,例如我们不少人还是只用默认的电话、短信、闹钟、日程的提示音,而且如果真的大家都来自定义提示音,那么一到某个时间点一个办公室的人手机响起各种自定义的签到提示音,也是很滑稽的。

所以我就跟这个人力资源经理继续沟通,然后才发现了他的本质需求。他们公司原来是在一个特定的指纹打卡机上打卡的,每到上班时间,指纹打卡机前会排很长的队伍等待打卡。现在采用了移动办公应用,员工不用排队打卡了,人力资源经理强行拆除了指纹打卡机。但由于刚开始执行还没形成习惯,导致员工经常忘记打卡。该公司考勤很严格,忘记打卡或是晚打卡都要扣钱,员工就要在月底前打印纸质文件,然后再找两个以上的证明人来证明自己当天只是忘记打卡并非旷工。而这名人力资源经理则要去考证这些证明,无形中增加了很多工作量,也提高了公司的管理成本。我们可以看到,这名人力资源经理的原始需求是将签到提醒音改为人声,实际上他的本质需求是让员工减少忘记打卡的次数。在他看来只要将签到提醒音改为人声,那么明显的提示之下员工自然会想起来打卡,大家都打卡了,他也就没有那么多工作量了。

这名人力资源经理的原始需求和很多用户的需求一样,通常都是他们自认为的解决问题的方案,但是用户对整个产品的考虑却比较少,他们一般较难想到自己的方案对现有产品带来的影响或是在一些场景下的不适。对于这个人力资源经理的原始需求我给出了更为人性的方案:首先如果员工在上班前忘记打卡,但是员工此时手机连上了公司Wi-Fi,或者GPS定位员工在公司附近,那么应用会给员工自动补打卡(同时还要结合一些手机传感器数据,保证员工手机的确是在使用中,否则员工可能会拿个旧手机连着公司Wi-Fi一直放在公司);其次如果员工真的由于各种原因忘记打卡,而且自动补打的机制也未生效,那么就判断员工是否在工作时间连着公司Wi-Fi用我们的应用发过消息、传过文件,有这样的情况也可以证明员工并未旷工。通过这些相对智能和人性的判断来降低员工由于未注意到提醒而忘记打卡的概率,从而解决这个人力资源经理遇到的问题。

其实如果再深入分析一下这个人力资源经理的需求,我们除了能发掘出他的本质需求外,还会发现他一个隐含的需求。例如他为什么这么急切地要求我们尽快落地增强提示的方案?我们来脑补一下他面临的情况。他强行拆除了指纹打卡机,采用移动签到,改变了整个公司员工的打卡习惯,结果导致了很多员工忘记打卡,员工需要找各种证明和审批,一定怨声载道,甚至纷纷质疑这名人力资源经理当初的决策。所以这个人力资源经理的隐含需求极有可能是要尽快打消员工对于他强推移动签到这个决定的质疑。能帮他解决这个隐含需求,或许他的本质需求也能迎刃而解。

所以我们可以看到用户的原始需求跟他的本质需求和隐含需求可能差别很大,那么如何发掘用户的本质需求和隐含需求呢?除了深入交流之外最好是能身临其境,就以上面的案例来说,如果能到他们公司待上一段时间,当一段时间的员工可能会更有感触。我又想起来一个案例,在一次业界交流活动中,有个设计师在西门子公司做大型医疗器械设计。他就跟我说大型医疗器械的设计要非常严格精准,但是设计师不是医生,很多地方会考虑不到,于是他就跟医生一起工作,医生干什么他就干什么,时间长达三四个月,到最后他对人体的各种器官、血管都了如指掌了才开始进行设计。或许医生的原始需求只是要扫描病人的某个部位,但是如果仅仅很简单地去根据这样的需求做设计和开发产品,最终的结果一定不理想,也难以捕捉到医生的本质需求和隐含需求。

回到本文最开始的例子,“借一支笔”是原始需求,“回到酒店”才是本质需求,于是我的同事并没有给这个外国人找笔,而是找了另外一个同事顺路将其带回了酒店。看,并非一定是用户要求什么你就执行,仔细分析之后其实会有更好的方案。再深入分析一下这个外国人的隐含需求呢?其实是“跟司机用中文交流”,试想一下这个隐含需求解决了,他也就不会有刚开始借笔那一幕了。

To B产品面临的角色有很多,不能简单像To C产品那样考虑通用的人性,企业里的老板、经理、基层员工,不同岗位职责的人都会有不同的需求。所以一款好的To B产品对不同角色的需求把握必须非常到位,只有了解到对应角色的真实需求才能设计和开发出合适的产品。