文章来源：简书 作者：某年某人
banner：william王萌
之前写过一篇文章《像做发布会那样做产品》，文中主要写通过有意利用产品中的魅力需求来提高用户满意度，达到口碑宣传的效果。而今天写的文章与之类似，主要来写产品设计中的通过对用户使用场景的理解，将产品功能相互连接进行自然过渡，达到舒适的效果，在完成某些特定桥接的同时，兼顾人文关怀。
首先了解下用户场景：
用户场景的描述实际上是在构造一个完整的过程。一个场景里面包含了什么人，在什么状态下，遇到了什么问题，他们如何操作，他们得到什么反馈。
用一个套路来表示，具体描述如下：
“在某某时间（when），某某地点（where），周围出现了某些事物时（with what），特定类型的用户（who）萌发了某种欲望（desire），会想到通过某种手段（method）来满足欲望。”
when，where，with what这几点信息其实统一地描述了需求产生的环境。
从这些环境信息可以分析出诱发需求的条件和需求产生时的环境条件。
用户场景主要用来判断需求的存在必要性，深刻理解产品需求，深入考虑用户是如何使用产品的。用户使用产品有哪些路径以及在这些路径上的实际使用场景是怎样的。哪些是强场景，哪些是弱场景，在各场景下用户目标是怎样的，他们有怎样的需求，哪些是强需求，哪些是弱需求……
本文只要关注通过对用户使用场景的理解来优化产品设计，让产品设计过渡自然，富有情感。而做到这些必须对产品流程、用户目标足够熟悉，同时对用户心理也有所了解。
场景1、金山词霸的默认检测剪贴板
金山词霸
打开金山词霸后，如果它检测到系统剪贴板有粘贴内容（且为英文），会自动提示已经检测到您复制了以下内容，询问是不是要点击翻译。这点功能在开发中并不难，但是很多查单词的软件都没有这点，大多是在打开之后，在输入框粘贴刚才从其他地方复制到的英文单词，从流程上麻烦一个步骤。
分析用户使用场景（前几天我的真实场景）：
when:xxxxxxxxxxxx
who:xxxxx
where：xxxxxx
with what:手机浏览A软件时，遇到了一个不认识的单词，且该软件不自带翻译功能
desire:想要打开一个B软件查询单词意思
method：先在A软件中复制单词，准备打开B软件粘贴到文字框进行查询
这个是我的真实场景，当时我随手下载了几个词典类的app,当打开金山词霸的时候，发现他已经检测到了我复制的单词，无需我粘贴，点击就可以查询，当时略显感动。因为它对使用词典的流程有一个很清楚的认识，一般用户都是从其他软件复制单词到词霸中，并粘贴，在很多情况比如颠簸的公交车上，每一次操作都对用户来说成本很大，那么它就直接去检测你是系统内存中有没复制过的英文内容，猜测这是你想查询的单词，在缩短了操作步骤的情况下，充满人性关怀。
（注：最早我在学人机交互的时候，重点强调的是减少用户操作成本，不过个人感觉现在大多交互设计感觉稍微偏离了本质，越来越像UI设计，朝着越炫、越酷的方向发展，这个小贴心的功能，让我想起了人机交互最应该关注的点。）
场景2、新浪微博的下拉刷新-没有更多内容-询问是否前往热门话题
刷新微博
在首页下拉刷新时，如果没有更新的内容，一般app会弹出一个toast框提示【没有更多内容】,而新浪微博会首先弹出【你可能错过的一条热门微博】同时提示你去热门微博玩玩。
同理这个可以和上面一样进行用户场景分析：
用户以下拉刷新为method,本质的desire是获取新的内容，以完成消磨时间的欲望。当没有更新的内容的时候，我们可以通过其他方法完成用户的desire,比如给他最新的热门微博或者最热的笑话段子，这样一来可以帮用户完成他的desire,二来可以帮产品的其他功能进行引流，照顾或者加重某些功能权重；三来让用户感觉产品很有人性、很懂用户。
场景3、Google主页的断网状态-游戏模式
google页恐龙彩蛋
同样也是一个真实的场景，前日公司停网，因为断网很多工作不能进行，程序员同事也是这样（技术性休息），百般无聊坐等来网，突然发现旁边一个哥们玩起了google首页的恐龙游戏，围观了不少其他同事，请原谅我也是第一次才知道原来可以这样。
场景分析（省略who where when)：
with what:上班时候突然之间公司断网，一直刷新google首页看是否正常
desire:在等待的过程中，找点事情打发时间，但是不能被老板发现偷懒
method：找一些隐蔽的娱乐活动
正被大家熟知，www.baidu.com是一个大家用来测网络是否正常的一个流行工具，任何时候只要有人（不管是小白还是大神）要想知道自己网络是否畅通，大多时候是访问百度的主页，如果能刷出内容则说明网络通畅。可以猜测google在外国也有这项光荣的使命，就算在国内，断网的时候，我们也会通过查看google来了解情况，而在这个等待或者说异常的过程中，如果有什么事情能消遣并随时帮助第一时间了解状态那就再好不过，最好的方式就是在google的断网页面完成，于是google用小游戏来进行过渡，会让焦急等待的用户转移注意力，但始终停留在google首页，相当聪明。
场景4、超越iRate的评价方案
各种要好评
先说说iRate是什么？iRate是现在普遍在使用的一个开源的用户评分sdk,iRate可以判断：『在第几次打开客户端的时候，载入完成客户端之后显示此去评分的弹窗】（当然还有很多其他的方法）本质是用iRate中一段时间内第几次打开app来判断该用户是不是活跃用户，然后将去评分的信息弹给这批活跃用户，活跃用户比起一般用户对app依赖性大，感情深，喜欢程度高，去评分的转换率高。这个是目前最流行的模式，大部分app应该在用这个，在github上也有2000多个stars，不过这中方法难免会打断用户的正常操作，或者让用户感觉有点死皮赖脸强买强卖的感觉。
有没有一个更好的方案？我设想的用户场景：
with what:在当用户利用app核心功能完成某项操作到一个点时，或者获得某个荣誉时（这个时候是用户对app的价值最肯定的时候，或者说是最高兴的时候）
desire:看到这个感觉app帮助很大，或者很高兴，不去评价对不起app开发人员
method:弹出提示框，提示app已经帮助用户完成xxx,节省xxxx,在app中获得xxxx，引导去评分
每一个app都有自己的不同触发点，情况因app而议：
ex：音乐类app：当下载累计500首歌曲的时候，触发事件，弹出：【这是您的第500首免费歌曲，趁着下载的空，去评个分吧！】
ex：最近我们在做一款打榜的软件，有一个打榜的功能，我准备这样触发：
当用户打榜连续3次获得榜首的时候，小秘书发送祝贺消息：‘爷，您最近连续三次是榜首，小秘书帮你装了三次逼，要不去给我评个分？’
我YY的场景本质是告诉用户app帮你完成了什么或者给你带来了欢乐，是某个事件点上触发的，而不是生硬的判断你是打开app多少次，然后用卑微的声音求你去给评分，记住千万不要求，身份要平等，你要坚信你的app对用户带来的价值，评分是他们应该做的，当然前提是你app能确实帮助用户解决问题。
备注：做产品的时候，需要多考虑考虑用户的使用场景。用户哪些时候会使用应用，是工作的时候？走路的时候？用户经常在哪些地点会用，在办公室？地铁里？包括用户使用应用的平台、情绪，以及用户的网络情况，这些都可能影响到你对产品的设计，要迎合用户的使用姿态。
