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

今天我们谈什么？

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

导演？

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

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

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

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

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

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

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

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

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

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

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

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

这两者会有区别吗？

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

那么怎么做呢？

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

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

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

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

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