如今基于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。

本文编译自唐卓，原文地址。