微信热点

写给产品经理和设计师的用户体验知识

0
登录或者登记去做吧。

文章目录[隐藏]

从2015年起,我陆续写了《写给产品经理和设计师的用户体验知识》系列文章,得到了大家的肯定,此篇文章是这个系列的最后一篇文章,算是给这个系列画上句号。

作者:刘涵宇

腾讯高级产品经理

1
用户场景

用户场景这东西,或许每一个产品经理和设计师每天都在用,但我查了很多资料,还真的很难找到一个准确的定义。所以,我试图结合我自己的理解,自己去定义它。我认为用户场景有两层属性,分别是:「工具属性」和「思维属性」。

用户场景首先是一种对过程逻辑的阐述方法,简单讲,它帮助产品经理理清用户使用产品的核心逻辑。具体来说,涉及以下几个关键因素:

  • ●  用户是

  • ●  在什么样的条件下

  • ●  有了怎样的需求

  •   会去用什么方式实现(或者表述为:能够做一个什么样的功能来帮他实现)

从其工具属性来看,简单说,有两点用途:

  •   以用户视角发现需求,并思考解决方案,以及评估方案合理性

  • ●  辅助沟通

发现需求并思考解决方案

举例来说,出租车司机日常主要的工作场景可以表述如下:出租车司机在没有载客的时候,需要寻找乘客以便于载客赚钱,所以他们一边驾车在路上行驶,一边用眼神留意路边是否有乘客向其招手,如果有,就停车载客。

在上述场景中,「出租车司机」是用户,「没有载客的时候」是条件,「寻找乘客」是需求,「一边开车一边留意」是实现方式。那么,作为一个产品经理,当发现了这个场景的时候,就可以针对「实现方式」来思考,有没有更好的方式呢?于是,产品经理想到,现在不论是司机还是乘客都有手机,可以做一款手机应用,帮助司机和乘客双方更高效的找到对方。基于此,产品经理可以这样表述用户场景:出租车司机在没有载客的时候,需要寻找乘客以便于载客赚钱,于是他打开手机应用,应用会自动向他推送附近乘客发出的乘车需求,他可以选择合适的需求抢单,然后去接该乘客,以便于达到载客赚钱的目的。

事实上,不论是把观察到的现象抽象为一类共性的特征,以便于思考解决方案;还是用来验证脑中「灵光一现」的所谓idea,用户场景作为工具,都是相对客观和实用的。

辅助沟通

另外,确定需求有价值,方案合理之后,使用用户场景的方式将需求表述给其他环节的同事,往往更加高效。产品经理日常会遇到的一个重要的挑战,往往是所谓「需求的合理性」,但是不同的人出发点不同,同一个需求,往往有人认为重要,有人认为不重要,这时因为大家的立场不同,所以很多争论往往是鸡同鸭讲,没有结果。

但是如果使用用户场景的方式来讨论问题,就可以引导各角色从用户的角度出发去思考问题,有利于各方对于需求的理解以及相关进度的推进。

场景思维

用户场景除了可以作为一种有用的工具使用之外,更重要的,「场景思维」是一种相比于「业务思维」和「功能思维」来说,更加适合产品经理的思维方式。


案例:应用安装流程与权限设置

在这个案例中,我们来体会一下工程思维与场景思维做出来的产品的差别。如果我们在Android系统中下载某个应用并安装,在安装前,会显示如下图所示的,该应用将会用到的所有权限列表。


我们可以看到,该应用会使用到系统的很多权限,从图中滚动条的位置来看,足有2-3页。Android操作系统的逻辑是,在应用安装前,列出所有其可能用到的系统权限,供用户权衡,如果用户认为可以接受,就继续安装;如果认为不能接受,就不安装。理论上逻辑很清晰,但这是一种按照程序运行逻辑来展现的流程,如果从用户场景的角度来看,有两个问题:第一,普通用户懂这些权限究竟意味着什么吗?第二,在用户尚未使用任何功能的时候,列出所有权限,用户很难将其与具体功能和目的联系在一起,即便能看懂,也难以评估其是否合理。

紧接着,在安装过这个应用之后,打开时,又会连续弹出多个对话框向用户索要权限。其中一个地理位置信息的权限我点了「拒绝」,因为我并不觉得一个运营商手机营业厅需要知道用户的地理位置,结果,不给这个权限,应用拒绝运行,出现了如下图所示的提示:

而当我按下「去设置」按钮之后,则直接跳转到了如下图所示的权限设置界面:

这个应用的产品经理,同样延续了如Android操作系统一般的工程思维。程序运行的逻辑是:如果拥有ABC三个权限,就正常运行;如果缺少任何一个或多个,就拒绝运行,直到获得它们为止,如何获得呢?让用户自行去设置。沿着这个逻辑,所以用户就看到了这个提示框。但是这种做法同样有两个问题:第一,还是当用户尚不知晓应用需要相应权限要做什么的时候,难以评估其合理性,理论上难以做出选择。第二,即便有一些应用必须要获取到某种权限后才能运行,是否至少应该在提示中告诉用户,去往权限设置界面后,应该要开启哪几个权限呢?否则用户依然难以正确操作。

