如何专注于用户的核心任务：red routes 与 user story

一款产品在初创时间通常有相对核心的一个目标，随着产品的逐渐发展和迭代，如何依然专注于用户的核心任务呢？

我们可以通过三个步骤展开：

1. 确定用户的核心任务；
2. 采用用户故事来表达这些任务和目标；
3. 围绕用户故事来设计软件。

这篇笔记，将依次介绍什么是核心任务、为什么要专注核心任务；什么是用户故事、如何通过用户故事表达核心任务和目标。

red routes核心任务

1、 什么是 red routes

在伦敦，有红线的路叫做red routes。他们是伦敦的重要交通动脉，伦敦运输部做了他们所能做的一切事情，来保证这些路线的清晰。

软件也有 red routes，他们就是软件的关键“用户行为路径user journey”，也就是用户完成核心任务的行为路径/操作路径。

2、red routes 核心任务 的重要性

每个应用都有一小部分重磅的、核心的任务，来达成一个巨大的价值；当然也同样有较大一部分不那么重要的任务，他们可以削弱核心任务的价值。成功的开发团队，坚持不懈地专注于提升用户核心任务的可用性。比如： Dropbox，专注于让分享文件更简单。

如果没有red routes，可能**出现下图的界面，混杂着各种各样的信息。对于开车的司机来说，他们的主要任务是看清楚前面的路，但显然图中的设计干扰了用户去完成他们的主要任务。

（汽车表**）

如果没有核心任务，瑞士军刀可能做成大杂烩，最终任何一个用途都用起来异常困难、事与愿违。

（瑞士军刀）

3、red routes在用户体验设计中有何作用？

red routes 帮助你专注于由首要人物角色确认的“最重要的场景”、为最常见的用例设计。

red routes 产生了可操作性的结果。我们能做的就是让用户坐在我们的系统前，请他们使用我们的系统完成某个特定的目标（从red routes开始），然后看他们如何操作、他们经过了那么地方、他们遇到了哪些障碍、他们犯了哪些错误。优化、修复这些问题之后，系统将**变得更加易用。

red routes让用户更容易、花更少的时间做出选择。根据hick’s law 席克定律，如果给用户越多的选择，他们就要花更多的时间来做决定。如果不专注 red routes，就可能像iTunes一样，用户不知道该怎么用，既给用户带来干扰、又降低了使用效率，浪费时间和开发成本。

4、如何确定red routes核心任务？

• 步骤1：确定常见的、关键的任务
• 步骤2：根据两个关键点“有多少用户**做这个任务”、“有多频繁的做这个任务”，将列举的任务放置在这样的坐标当中（这**让你感知哪些是有价值的）

以车载导航系统为例，它的red routes是什么呢？如下图，根据纵轴——使用频率、横轴——使用的用户数 来分布常见的、关键的任务，由此可确定右上角的几项是需要重点关注的功能，也就是“核心任务”。

（确定核心任务）

在快速实践这种“确定red routes”的方法时，我们还需要注意几个tips：

1. 在确定常见的、关键的任务时，可以采用头脑风暴的方式，描述10个red routes，每张便签纸上写一个。
2. 描述的这10个red routes核心任务，来自“使用产品的首要人物角色”的关键任务（要关注首要人物角色的任务，而不是你以为的任何人都想做的事）
3. 这些任务是一系列的行动，所有请用“动词”开头。

用户故事 user story

1、用户故事的作用

两个用户，他们有相同的用户需求red routes——找一家酒店、预订一个航班。但是他们有不同的使用情境，一位是与伴侣的一次浪漫的旅游，另一位则是两天的商务出差。

尽管用户需求相同，但不同的使用情境将改变你帮他们达成目标/完成任务的方式。用户故事，就是一种将使用情境纳入到你的任务中的方式。

2、用户故事的表达方式

用户故事，是敏捷开发的一个关键组成，它有一个特殊的结构——“作为一个用户，我想要…，所以我能…” 。其中关键元素有 user用户、task任务、goal目标。因为用户故事通常写在卡**上，所以也叫做故事版。

以前面提到的预订酒店的需求为例，将一些使用场景嵌入到故事当中，就可以这样表达：

1. 作为一个商户出差者，我想找到有商户中心的酒店，这样我能远程工作
2. 作为一个旅游者，我想找到房间的图**，这样我能和我的伴侣拥有一个浪漫的周末
3. 作为一个旅游代理，我想到处我的历史预订记录，这样我能为我的顾客开具发票

3、怎样从red routes 核心任务 到user story 用户故事？

课程介绍了两个正例、一个反例：

（核心任务 and 用户故事）

我们可以重点看看反例，它描述的任务task是”我想了解怎么计算我的缴税代码”，目标goal是“这样我能确认我在使用正确的缴税代码”。

事实上，这样的用户故事限制了解决方案，也并不是真实的用户的初衷。真实用户的任务task是“我想要缴纳正确数额的税”，目标goal是“这样我能拥有我应该有的钱，并且避免预期之外的税金”。

对于这个反例，修改前后的用户故事如下：

（用户故事修改前后）

小贴士：在red routes中挑选2-3个更为重要的，来建立用户故事并写在卡**上，不需要为所有的任务创建用户故事。

4、 怎样测试一个用户故事是否合适/正确？

1. 这件事，是真实的用户希望说的？
2. 这件事，可以帮助你设计或者更为优先的处理吗？
3. 它不必要的限制了可能的解决方案吗？（ 专注于目标，而不是具体的步骤、简单的实现方式）
4. 你有好的证据吗？（ 比如，来自情境调研中真实用户的故事）

这篇笔记就到这里啦！

#专栏作家#

青溪Joanna，微信公众号-青溪札记（qingxizhaji），交互设计师一枚，喜欢体验各种App，关注社交、在线旅游、O2O、工具类产品；擅长需求分析、交互设计，有一定前端开发经验；业余时间喜欢网球、ukulele、简笔画，正在努力攒技能。

本文原创发布于人人都是产品经理，未经许可，不得转载。