体验设计7日谈之二：导演交付

今天我们谈什么？

今天我们谈体验设计是如何来导演整个交付的。

导演？

是的，就像拍电影一样，把整个交付用体验的方式来串联起来。我上个月曾经参加过上海一个敏捷社区的活动，一位来自著名游戏厂商的实践者提到了一个有趣的比喻：特洛伊木马。他把敏捷交付比作是给客户制作特洛伊木马，用史诗级（Epic）的用户故事去拆分这个未来存在于客户脑海里的特洛伊木马，把它们拆散放置在斯巴达的海滩上，成为供客户挑选用于组装的零件。

这就是敏捷的特点之一──我们把复杂的东西拆分成更小颗粒的“零件”，让客户进行选择，选择本身就是一种对交付范围的确认──我们把不在交付范围的东西放在了backlog中。

但是，一个从来没有见过“特洛伊木马”的客户如何知道他所选择的“零件”组装起来到底能干什么，这就是构建backlog的问题：我们是如何决定什么东西在backlog中？什么东西不在？评价标准是什么？那些在backlog中的东西是不是都是零散的而缺乏组织的？

如果你经历过一次交付前的需求调研活动，你会发现大部分的情况都是对于标书的拆分、细化和理解──最终的结果是功能列表。功能列表的问题是：当你跟客户说功能A和B哪一个是需要的，客户很难做判断以至于倾向于都要。

我不敢妄加揣测所谓敏捷需求调研活动是如何在更广范围进行操作的，据我了解，我们很多情况下只是用具备一定业务含义的用户故事（比如之前提到的史诗级故事）包裹具体的功能，摆在客户面前说：敏捷需要您提供优先级，看我已经把这些难懂的功能用业务语言描述了，还有业务价值（So That）哦。

其实，客户真的不知道在业务上，熟轻熟重，这样的优先级往往意义不大。

我们需要一种东西去引导客户选择他们想要的，去掉那些没用的，从某种意义上说，这就是一种导演。

你的意思是说，我们需要一种手段把交付的内容关联到一起，只有形成全局的概念，才能让客户更好选择交付的内容是吗？这就是你说的导演？

对，需要补充的是，这种全局描绘不单单是对客户，更是对整个交付团队。我们做用户故事拆分的时候，都会说某个用户故事是有价值的，这种价值传递给开发者的信息是“我为什么要做”，而这个信息并不足够产生足够的上下文，让开发者明白，在全局中“我为什么要做”。

单个用户故事的价值绝不等同于业务价值，只有一系列用户故事的共同作用才能产生实质的业务价值。也就是说，希望以用户故事的方式让开发者了解业务，不会跟按模块拆分任务有本质的差异。那么我之前讲到的用某种手段去将交付（用户故事）进行关联，是真正让开发者了解全局，感受业务价值的关键。

你一定要说，是体验将整个交付关联在一起

没错，这个核心的关联手段就是体验。而这里的体验，并不是指用户体验，而是把软件当成一种商业模式，它能够带给消费者的服务体验。

这两者会有区别吗？

答案是会。如果我们简单谈用户体验，那我们必然将讨论范围放在了系统本身的功能实现，而一个软件产品的成功，绝对不是一个IT系统能够单独完成的，它还包括运营、业务支撑等其他因素。如果我们不去讨论那些非IT化的因素，我们就不能建立起一个提供完整服务体验的商业模型，宏观的业务价值就是有缺失的。

那么怎么做呢？

大家应该了解Scrum当中backlog的概念，但实际上backlog只是一个等待进入开发的Story列表，并不能够直观地体现整个交付的全貌，所谓用体验来导演交付，本质上是丰富backlog的内容，使它真正成为交付的剧本。我们暂且把这个新的backlog叫做“体验地图”，下面我来介绍一下如何制作一个交付的“体验地图”。

我们用个点子为例，来讲解建立“体验地图”的过程，假设这个点子是：如何让消费者快速寻找到周围信用卡优惠信息。

第一步，你得找一处巨大的墙，有时候体验地图会很长。

第二步，所有的体验都是从产品的核心使用者出发，这个墙的最左边就是核心使用者，你当然可以把你们对核心使用者的调研结果写在墙的左边；

其次，所有体验必然是某种驱动驱使使用者达到某种或多种目标的过程，识别出使用者的驱动，在这个“信用卡优惠应用”的例子里，驱动是“例如让自己在逛街时迅速了解自己信用卡可以获得的优惠”，而目标可以是“最终成功地使用信用卡获得优惠”。把“驱动”和“目标”写在墙的两边。就像下面这个样子。

第三步，把为了达到最右边的目标需要做的事情展示出来，这里的事情不单单包括他所使用的产品功能，为了使整个体验更加的真实，可以把与产品功能无关的事情也描述出来，就像下面所示：

第四步，为了让过程更加可视化，你可以选择将部分用户原型界面贴在某些步骤旁边，就像下面的样子：

第五步，把你识别出来的用户故事或者技术任务体现在体验地图上，可以用各种颜色的标签来体现故事的各种信息：是不是最基础的用户故事？风险高低？是不是后台运营的用户故事等等，你可以按照项目实际情况去丰富，就像下面所示：

第六步，到现在你已经有了一面非常好的体验地图，你未来交付的用户故事和技术任务都在这张地图上展示得一清二楚，不管是你的开发人员还是你的客户，都可以从这张图上看到这个产品概念是如何一点点被转化成可用的产品的。最后的关键一步就是和迭代交付的那面墙合二为一：

每个迭代都要从左边的体验墙中挑选合适的卡片放入迭代故事墙；当一张卡片最终验收通过时，又把这张卡放回体验墙上，贴上个笑脸标签，当整个交付结束你会看到整整一副满是笑脸的体验地图，那么就说明，我们的主人公通过我们的产品完成了自己的目标，整个项目便可以上线了。

在整个过程里，团队里的每个人都知道每张卡从哪里来，为什么要做，它会对其他卡有什么影响，有什么卡依赖它；对于客户来说，每个迭代只需要关注这张体验墙就会明白，自己的产品做到了什么程度，这是不是比和Scrum Master一起浏览冷冰冰的Backlog要好得多？这就是我说的，使用体验来导演交付。

太好了，我也可以尝试着把我们的Backlog换一种形式，可是似乎能把这个体验地图描绘出来也需要一些分析啊。

这就是我们下一次的话题，怎样快速地设计出一副好的体验地图来，很多时候我们都会在项目的初期做这样的事情，我们下次再谈吧？