从2015年起，我陆续写了《写给产品经理和设计师的用户体验知识》系列文章，得到了大家的肯定，此篇文章是这个系列的最后一篇文章，算是给这个系列画上句号。
作者：刘涵宇
腾讯高级产品经理
用户场景这东西，或许每一个产品经理和设计师每天都在用，但我查了很多资料，还真的很难找到一个准确的定义。所以，我试图结合我自己的理解，自己去定义它。我认为用户场景有两层属性，分别是：「工具属性」和「思维属性」。
用户场景首先是一种对过程逻辑的阐述方法，简单讲，它帮助产品经理理清用户使用产品的核心逻辑。具体来说，涉及以下几个关键因素：
-
● 用户是谁
-
● 在什么样的条件下
-
● 有了怎样的需求
-
● 会去用什么方式实现（或者表述为：能够做一个什么样的功能来帮他实现）
从其工具属性来看，简单说，有两点用途：
-
● 以用户视角发现需求，并思考解决方案，以及评估方案合理性
-
● 辅助沟通
-
发现需求并思考解决方案
举例来说，出租车司机日常主要的工作场景可以表述如下：出租车司机在没有载客的时候，需要寻找乘客以便于载客赚钱，所以他们一边驾车在路上行驶，一边用眼神留意路边是否有乘客向其招手，如果有，就停车载客。
在上述场景中，「出租车司机」是用户，「没有载客的时候」是条件，「寻找乘客」是需求，「一边开车一边留意」是实现方式。那么，作为一个产品经理，当发现了这个场景的时候，就可以针对「实现方式」来思考，有没有更好的方式呢？于是，产品经理想到，现在不论是司机还是乘客都有手机，可以做一款手机应用，帮助司机和乘客双方更高效的找到对方。基于此，产品经理可以这样表述用户场景：出租车司机在没有载客的时候，需要寻找乘客以便于载客赚钱，于是他打开手机应用，应用会自动向他推送附近乘客发出的乘车需求，他可以选择合适的需求抢单，然后去接该乘客，以便于达到载客赚钱的目的。
事实上，不论是把观察到的现象抽象为一类共性的特征，以便于思考解决方案；还是用来验证脑中「灵光一现」的所谓idea，用户场景作为工具，都是相对客观和实用的。
辅助沟通
另外，确定需求有价值，方案合理之后，使用用户场景的方式将需求表述给其他环节的同事，往往更加高效。产品经理日常会遇到的一个重要的挑战，往往是所谓「需求的合理性」，但是不同的人出发点不同，同一个需求，往往有人认为重要，有人认为不重要，这时因为大家的立场不同，所以很多争论往往是鸡同鸭讲，没有结果。
但是如果使用用户场景的方式来讨论问题，就可以引导各角色从用户的角度出发去思考问题，有利于各方对于需求的理解以及相关进度的推进。
场景思维
用户场景除了可以作为一种有用的工具使用之外，更重要的，「场景思维」是一种相比于「业务思维」和「功能思维」来说，更加适合产品经理的思维方式。
案例：应用安装流程与权限设置
在这个案例中，我们来体会一下工程思维与场景思维做出来的产品的差别。如果我们在Android系统中下载某个应用并安装，在安装前，会显示如下图所示的，该应用将会用到的所有权限列表。
我们可以看到，该应用会使用到系统的很多权限，从图中滚动条的位置来看，足有2-3页。Android操作系统的逻辑是，在应用安装前，列出所有其可能用到的系统权限，供用户权衡，如果用户认为可以接受，就继续安装；如果认为不能接受，就不安装。理论上逻辑很清晰，但这是一种按照程序运行逻辑来展现的流程，如果从用户场景的角度来看，有两个问题：第一，普通用户懂这些权限究竟意味着什么吗？第二，在用户尚未使用任何功能的时候，列出所有权限，用户很难将其与具体功能和目的联系在一起，即便能看懂，也难以评估其是否合理。
紧接着，在安装过这个应用之后，打开时，又会连续弹出多个对话框向用户索要权限。其中一个地理位置信息的权限我点了「拒绝」，因为我并不觉得一个运营商手机营业厅需要知道用户的地理位置，结果，不给这个权限，应用拒绝运行，出现了如下图所示的提示：
而当我按下「去设置」按钮之后，则直接跳转到了如下图所示的权限设置界面：
这个应用的产品经理，同样延续了如Android操作系统一般的工程思维。程序运行的逻辑是：如果拥有ABC三个权限，就正常运行；如果缺少任何一个或多个，就拒绝运行，直到获得它们为止，如何获得呢？让用户自行去设置。沿着这个逻辑，所以用户就看到了这个提示框。但是这种做法同样有两个问题：第一，还是当用户尚不知晓应用需要相应权限要做什么的时候，难以评估其合理性，理论上难以做出选择。第二，即便有一些应用必须要获取到某种权限后才能运行，是否至少应该在提示中告诉用户，去往权限设置界面后，应该要开启哪几个权限呢？否则用户依然难以正确操作。
同样的场景，在iOS系统中是另外的一套体验。如果在App Store中安装一个应用，只需要按下「获取」按钮，验证Apple ID和密码（虽然Apple ID这里是长久以来被诟病的环节），即可开始下载安装该应用。安装好之后，该应用的图标就会出现在手机屏幕上，全程没有任何需要做决策的步骤。如下图所示：
同样，以滴滴出行这个应用为例，在启动的时候，依然会向用户索要相应的权限，这是系统必要的安全机制。但是其方式与上述运营商的应用不太一样，区别仅仅是，多了一行文字提示：「滴滴出行需要获取您的位置信息，以便司机师傅能够准确接您上车」，如下图所示：
以上App Store的案例和滴滴出行的案例结合在一起，对比Android操作系统上的流程，我们会发现iOS体系是更加贴近用户场景的实现方式。
首先，在安装应用的过程中，流程一直围绕着「安装」这个核心目标进行。浏览应用截图、浏览应用简介内容、验证ID、查看安装进度，这些都是安装所对应的用户场景中可能的元素。显然，一个工程师有可能在安装应用的时候想到「它会需要哪些权限」，但一个普通用户应该是想不到这一点的——只有在使用具体功能的时候，才可能注意到。
其次，滴滴出行在向用户索要权限的时候，明确告知用户「为什么」，虽然看上去只是多了一句文字提示而已，但非常契合用户场景。这样，用户知道，必须授权后，司机才能准确找到用户，来接他，这样用户更有依据去做决策——这个权限给还是不给。
看起来，用户体验是一种可以让「世界变得更美好」的东西。很多时候，的确如此，但是，如果没有「用户价值（帮用户解决什么问题）」、「商业价值（如何盈利）」等作为根基，用户体验就将像是无根的浮萍，最终是无法很好的落地的。如果一定要做比较，那么，大多数的时候，用户价值高于用户体验。
案例：脸萌的起落
「脸萌」是一个曾经风靡一时的虚拟形象制作应用，用户通过滑动手机屏幕的方式组合不同的发型、发色、脸型、肤色、五官等元素来制作属于自己的虚拟形象。曾经在微信朋友圈、微博等各大社交网站上刷屏，并且获得了包括IDG在内的风险投资。
其实，虚拟形象的成功案例早就有，国内最经典的案例应该就是QQ秀了。在QQ秀中，用户也是通过自由组合各种元素的方式来设计自己的虚拟形象，并且可以组合的元素不仅包括头发、五官和脸型，还包括着装和饰品。从腾讯的财报上来看，QQ秀在历史上也曾为腾讯贡献了不少的收入，用户愿意为此付钱，侧面证明其用户价值还是值得肯定的。脸萌主打的是「萌」这个概念，其成功切中了一部分年轻人的需求，但是如果我们深入的去对比一下脸萌和QQ秀这两个产品就会发现问题。虚拟形象类的产品，其用户价值究竟是什么？是可以设计出一个漂亮的虚拟形象；还是设计了漂亮的虚拟形象之后，可以把它用在社交场景中呢？显然是后者。脸萌在产品层面并没有什么特别的壁垒，虽然玩法有趣，易于传播，但是因为无法创造社交场景，所以绝大多数用户只能把它当做一个简单的工具来使用，其用户价值大打折扣。
毫无疑问，脸萌的用户体验真心不错，但是，因为其缺少更核心的用户价值作为根基，最终隐居在了茫茫的应用海洋之中。
在日常工作中，产品经理和设计师经常会就某一些方案进行深度的撕逼，这种撕逼很多时候并不会有特别明确的结果——因为很多时候，双方立场不同。我见过很多设计师，他们以为自己能够代表用户，以为自己是在为用户争取「权益」，而实际上，他们中很多人看不到「体验」之外的因素，甚至是看不到「UI」之外的因素；同样，我也见过很多产品经理，他们急于拿到好看的数据，有时候会或者有意或者无意的提出损坏用户体验，继而是透支产品未来的需求方案。
但是，这种撕逼的过程并不是完全没有意义的，正因立场不同，双方可以形成一种制衡，让最终的产品不至于过于偏向任何一方的立场。
然而，作为一个优秀的产品经理，还是应该对自己要求高一些，应该做到理解对方的立场，并且综合各因素去思考问题——在整个团队中，产品经理是唯一一个不能「任性」的角色。
一个优秀的产品经理，并不应该是一个「唯商业论」、「唯数据论」或者「唯体验论」者，而是应该有能力在包括「用户体验」在内的诸多因素中，找到最佳的平衡点——这在我过去一年多做「互联网+」产品的过程中，深有体会。
就像是，几年前，我从交互设计师转岗到产品经理职位，去面试的时候，说（chui）过（guo）的一句「台（niu）词（bi）」：「国内不缺优秀的设计师，缺的是，能够用好设计师的产品经理。」
或许，当我们生活在一个狭窄的空间中，当我们眼界有限，只能看到「体验」的时候，善良的我们就只会以「做好体验」为己任；而当我们站得更高，可以看到更大的世界时，我们才能够有机会学会「平衡」。
我正在向这个方向努力。
原创文章，作者：交互精选，如若转载，请注明出处：https://www.iamue.com/36582/
