用户故事地图怎么用？实践才能出真知

在产品设计和交互过程中，用户体验是一个非常重要的部分。 随着产品的逐渐完善，主创团队也需要通过各个维度来了解用户需求，完善用户的整体体验。在这里，我们经常用到的一个实践是用户故事地图。

一、用户故事地图是什么？

我们可以把用户体验整个产品的行为当作用户的旅程。在整个旅程中，用户是不能第一步就发现产品的所有价值的，需要经过各种活动及行为的触发，来深入进行体验，从而挖掘出产品的价值。

用户故事地图

那用户故事地图就是一种安排用户故事的方法，它将用户旅程的基本步骤安排在水平轴（行）上，将用户故事安排在相应的步骤（列）下面，在同一列中，用户故事的优先级由上至下依次降低。当用户故事地图完成时，我们可以在单一的逻辑视图中看到用户与产品交互的所有方式，从第一次交互到完成总体用户目标。使用用户故事地图，可以通过更全局的视角了解用户故事如何融入整体用户体验。

二、我们要如何使用用户故事地图？

首先第一步，确定目标用户

在确定目标用户之前，我们还需要对齐一下产品的定义以及产品的目标。也就是说，我们需要在内部明确我们到底要做什么、我们为什么要这样做以及用户的价值。接下来我们就需要确定产品的目标用户，比如当当的目标用户是新书、畅销书购买群体；而孔夫子旧书网的目标用户则是古旧书、绝版书购买群体。

确定好目标用户之后，我们就要来梳理目标用户的用户故事了。

第二步：确定用户故事

在这一步中， 我们需要确定的是主干用户故事。举个例子，如果我要在周末去吃饭，可能会将这个活动拆分为起床-洗漱-换衣服-选择餐厅-出门-到达餐厅。那在这个时候，我们可以将这些主干用户故事放在用户故事地图的最上一层。

接下来， 我们需要将这些用户故事进行更加细致的拆分：洗漱我们可以拆分为洗脸、刷牙、护肤等。这些颗粒度更细的用户故事可以放在主干用户故事的下面一层。不过在这里我们要注意一点，我们不需要将用户故事进行非常细致的划分，比如：将起床拆分为睁开眼睛、从床上坐起来等等，因为这种维度的拆分是已经落实到非常细节的执行中了的，如果只关注在这种颗粒度的话，会让我们过早地深入探究“如何实现产品”中去，而忽视了高纬度的产品设计。

在拆分用户故事的时候，我们需要去 发散一下自己的思维：比如用户在这个部分会去做什么？怎样才能提高用户的体验？用户还有没有其他的方法来完成这个步骤等等……

等大家发散了自己的思维之后，我们就会得到一个比较完善、有条理的用户故事。

第三步：做好用户故事的优先级排列

既然我们的主干用户故事和更细化的用户故事已经出来了，接下来就需要对这些拆分出来的用户故事进行优先级以及自上而下的排序，优先级最高的用户故事放在上面，并依次递减。

第四步：沟通确认

用户故事是需要和客户/用户以及团队成员进行最终确认的，防止出现产品需求方面的偏差。确认完成之后，我们就需要排发布计划了，在协调好手中的时间、人力等各方面的资源后，将需要开发的用户故事排为产品计划，在接下来的时间内逐步交付。

对于项目团队来说，用户故事地图能够帮助团队从用户视角来考虑问题：

能够帮助团队更好地了解他们为什么要构建软件，以及软件如何融入全局。

除了一些罕见的例外，任何软件产品都只是更广泛的业务活动或客户体验的一部分，通常在与软件交互之外开始和结束。软件可能只是加速某些活动的某一部分，或者提供一种新的做事方式。规划用户旅程有助于团队在更广泛的背景下考虑用户故事，发现遗漏或不必要的步骤，并创造新的产品创意。

避免线性思维。用户故事地图有助于优先级划分、故事拆分，并为发布计划提供重点。特别是，通过规划一段旅程，然后在每个步骤中考虑故事，这样故事地图帮助团队将用户故事视为选项，而不是承诺。

将交互设计融入迭代交付。故事地图提供了一个很好的框架，用于考虑用户交互过程，并在此背景下绘制迭代版本和里程碑。这样就更容易规划交互设计工作，优先考虑与即将到来的里程碑相关的部分。

促进迭代交付。通过将相关故事分组在一起，利益相关者通常会看到，他们可以通过更简单的可交付成果选择来启用某些操作，并将更复杂的故事推迟到以后的版本中。

总之， 使用用户故事地图，就可以“既见树木，又见森林”，考虑问题更全面，规划交付更轻松，并引导以用户的视角看待问题，提升软件的价值，同时提升与用户沟通的效率。