| 文章描述：怎样设计一个像样的Scenario — Everett Mckay（前微软项目经理）. |
现在基于scenario的设计已经被广泛的应用到了各种产品设计中。大家发现，很多时候一个短小精悍的小故事往往比一大段枯燥的介绍更来的实在和有趣。但是在我的工作过程中，实在是见过不少非常糟糕的scenario，下面就是一个典型的例子：
Joe在Fortune 500公司上班。他的工作常常需要他查询客户的Snarfbladt资料。他发现Bladtblaster 2000能够让他在bladtblaster的网站上更快的获得Snarfbladt的信息。这让Joe非常高兴。
这个scenario有什么问题？简单来说，全部。它其实算不上是一个scenario，而只是一个单薄又毫无营养的“广告”，用来告诉某人：“OK，那里有个客户需要Snarfbladt的资料，所以别砍掉这个功能。”除开这个，这个scenario就没什么其他作用了。不幸的是，我见过的大部分scenario都跟上面这个例子差不多。
基于功能的设计 和 基于任务的设计
为了进一步了解问题的所在，我这里先先简单回顾下基于情景设计的历史（scenario-based design）。在早期的软件设计中，大部分公司的软件都很给力。因此，同行之间经常会有“功能竞赛”，比谁的软件能做的事情更多，比谁的软件附加功能更多。在那段时间，基于附加功能的设计（feature-based design）诞生并占了主导位置 — 哪家软件公司的产品的feature列表越长，哪家公司就貌似越NB。
这个东西的弊端就在于，用户的根本目的不是去使用这些功能，而是通过这些功能去完成不同的任务。所以，这些丰富的功能一开始貌似非常吸引人，但不久，用户就发现其中很多的功能对于他们完成主要目标没有任何帮助。因此，基于用户任务的设计（task-based design）诞生了，用来帮助用户更加快捷方便的完成他们的任务。
基于情景的设计
尽管基于任务的设计在一段时间内看上去挺不错的，设计师们还是越来越感觉到了它的局限性，问题出在哪里呢？因为在设计用户体验的过程中，“目标用户群”这个概念越来越重要，然而基于任务的设计完全就没有考虑这一块！另外，基于任务的设计往往导致“设计师设计他们自己喜欢，而不是用户喜爱的东西”。
好的设计需要在设计时候有一个清晰的思路：“这个产品是为谁设计的？”，“这个产品需要为这些人做什么事，解决什么问题？”。随后，基于情景的设计（scenario-based design）才渐渐被引入进来。前文说了这么久的scenario，到底什么才是scenario呢？
一个情景（scenario）描述的是目标用户怎样在特定的环境里完成特定的任务。
或者更简洁一点：
情景 = 用户 + 任务 + 环境
因此，scenario-based 和 task-based的最大区别是牵着专注于产品的用户和使用环境。好的设计必须同时具备易用性和高的用户满意度。设计scenario瞄准的是用户满意度这一块，而基于任务的设计大部分时间只能让产品可用和易用而已。
因此，一套经过深思熟虑的scenario将对你的产品带来极大帮助。如果你在设计过程中弄出来的新东西没法跟你的scenario对上号，那你很可能是做错了。
Scenario 分析
让我们再回到文章开头的scenario — 它到底有什么问题？我们来逐字逐句的分析下。
Joe在Fortune 500公司上班。可以说这是用一种最没意义的方式带出用户和他所处的工作环境。你从这句话中了解不到任何关于joe的具体信息，目标用户并没有被准确定义 — 他可以是任意人，处于任意地点，做任意事情。
他的工作常常需要他查询客户的Snarfbladt资料。还好，至少用户目标被定义了。
他发现Bladtblaster 2000能够让他在bladtblaster的网站上更快的获得Snarfbladt的信息。这就是那条“为什么Joe需要这个功能”的广告了。但是难道就没有任何其他解决问题的方法了吗？只此一条路？如果有其他途径，你需要把他们放到scenario中，然后通过scenario说明Joe为什么不选择它们。
这让Joe非常高兴。这是一个典型的在写Scenario时很容易犯的先入为主的错误，下面会详细说说。
“这让Joe非常高兴”这句有什么问题呢？
也许会显得有点太钻牛角尖了，但是用一个“高兴”的用户来为一个scenario结尾是一个大错误！为什么？参考下Everett的“基于情景设计的原则”：
如果写scenario的意义在于证明某个/某些功能是成功的，那显然你并不是在做基于情景的设计（scenario-based design），你是在做基于功能的设计（feature-based design）！
使用scenario的目的不是为了“取悦”Joe，否则你直接给他他想要的功能不就得了。Scenario的目的是找出Joe为什么高兴，系统中的那一部分取悦了他。这一部分重要的信息必须要包含在scenario里，遗憾的是它并没有。总的来说，举的这个例子，它名义上是基于情景的设计，实质上又回到了基于功能的设计的老路上。
改进后的新Scenario
Joe在一家大型公司的货运部门工作，平均每天要负责200个包裹的签收和发送工作。为了保持一个积极的工作态度，他经常加班，做一些额外的工作。
在做包裹的发送工作的时候，Joe常常需要查询客户的Snarfbladt资料。他发现Bladtblaster 2000能够让他在原理办公室电脑的地方从bladtblaster的网站上轻松获得Snarfbladt的信息。无论如何，他可以在签收和发送货物的时候使用它，只需要单手操作 — 大部分情况下都可以在3次点击下完事。
可以看到，新的scenario更加丰满。它并没有告诉你“Joe很开心”，而是详细的绘制了Joe的个人和工作情况。在此基础之上，我们可以更加自信的捕捉那些会让Joe高兴和挫败的部分，从而发展出新的，更加丰富客观的Scenario。
本文编译自唐卓，原文地址。