用户画像PPS之用户故事：价值、类型与案例
为什么我们把Scenario翻译为“用户故事”？
如果直译，Scenario应该叫做“场景”。但在用户画像体系中，Scenario通常被认为是“用例”，是关于特定用户的场景故事。
一个合格的用户故事，应该开始于用户肖像，并根据用户需求活动添加生动的细节。用户故事描述特定的用户在特定场景下如何完成任务，包括人物、目标、时间和结果等等。
打个比方：如果说用户肖像是说明用户的“记叙文”，那么用户故事是饱含用户生活细节的“小说”。
用户故事的价值
用户故事是用于构想产品未来使用情况的设计技术，它关注用户如何实现目标，帮助设计和开发人员了解系统的实际使用方式。
用户故事是关于特定用户与系统交互的故事，可能基于一个或一组用例。
在产品开发过程中，用户故事能让用户更加形象化。它可用于早期的产品评估，可用于可用性测试，甚至可用于访谈提示。通过用户故事，产品的使用情景逐渐变得更加详细。
用户故事的类型
用户故事一般可分为情境故事和关键路径故事两类。
情境故事描述高阶场景，不涉及用户与产品的交互细节，而聚焦于用户如何实现其目标。
情境故事常常是需求定义阶段的一部分。
情境故事示例
Lisa正在听课。当老师讲到有丝分裂(mitosis)时，她感到到自己很困惑。她记下了当时的时间。
那天晚些时候，她打开bSpace课程网站，直接进入当天课程的网络广播，并通过网络课程回顾了当天课程中需要澄清的部分内容。
关键路径用户故事则加入更多细节，它将功能和数据需求纳入场景中。关键路径故事一般是UI框架定义阶段的一部分。
关键路径故事示例
Lisa正在听课。当老师讲到有丝分裂(mitosis)时，她意识到自己很困惑。她记下了当时的时间。
那天晚些时候，她打开bSpace课程网站，点击“最近的网络广播”链接。bSpace切换到“使用网络广播”视图，播放当天的网络课程。
Lisa看着她的笔记，找到她早先记下的时间，并将其输入“课程时间”字段，按下“回车”。课程直接跳到老师讲授有丝分裂的位置。
用户故事案例
不难想见，创建用户故事费时费力，不太可能、也没要必要覆盖所有可能的用户任务和状况。
通常的做法是：为主要用户创建用户故事，如果还有时间精力再考虑次要用户。
限于篇幅，明天继续介绍用户故事的内容和创建方法，这里先给出一个较完整的案例。
还记得这个用户肖像吗？
这个用户的名字叫做弗朗西斯，她的丈夫叫迈克尔，他们正筹划着买房。以下是他们的故事。
弗朗西斯和迈克尔商量好，主要由她负责了解购房过程。她上网，谷歌搜索“亚特兰大房地产”，然后点击链接，访问该网站主页。她看到主页可以搜索房子，便兴味盎然地输入亚特兰大，看看能找到有什么房子。
她发现，在不同的街区有各式各样的房子，于是便将她的搜索结果缩小到她和迈克尔居住的地方，并使用地图进行查看。仍然有很多结果，她不太确定使用哪些搜索选项来进一步缩小搜索范围。
然后，弗朗西斯注意到首次购房者的链接，可以获得基本的操作方法信息。这个链接将她带到一个逐步操作的教程，它解释了整个过程。弗朗西斯立刻觉得自己找到了正确的网站，便开始从中仔细查找房子。她仔细阅读了一些首次购房者的指导文章，边读边做笔记。她记下了她想回头再读的其他文章。
她还找到了网站的购房计算器，并开始尝试不同的数字组合，以找出她和迈克尔可以负担得起的房子。她特别喜欢计算器旁边的术语表，她终于弄明白什么是“积分”，并了解到不同类型的购房贷款。仔细研读了一个半小时，她觉得脑子全都塞满了，便将电脑关掉，休息一会儿。她感觉很开心，觉得开局良好。
第二天，她回到该网站，继续查找亚特兰大特定小区的信息，发现大量各种小区信息。她重点关注了五个看起来特别好的小区。当天晚上，迈克尔听她叨叨了她了解到的所有信息。于是，他们的购房乐趣开始了。他们决定，定期查看在线住宅列表。
小结
本节我们进入用户画像PPS框架的第三模块：用户故事。
既然是用户故事，本节主要是讲故事。我们回顾了什么是用户故事，讨论了用户故事的价值和类型，然后就是实例。
一条评论