作为更大的数字产品叙事的一部分，与 用户故事 在整个设计过程中帮助设计师专注于改善用户体验. 清晰的用户故事可以帮助用户始终处于设计过程的中心, 与产品的目标受众产生共鸣, 并产生更适合人们生活的想法.

产品设计师经常发现自己处于谚语所说的“本末倒置”的境地吗? 随着项目的启动，我们制定了技术细节以及如何交付它. 定义了开发框架, 确定目标设备, 屏幕尺寸设置, 然后团队开始创造解决方案, 随机添加产品功能.

在这个过程中, 我们疯狂地生成了大量的用户体验工件:情绪板, 站点地图, 用户流, 角色, 同理心图, 举几个例子. 船装好了，却没有舵，也没有地图. 然后有一天，我们醒来，突然意识到这一点。”我们为什么要做这个产品，我们如何定义它的功能，以及我们如何优先考虑它们?”

经典的叫醒电话.

可怕的“功能蔓延”就在我们眼皮底下悄悄逼近.

幸运的是，有一个对抗它的对策. 这是一种设计策略，叫做 用户故事.

用户故事是产品团队的一种协作设计技术, 采用敏捷软件开发方法. 敏捷团队通常专注于在sprint期间实现小目标. 他们 强调速度、目标和结果 而不是大量的文档，因此有了用户故事的概念.

对于大多数敏捷团队来说，用户故事是增量软件交付的主要载体. 敏捷联盟

什么是用户故事?

用户故事描述了用户想要完成的事情. 用户故事可以提供帮助 设计师 而开发团队则专注于用户需求, 而不是陷入增加产品功能的狂热中.

用户故事是简短、具体和目标导向的. 它是一个从用户角度出发的一句话陈述，具有以下结构:

“作为一种(用户类型)，我想要(目标)，这样我就可以(获得利益)。.”

用户描述使团队能够在整个开发过程中就项目进行更好的对话. 它有助于防止功能蔓延，因为与它们一起工作有助于实现 对团队正在尝试构建的内容及其原因的共同理解.

如果在用户界面设计和人机交互领域有什么原则是神圣的, 它是 了解你的用户. 唐·诺曼，尼尔森·诺曼集团的联合创始人和名誉校长

在设计和敏捷之间调整用户故事

用户故事是开发人员理解的概念. 无论是在项目开始还是在产品开发过程中, 通过使用用户场景，设计人员可以与开发人员更有效地协作. 产品功能可以一起规划，优化开发，清晰化 团队应该关注什么结果 on.

也就是说, 许多设计师并不认同这种观点 敏捷和用户体验 可以一起玩得很好. 其中一个信念是，这两种不同的激励力量和时间线不能很好地结合在一起，用户故事不容易适应整体设计过程，因为, 在开发中, 重点是短期交付周期. 另一种观点是，用户故事作为一种设计方法不够实质性——它们缺乏考虑大局的视角: 完整的用户体验.

这些信念在某种程度上是正确的，但也 被误导的.

让我们消除误会吧. 首先，设计师需要认识到，处理用户故事是一种挑战 协同设计流程. 虽然它在开发方面可能与敏捷冲刺不完全一致, 它们可以成为更广泛的 与开发人员协作时的异步设计过程. 用户描述还使位于不同位置的团队更容易进行协作.

第二, 用户故事是以人为中心、以活动为中心的设计的重要组成部分. 而不是专注于增加越来越多的产品功能-众所周知的“功能蔓延”-用户故事使其成为现实. 用户故事是人们执行的每个活动的背后, 哪些是由任务组成的, 这又是一系列的行动. 因此，产品的开发是基于对用户活动的深刻理解. 使用用户故事很好地适应了 设计 令人愉悦的用户体验.

产品测试和用户体验度量的用户故事

清晰的用户故事为优秀的产品设计提供了多方面的动力. 定期回顾用户故事并检查是否可以实现特定的用户目标验收测试 对于一个给定的用户故事——将帮助产品团队保持在正轨上.

企业经常花费大量的时间和金钱来制造客户不需要或不想要的产品, 浪费时间和资源. 这些产品可能是出于好意, 但它们之所以失败，是因为它们没有以消费者理解的方式解决可识别的需求.

通过在潜在客户身上进行用户测试，产品团队可以理解 如果产品解决了一个清晰可识别的需求. 这是衡量成功的一种方式. 基于定义良好的用户故事构建和测试原型， 设计师 能否衡量任务完成时间和成功率. 不仅在产品早期设计阶段，而且在整个产品开发生命周期中. 这样做时， 团队可以看到产品在满足客户需求方面是否越来越好.

此外，用户故事可以用来定义用户体验结果(通过 用户体验成功指标)，并帮助设计师通过用户体验进度指标检查产品的演变.

• 用户体验效果 让每个人同步了解正在建造的东西.
• 用户体验成功指标 告诉团队他们什么时候完成了结果.
• 用户体验进度指标 使团队能够跟踪和评估进展.

如何生成优秀的用户故事

用户故事的创建从人物角色开始 用户研究见解. 对人物角色的深刻理解将有助于设计师创造有意义的故事，与更大的用户目标联系起来. 在这个过程中，可以发现未满足的用户需求，并构建产品叙事 史诗 在敏捷).

设计师可以采用实质性的用户体验叙述, 由角色和用户目标驱动, 把它们分成更小的部分: 用户故事. 例如，假设我们正在开发一款手机银行应用. 的 史诗的 目标是“在忙碌中管理资金”.这个更大的用户目标可以分成更小的用户故事，比如:

