用户场景是我们开始接触产品后经常听到的一个词汇，在做产品之前，我们经常听到老手们会说：
用户调研、走进用户、换位思考、用户思维、用户画像……最后要从用户场景开始引导产品流程逻辑的整理，与业务逻辑相结合。
用户场景看起来是个很简单的问题，因为我们平时无处不在的生活环境和行为都构成了一个个场景。但是完善的分析产品的用户场景并不是那么简单，因为你不是用户，你很难完全的站在用户的位置去发现需求，用户不是你，他不会站在战略层、范围层来理解你的产品；再加上用户需要面对的各种杂七杂八的干扰，你需要考虑很多。
我们在考虑用户场景时，需要考虑什么？我会从四个方面来进行发散思考。
一、描绘场景所需要覆盖的因素
这里我们用经典电影《星球大战》老三部曲的第一部中的一个剧情来分析：欧比旺带着卢克去乘韩索罗的千年隼号飞船。
1、用户是谁?（人物角色可以反映出产品真实的、主要的用户群体）
银河帝国已经得知他们需要抓的机器人R2D2,C3PO在卢克手中，而杀死了卢克的养父母没有得到这两个机器人，那么他们就要来追杀卢克，而欧比旺因为卢克父亲的原因想在卢克身边训练、保护他，而且自己又是绝地武士，所以这两个人是逃犯，不能通过正规交通工具，且急需逃命，去遥远的星球的人。所以他们找到了韩索罗，这个提供超光速飞船、非法服务、随叫随走的产品提供者。
2、用户为什么来你的网站?（在可行的条件下获取用户使用产品的动机和预期）
韩索罗此时在问欧比旺来找他乘坐“千年隼”号的目的，虽然来找他坐飞船的都不是善类，但是韩索罗作为一个精明的江湖人士，还是要发问。因为他需要权衡这趟旅程的收益，值不值得冒险，还有准备开什么价。就像我们用用户场景来进行分析时，需要在用户场景下寻找使用产品的动机，是否与预设的产品需求相符合，如果我们得到充足的证据，我们需要让产品为真实、主要的用户群体去改变。
3、用户的目标是什么?（通过用户场景分析，我们要知道满足了用户获得什么才算我们的产品有价值）
在这里，韩索罗吹了一通牛（当然千年隼号就是牛），就是“跑得比谁都快”、“银河系哪个星球我没去过”、“和凯若里战舰谈笑风生”，欧比旺听了韩索罗的话，立即表示要乘坐千年隼号，并且使出浑身解数来砍价，韩索罗心里就有数了，这笔生意搞定了。
4、用户如何通过自己的产品实现目标
对于欧比旺和卢克来说，当然就是乘上千年隼号跑了啊。但是我们现实生活中的产品都是要自己去动手操作的，就好比如果千年隼号就是个互联网产品，那么怎么开的快？怎么去遥远的地方？怎么躲避帝国追击？这些都是韩索罗作为产品经理需要考虑的“用户场景”。
5、定义出用户如何在网站上完成自己的目标，并找出完成目标过程中的多种可能性和任何潜在的问题。
韩索罗需要确定欧比旺和卢克：1、乘坐上了快速的千年隼号2、到达了他们的目的地3、没被帝国抓住（虽然最好他们自投罗网了），这算是实现了两位用户的基本目标，但是在使用产品的过程中，韩索罗遇到了一下的干扰。
被债主悬赏捉拿
在起飞之前被帝国阻截
目的地星球已被摧毁
韩索罗和欧比旺他们遇到的问题，如果把他搬到现实产品中来，那就会是
团队因为资金、资源、网络等问题可能会延误业务（韩索罗被要挟用千年隼号抵债）
用户网络不好，初次打开产品就遭遇体验不佳（千年隼号在起飞之前遭到帝国拦截）
如果是个电商产品，我们可以认为是商品没货了（目的地阿尔德兰被炸飞了）
二、不同的产品类型
1、用户目标明确清晰的场景
只知道用户要做什么而不详细的向用户介绍具体操作流程。这种类型的场景在确定网站架构和内容的时起到了比较大的作用
在可用性测试的时候，与测试人员一起给用户提供一个这样的场景：只给用户一些背景、人物之类的框架信息，去观察用户在这种情况下如何完成任务，来记录和了解用户的行为。
欧比旺就给了卢克一把光剑以及原力的基本使用方法，让他格挡攻击无人机的进攻，看他如何了解原力，如何战斗。
2、精细化的场景
提供了更多的用户使用细节。这些细节能帮助产品团队更深入的理解用户特征及这些特征是如何帮助或阻碍他们使用产品时的行为。知道了这些信息，团队更容易设计出让用户更舒服、更易操作的内容、功能和产品流程。
卢克、莉娅、韩索罗来到反抗军的基地准备应对来袭死星的进攻，死星是摧毁了阿尔德兰整个星球的武器，威力十分强大，反抗军需要商讨孤注一掷的战略才有胜利的可能性。
在这个场景中有如下细节，使得这次反攻计划必须按照置顶的战略进行才能成功。
死星的防御系统是针对大型武器设计的，帝国不屑于小型战机的攻击——反抗军用小型战机最终达成了战略目标
死星有个排气管，引爆他就能摧毁死星，但是这个地方很小很隐蔽——所以反抗军出动了大量敢死队来提高攻击行动可能性
死星的弱点依然有防御系统——反抗军小型战机使用了质子弹进攻了这个地方
帝国军强大的达斯维德亲自开战机来攻击来袭的反抗军战机——最后需要卢克领悟原力，韩索罗辅助才完成战术
3、全面的场景
把每个用户使用产品每一个的场景都呈现出来是不现实的，但是，在设计这个产品之前，你可以先写下10-30个你认为的用户想使用你的产品的原因或者用户希望通过产品实现的任务。
场景和人物角色还可以结合起来，分类呈现不同类型的用户使用产品的原因，有什么样的需求，揭示出“什么样的人”在“什么样的场景”下会有“什么样的行为”。（也就是与常说的用户画像相结合）场景和人物角色可以通过时间的方式相结合来呈现，并且解释几个问题：为什么某类用户会使用你的产品?他们使用产品希望做什么?这类用户有什么特征?这些特征怎么影响到他们使用产品时的行为的?
因此，使用用户场景分析来设计一个产品的重心应该在用户以及他们想达成的目标，而不是产品的组织和内在架构。知道了用户的需求后，产品的内容及架构该怎么建设的方法就浮出水面了。
四、在可用性测试中使用任务场景
在为可用性测试设置场景时，因为时间不会那么充裕，所以你的设置的测试任务不宜过多。此外，在测试中，你还可以去设想去挖掘用户自己所处的场景，他们为什么要来使用你的产品，他们想通过你的产品获得什么。
可用性测试中，我们要做的事不是通过场景告诉用户如何去完成一个任务，而是应该在测试中观察用户是如何完成任务的，并根据用户的操作情况来判断：现在产品的设计是否能够帮助用户在复杂的环境与干扰下，通过你的产品实现自己的目标。可用性测试的场景不是要去高速用户如何使用产品来实现自己的目标。在可用性测试过程中我们会看到，用户是如何完成任务的，并且能告诉你设计的产品的流程、界面是推动还是阻碍了这个任务的完成。
在正式测试前，你必须预先设定好你所想要的用户完成目标的流程，包括用户可能使用的主要的入口或者其他的入口，测试人员在测试过程中去了解用户在场景下使用产品的情况。而在测试后，可对比下你的预期操作流程和用户完完成人物所经过的真是操作流程，这个对比可以帮助你分析产品构架的设计各方面的效率。
网友评论