对于理论以及长篇大论的需求文章来说，人们更能记住故事发生的场景，通过简短但是详尽的故事描述，让程序员和设计师来理解，产品的用心良苦，从而达到，为用户提供设计服务，而不是产品单方面的猜测。
让我们来了解一个简单而又强大的工具，这是一种很好的设计方法，你可以在所有项目中应用它，同时可以增强所有利益相关者的合作。
敏捷设计的核心部分是用户需求也就是用户故事。有很多关于 UX 和敏捷开发的文章，很多人都在喋喋不休地谈论敏捷开发如何使用户体验不友好，这两种方法如何无法协同工作等等，并且很难适用于软件项目，与其他学科合作很有挑战性。虽然我们正在努力，但我们可能会对许多缺点说“是”进行妥协，而且我们不会在一篇文章中解决这些问题。
今天我们关注的是一种简单快速的设计方法，称为“用户故事”，可以帮助您解决许多这些挑战。
为什么？
用户故事简短，具体且面向目标。这是一句话，往往具有以下结构：“作为一个，我想这样”。
用户故事是协作设计工具，期望所有项目利益相关者参与用户故事的定义和排序。
这听起来不是以用户为中心的哲学和发展过程的核心吗？然而，它是来自敏捷开发的工具。
那么，为什么不接受它们呢？
当然，有些团队不进行任何用户研究，并根据他们的想法编写用户故事。虽然这不是最佳选择，但它比考虑“我”要好得多。一点想象力可以创造奇迹，同时注意用户与设计者的不一样。只是为了强调这种思维方式的相关性，你可以向所有利益相关者，解释一下像下面这样的小方案。
“例如，如果你必须设计一个迎合音乐家的网站，他们可以选择风格和效果来帮助他们创作歌曲，你需要考虑很多类型的音乐家。客户要求提供具有各种效果的菜单。可能你会突然想到的是汽车音响的CD上的一首歌，抛弃这个想法吧，因为你想的是“我”。
相反，想一想：
“我” 可以是任何专门研究一种或多种乐器的音乐家。如果你认为“我”是一个沉重的摇滚吉他手，那就回去考虑一下键盘手，歌手，贝司手和鼓手……或者，也许是一位古典作曲家正在起草一部歌剧，并希望查看一些关于乐谱的想法。
“我”也是任何类型的作曲家。这可能是轻松倾听，电子化，或者是，精致，沉重的摇滚乐。或者，它可能是一位古典主义者，他被委托为一部你未曾见过的电影编写原声带。
太好了！现在我们已经设法让团队思考“更多的可能性”以适应我们的用户，我们能够创造用户故事。用户故事的格式迫使我们站在他人的角度进行思考，同时将他们的需求放在焦点上，对于同理心的工作，可以让自己置于用户的角度。
也许，有时候，我们不会根据实际数据做到这一点，但这是一个开始。也许通过这种微小的同理心练习，管理层和团队成员可能会理解出去寻找目标用户的必要性！
理想情况下，作为用户研究员，您应该在用户故事的定义上起带头作用。您可以将您的角色（我们创建的虚构用户）和用户场景带到用户故事会话中，并为所有利益相关者构建正确的框架。如果没有用户研究阶段，只需确保收集尽可能多的现有项目信息。这可以来自日志或分析，来自客户支持，来自计算机研究，竞争分析等。在我们音乐网站的互动场景中，我们很幸运的是客户告诉我们，他是主要为电视节目中的音乐处理的键盘手。
作为用户体验设计师，您是项目开发期间用户的“声音”。尝试用尽可能多的现实环境进行思考，并将这个“用户声音”翻译成用户故事，以便每个人都记住它。
如果你来自“旧学校”，你可能还记得用户用例。也许用户故事会提醒你关于你用户的一切。好吧，虽然有一些相似之处，但差异性使得用户故事更好。
用例具有特定的语法和结构，因此，并非每个人都参与定义它们，只有负责定义要求或功能规格的团队或负责人才能编写。用例是客户端（有时是用户和开发团队）之间的桥梁，因此，促进“轮胎摆动”模型，我们看到会发生什么……
在上图的模型中，我们发现了每个人对于用户的需求解析出现了一些可怕的错误！但用户故事以其简洁和专注，提供了避免此类情况的完美方式。参与团队的任何人都可以参与其中。他/她只需要了解特定语法的相关性：
作为一个 。角色指的是做出行动和受益的人。
我想要 。这是执行的动作。
以便 。它是用户从操作中获得的附加值。
通过这个简短的陈述，用户故事可以缩短学习时间！如果您来自参与式设计方法，您还可以让用户参与用户故事的撰写。
正如我们之前所说，您作为用户体验设计师的目标是促进最终用户的具体，现实和共享的愿景，用户故事是你最好的盟友。由于它们的可访问性和灵活性，您可以使用它们来构建公共语言和项目所涉及的常见心理模型。因此，您可以让所有利益相关者 – 客户，管理层，团队成员 – 使用相同的语言，并专注于用户以及项目正在尝试实现的目标。
用户故事促进了项目讨论方式的转变，我们不再关注解决方案和功能。我们专注于“真实”用户能够为特定目的而努力的目标，我们没有一个可疑的抽象功能列表，我们将项目的最终目标集中在如何让用户做具体和有形的事情上。
用户故事通常写在Post-its上，起初，Post-it的数量可能是压倒性的，但它比永无止境的需求文档更易于管理！
用户故事具有恰当的详细程度。在更抽象的层面上，我们有“epics”。在敏捷开发中，“epics”用于所需功能的高级概述。因此，他们收集了一组用户故事。如果您正在构建亲和关系图，则epics将是一组常见用户故事的名称。 Epics使项目中的每个人都可以从许多用户的角度看待设计，那么任何不合理的方面都可以显示出来。用户是否需要“尝试”未经计划或计划得好的东西也可以通过此得以验证。
用户故事必须足够具体，以便项目团队可以在冲刺期间选择并处理它们。在此之前，团队应该从一开始就深入研究细节并解决可用性问题。作为用户界面设计师，您应该成为项目团队的一员，并与开发人员合作，使用户故事真实可用。
用户故事的简单语言有助于每个人了解每个sprint中正在构建的内容，所有利益相关者都可以查看他们的关注点和需求是如何得到解决的。因此，用户故事非常适合设置阶段和定义项目范围，它们也是定义后续步骤的理想选择。因为它们处于完美的粒度级别（即完美的细节级别），所以当项目遭遇特殊变动时，用户故事可以帮助你更好地看清一切。
选择
用户故事一开始是作为敏捷和SCRUM开发方法的一部分，作为用户体验设计师，我们需要拥抱它并使用这种简单的方法来实现我们自己的“好处”，这对于用户而已也是很好的设计方法！
用户故事为设计人员提供了创建用户的真实，具体和共享理念所需的一切：
用户故事基于用户目标; 因此，他们可以专注于产品的核心用户；
用户故事是易于访问和管理的; 因此，它们促进利益相关者和团队成员之间的协作；
通过一个非常简单和具体的结构，用户故事可以帮助项目专注于许多方面，例如：以用户为中心，以目标为中心，以及在每个阶段应该实施什么内容，如何选择和抛弃。
敏捷开发是一种很好的以用户为中心的设计方法，不单单是因为它可以为我们提供研究和计划的一个更好的方向，同时他还可以帮助我们构建以及创造出项目中每一个可能性的转折点，用户故事为我们提供了在最重要的用户研究和用户需求方面的一个可靠的理解和体会。
个人感想
我作为一名产品经理，当我去开启一个项目，进行背景以及功能点的解说是，我通常会采用用户故事的方法来叙述整一套的用户流程，同时我也希望我的团队这么去做。对于理论以及长篇大论的需求文章来说，人们更能记住故事发生的场景，通过简短但是详尽的故事描述，让程序员和设计师来理解，产品的用心良苦，从而达到，为用户提供设计服务，而不是产品单方面的猜测。
建议大家可以多采用 Persona 以及 Scenerio 来为更多人讲述你设计的产品的初衷。只有当你成功的说服了别人，人们才会愿意为此埋单。