• 作为一个企业主，我想做移动存款，这样我可以节省时间.
• 作为一名企业主，我想申请贷款，以便更快地获得信贷.
• 作为一名企业主，我想用一个应用程序检查我的账户，以掌握我的财务状况.

我们如何想出这样的用户故事? 通过使用各种用户体验研究技术, 比如影子(一种观察技术), 日记研究, 用户访谈. 另外, 设计师可以使用产品分析来识别用户行为模式，并揭示驱动这些模式的底层结构.

例如，通过观察事件流，数据可能显示有几个任务无法完成. 任务已启动, 取得了进展, 但在任务进行到一半时意外退出表明了这一点, 他们没有得出结论. 这样的模式会导致人们在沮丧中放弃，因为产品没有提供一种简单的方法来完成一组协调的任务. 一个敏锐的用户体验设计师会发现这个问题, 进行更多的用户研究, 重新设计没有发挥作用的产品功能, 再次测试任务完成情况.

如何编写用户故事并确定优先级

谁写用户故事? 传统上, 编写用户故事一直是产品经理推动开发的责任(通常在团队中没有设计师的情况下)。. 然而，当团队中有设计师时，最好是由设计师来写. 他们进行过用户研究，最熟悉用户角色和他们的需求.

作为一种技术, 用户故事应该是紧凑而轻巧的, 允许团队快速构建产品. 如前所述, 它们需要写成简单的, 从用户的角度看一句话:作为一个(用户)，我想(做某事/目标)，这样我才能(达到预期的结果)。.”

以这种方式创建的用户故事有助于证明添加到产品中的每个功能的合理性，并将每个设计决策背后的基本原理放在首位:我们为什么要做我们所做的.”

要写一个优秀的用户故事:

• 它应该是清晰的、重点突出的、可操作的.
• 它应该以一种感觉有价值的方式捕捉故事.
• 它可以转化为产品特性.
• 它有一个验收测试(目标是否实现)?).

一旦写好，用户故事就需要按优先级排列成矩阵. 这对产品经理来说很熟悉, 优先级矩阵有助于确保产品团队首先关注最具影响力的特性. 为 设计师，这意味着优先考虑为客户提供最大价值的用户故事.

以下几个方面会影响用户故事的优先级索引:

• 业务目标. 直接影响公司收益的用户故事应该比那些仅仅令人满意的用户故事获得更高的指数值.
• 函数依赖. 如果多个用户故事只能在一个特定的故事之后实现, 后者变得至关重要，并获得更高的指标值.
• 开发时间. 如果开发团队评估一个用户描述是快速实现的，并且对于实现业务目标是必不可少的, 那么故事的索引值就会更高.

用户故事在设计中的好处

使用用户故事框架可以确保产品只具有用户需要的特性. 基于假设，产品团队希望他们使用的功能. 换句话说， 使用用户描述可以防止功能蔓延.

使用用户故事有几个好处:

• 提供公共语言. 用户故事成为整个开发团队的通用语言, 消除对解决方案和特性的关注. 相反，他们会围绕要实现的目标进行讨论.
• 促进合作. 它们激发了用户、设计人员和开发团队之间的协作.
• 促成共同的理解. 它们通过使用共同的语言帮助开发对用户需求的共同理解.
• 增加透明度. 它们促进了团队成员之间的开放，从而增强了信任.
• 它们是全面和有凝聚力的. 为了掌握项目，将项目需求转换为用户描述相对容易. 与特性和功能需求列表相比，浏览用户故事可以更明确地了解“项目是关于什么的”.
• 提供灵活性、可访问性和可管理性. 与其他文档相比，用户故事在概念上是直截了当的, 而且它们的创造速度很快. 用户也可以参与到他们的世代中, 涉众可以毫不费力地编辑用户故事或添加他们自己的故事.
• 改变项目的视角. 用户故事将项目的视角从潜在的随机和抽象需求列表转变为以用户为中心的活动的表示.
• 促进最高价值的交付. 它们帮助交付以客户为中心的功能，从而产生最大的好处.
• 提供检查清单. 它们能够对成功的任务完成进行度量. 如果用户不能完成任务，产品就失败了.

更好的产品设计与用户故事映射

设计师不应该仅仅依靠用户故事来推动产品设计-全面的产品设计过程涉及许多其他方法和工件. 良好集成的用户故事应该像组成整个产品UX的拼图一样相互完善. 相反，脱节的用户故事会扰乱用户体验的凝聚力.

当完全依靠用户故事来驱动设计时，其他潜在的问题:

• 缺乏上下文(忽略整体用户体验结果)
• 没有完成感(不确定是否涵盖了更大的目标)
• 混淆用户故事和用例
• 没有发展产品(用户故事不是固定的，它们往往会随着时间的推移而改变)

构建用户故事地图可以帮助我们关注大局——产品作为一个整体，而不是目光短浅地关注单个故事. 杰夫·巴顿，这本书的作者 用户故事映射

Summary

在设计中使用用户故事提供了关键的度量 设计师 需要交付精心设计的产品. 坚持用户故事框架的原则还意味着永远不要在没有相应用户故事的UI中放置设计元素.

用户故事的吸引力在于它们 识别功能需求 但不要规定 如何设计产品 为了满足这些功能需求. 在制定解决方案之前，他们首先关注问题本身.

设计师应该将用户故事视为产品设计中有价值的构建模块, 映射用户故事以创建一个内聚的用户体验, 并采用用户故事最佳实践. 这将防止功能蔓延, 使产品团队能够交付设计更好的产品, 并使设计师能够创造出无摩擦的产品, 愉悦的用户体验.

---

让我们知道你的想法! 请在下面留下你的想法、评论和反馈.