一款产品在初创时间通常有相对核心的一个目标，随着产品的逐渐发展和迭代，如何依然专注于用户的核心任务呢？
我们可以通过三个步骤展开：
围绕用户故事来设计软件。
这篇笔记，将依次介绍什么是核心任务、为什么要专注核心任务；什么是用户故事、如何通过用户故事表达核心任务和目标。
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：
在确定常见的、关键的任务时，可以采用头脑风暴的方式，描述10个red routes，每张便签纸上写一个。
描述的这10个red routes核心任务，来自“使用产品的首要人物角色”的关键任务（要关注首要人物角色的任务，而不是你以为的任何人都想做的事）
这些任务是一系列的行动，所有请用“动词”开头。
用户故事 user story
1、用户故事的作用
两个用户，他们有相同的用户需求red routes——找一家酒店、预订一个航班。但是他们有不同的使用情境，一位是与伴侣的一次浪漫的旅游，另一位则是两天的商务出差。
尽管用户需求相同，但不同的使用情境将改变你帮他们达成目标/完成任务的方式。用户故事，就是一种将使用情境纳入到你的任务中的方式。
2、用户故事的表达方式
用户故事，是敏捷开发的一个关键组成，它有一个特殊的结构——“作为一个用户，我想要…，所以我能…” 。其中关键元素有 user用户、task任务、goal目标。因为用户故事通常写在卡片上，所以也叫做故事版。
以前面提到的预订酒店的需求为例，将一些使用场景嵌入到故事当中，就可以这样表达：
作为一个商户出差者，我想找到有商户中心的酒店，这样我能远程工作
作为一个旅游者，我想找到房间的图片，这样我能和我的伴侣拥有一个浪漫的周末
作为一个旅游代理，我想到处我的历史预订记录，这样我能为我的顾客开具发票
3、怎样从red routes 核心任务 到user story 用户故事？
课程介绍了两个正例、一个反例：
我们可以重点看看反例，它描述的任务task是”我想了解怎么计算我的缴税代码”，目标goal是“这样我能确认我在使用正确的缴税代码”。
事实上，这样的用户故事限制了解决方案，也并不是真实的用户的初衷。真实用户的任务task是“我想要缴纳正确数额的税”，目标goal是“这样我能拥有我应该有的钱，并且避免预期之外的税金”。
对于这个反例，修改前后的用户故事如下：
（用户故事修改前后）
小贴士：在red routes中挑选2-3个更为重要的，来建立用户故事并写在卡片上，不需要为所有的任务创建用户故事。
4、 怎样测试一个用户故事是否合适/正确？
这件事，是真实的用户希望说的？
这件事，可以帮助你设计或者更为优先的处理吗？
它不必要的限制了可能的解决方案吗？（ 专注于目标，而不是具体的步骤、简单的实现方式）
你有好的证据吗？（ 比如，来自情境调研中真实用户的故事）