同样的场景,在iOS系统中是另外的一套体验。如果在App Store中安装一个应用,只需要按下「获取」按钮,验证Apple ID和密码(虽然Apple ID这里是长久以来被诟病的环节),即可开始下载安装该应用。安装好之后,该应用的图标就会出现在手机屏幕上,全程没有任何需要做决策的步骤。如下图所示:

同样,以滴滴出行这个应用为例,在启动的时候,依然会向用户索要相应的权限,这是系统必要的安全机制。但是其方式与上述运营商的应用不太一样,区别仅仅是,多了一行文字提示:「滴滴出行需要获取您的位置信息,以便司机师傅能够准确接您上车」,如下图所示:


以上App Store的案例和滴滴出行的案例结合在一起,对比Android操作系统上的流程,我们会发现iOS体系是更加贴近用户场景的实现方式。

首先,在安装应用的过程中,流程一直围绕着「安装」这个核心目标进行。浏览应用截图、浏览应用简介内容、验证ID、查看安装进度,这些都是安装所对应的用户场景中可能的元素。显然,一个工程师有可能在安装应用的时候想到「它会需要哪些权限」,但一个普通用户应该是想不到这一点的——只有在使用具体功能的时候,才可能注意到。

其次,滴滴出行在向用户索要权限的时候,明确告知用户「为什么」,虽然看上去只是多了一句文字提示而已,但非常契合用户场景。这样,用户知道,必须授权后,司机才能准确找到用户,来接他,这样用户更有依据去做决策——这个权限给还是不给。

2
户体验的局限性

看起来,用户体验是一种可以让「世界变得更美好」的东西。很多时候,的确如此,但是,如果没有「用户价值(帮用户解决什么问题)」、「商业价值(如何盈利)」等作为根基,用户体验就将像是无根的浮萍,最终是无法很好的落地的。如果一定要做比较,那么,大多数的时候,用户价值高于用户体验。

案例:脸萌的起落

「脸萌」是一个曾经风靡一时的虚拟形象制作应用,用户通过滑动手机屏幕的方式组合不同的发型、发色、脸型、肤色、五官等元素来制作属于自己的虚拟形象。曾经在微信朋友圈、微博等各大社交网站上刷屏,并且获得了包括IDG在内的风险投资。

其实,虚拟形象的成功案例早就有,国内最经典的案例应该就是QQ秀了。在QQ秀中,用户也是通过自由组合各种元素的方式来设计自己的虚拟形象,并且可以组合的元素不仅包括头发、五官和脸型,还包括着装和饰品。从腾讯的财报上来看,QQ秀在历史上也曾为腾讯贡献了不少的收入,用户愿意为此付钱,侧面证明其用户价值还是值得肯定的。脸萌主打的是「萌」这个概念,其成功切中了一部分年轻人的需求,但是如果我们深入的去对比一下脸萌和QQ秀这两个产品就会发现问题。虚拟形象类的产品,其用户价值究竟是什么?是可以设计出一个漂亮的虚拟形象;还是设计了漂亮的虚拟形象之后,可以把它用在社交场景中呢?显然是后者。脸萌在产品层面并没有什么特别的壁垒,虽然玩法有趣,易于传播,但是因为无法创造社交场景,所以绝大多数用户只能把它当做一个简单的工具来使用,其用户价值大打折扣。

毫无疑问,脸萌的用户体验真心不错,但是,因为其缺少更核心的用户价值作为根基,最终隐居在了茫茫的应用海洋之中。

3
用户体验与其他因素的权衡


在日常工作中,产品经理和设计师经常会就某一些方案进行深度的撕逼,这种撕逼很多时候并不会有特别明确的结果——因为很多时候,双方立场不同。我见过很多设计师,他们以为自己能够代表用户,以为自己是在为用户争取「权益」,而实际上,他们中很多人看不到「体验」之外的因素,甚至是看不到「UI」之外的因素;同样,我也见过很多产品经理,他们急于拿到好看的数据,有时候会或者有意或者无意的提出损坏用户体验,继而是透支产品未来的需求方案。

但是,这种撕逼的过程并不是完全没有意义的,正因立场不同,双方可以形成一种制衡,让最终的产品不至于过于偏向任何一方的立场。

然而,作为一个优秀的产品经理,还是应该对自己要求高一些,应该做到理解对方的立场,并且综合各因素去思考问题——在整个团队中,产品经理是唯一一个不能「任性」的角色。

一个优秀的产品经理,并不应该是一个「唯商业论」、「唯数据论」或者「唯体验论」者,而是应该有能力在包括「用户体验」在内的诸多因素中,找到最佳的平衡点——这在我过去一年多做「互联网+」产品的过程中,深有体会。

就像是,几年前,我从交互设计师转岗到产品经理职位,去面试的时候,说(chui)过(guo)的一句「台(niu)词(bi)」:「国内不缺优秀的设计师,缺的是,能够用好设计师的产品经理。」

或许,当我们生活在一个狭窄的空间中,当我们眼界有限,只能看到「体验」的时候,善良的我们就只会以「做好体验」为己任;而当我们站得更高,可以看到更大的世界时,我们才能够有机会学会「平衡」。

我正在向这个方向努力。

邀你参与丨2018中国用户体验行业调研
交互设计行业&教育状况调研报告