用好用户故事，帮助团队协同运行，保障产品好发展

通常在设计团队坐下来分享或讨论产品的设计过程后者复盘时，团队成员都有不同的想法......很快，会议会变成更多关于谁对谁错的讨论，每个人都在捍卫自己的设计想法，没有人在捍卫产品和用户，这是人性，那怎么办？

在这种时候，我们需要用到用户故事。

如今，许多UI / UX专业人员发现自己都处在敏捷开发/设计的世界中，因此，我们需要能够进行快速，有效协作的工具辅助，听起来似乎是矛盾的，但是有些工具可以帮助我们一起协同工作，用户故事几乎不需要花费时间来实现，但是可以使项目保持正常运转，他基本可以实现以下三大功能：
用户故事可让用户关注产品
用户故事可促进团队成员之间的协同工作
用户故事有助于防止功能需求变更和设计死角

怎么理解用户故事？
用户故事的核心是描述用户希望通过使用软件产品来完成的事情。它们起源于敏捷开发/设计策略的一部分，但是对于设计师来说，它们主要是提醒用户目标以及组织和确定每个屏幕的设计优先级的方法。

用户故事是一个很短的故事，实际上大约只有一句话。
这是模板：“作为用户，我要……[基本用户目标]。” 由于这些故事太短且太具体，因此需要花很多时间才能涵盖每个可能的用例。实际上，我们尝试了解每个故事，看看可以分解多远。

例如，一个用户故事可能始于： “作为用户，我想创建一个新帐户。”
但是，创建新帐户真正涉及什么呢？用户需要提供用户名，密码和其他相关信息。每个单独的动作都需要一个相应的用户故事，并且每个故事越具体，对于设计师和开发人员而言，以后的工作就越容易。因此，“创建新帐户”实际上可以进一步细分：
“作为用户，我想输入一个新的用户名。”
 “作为用户，我想输入密码。”
 “作为用户，我想重新输入密码进行验证。”
 “作为用户，我想提交此信息并创建一个帐户。”
如果做得正确，最终结果将是一长串的用户故事，我们将把其中的大部分纳入最终产品中。 

保持用户关注
作为设计师，在与项目利益相关者的第一次会议上，我的想法就开始将布局和配色方案拼凑在一起。当我听取他们的目标并了解他们的最终用户时，我可以设想该应用程序的外观。但是至关重要的是，不要把购物车摆在前面。当我们首先确定用户故事时，我们让他们决定设计，而不是相反。

在为一个应用程序集思广益之后，我们将其放入协作的电子表格中，客户可以在其中添加他们认为缺少的所有故事。一旦客户和团队都认为我们已经涵盖了所有基础，便会为每个故事分配一个编号。当我们将它们用作简洁的标签来标识哪些线框所涵盖的故事时，这些数字在项目后期特别有用。

该列表的作用不仅仅使我们想起功能。它使我们在整个过程中始终与用户保持联系。每个用户故事都经过专门设计以适应我们的最终用户，从而确保我们能够满足他们的需求。在涉及约会应用程序的项目中，这一点尤其明显。

当我为“用户个人资料”页面创建线框时，我最初认为通过添加一个在应用程序中进行标记的按钮来添加“保存用户”功能是适当的。但是，对“用户个人资料”部分的浏览使我想起了用户故事中的一个细节：“作为用户，我想收藏另一个用户。

”从“保存”到“收藏夹”的更改是一个很小但有价值的决定，因为“保存”用户是冷淡的，没有个性的，而“收藏”则与用户的约会心态保持一致。设计师往往会陷入技术方法的陷阱，尤其是在功能性工作了数小时之后，而用户故事则有助于提醒我们始终专注于用户体验，从而赋予应用程序其特色。

促进合作
一个UI设计通常有多个与结果相关的利益相关者。该组可以包括客户，设计师，程序员和许多其他职务，具体取决于组织的规模。从许多方面来说，这与参加赛艇队的情况类似。

为了赢得比赛，每个团队成员都必须以相同的速度和相同的方向齐心协力。这并不意味着每个人对所有事情都会有相同的看法-只是意味着每个人都专注于同一目标，并且知道他们如何适应团队。

但我们发现用户故事可以使每个人保持一致。能够使决策与用户故事保持一致，从而使应用程序的目标清晰明了且定义明确。这降低了团队合作的障碍，因为我们已经用简短，具体的词组确定了我们的集体目标。

用户故事还使位于不同位置的团队更容易进行协作。当团队有时会与客户会面，讨论该应用程序的要求。创建了用户故事-尽管在整个项目中对其进行了修改-并将它们放置在我们的云端硬盘中。然后，我们将在创建线框并根据需要进行更改时参考用户案例。

如果不是这个过程，那么该项目将花费更长的时间才能完成，并且将需要长时间的解释才能在短短几分钟内完成我们众多微型用户故事的工作。

防止功能需求变化和设计死角
“功能需求变化”是一个在UI设计期间经常出现的术语。它表示希望继续增加更多功能并扩大项目范围的趋势，无论是硬件还是软件。
当然，随着项目的进展，我们乐于接受不断变化的需求。但是，如今，我们拒绝在没有用户故事的情况下添加太多文本框，而这并不能解释我们为什么此特定文本框很重要。在看到以前的项目失控，失去关注并未能实现其最初目标之后，我们决定对此采取强硬措施。不久前，我们的客户忽略了用户故事。我们正在为一家处理机密资产的公司开发一个应用程序，他们想要一个管理员工之间通信的应用程序。

交流的主要手段（我们都同意）是使用文本消息和图片的公司内部聊天平台，这些平台我们记录在用户故事中。后来，客户要求添加视频，语音消息和位置共享。为了变得“灵活”，我们尝试将其实施到新的通信中，从而扩大了范围并推迟了计划，在所有这些努力之后，我们最终意识到添加这些内容对最终用户没有帮助。

尽管它们是整洁的功能，但最初的原则是创建一个将通讯简化到最低限度的应用程序，以促进团队建设和合作，而无需使用内部Facebook。我们将他们带回了用户故事，使他们想起了该应用程序的初衷，最后，我们能够阻止功能蠕变并重回正轨。实验可以产生一些奇妙的结果，但是如果产品不符合基本要求，那么独创性将毫无意义。

从错误中吸取教训后，我们始终严格遵守用户故事。结果，最终产品非常符合我们最初的设计，主要是因为我们已经完成了构建全面用户故事集的前期工作。在此基础上进行构建可以节省以后的工作量，并使我们的工作井井有条，以用户为中心。尽管项目的每次迭代都带来了更多的用户和客户反馈，但该概念的核心仍然很牢固。

每个用户故事对设计团队和开发团队都有一系列影响。尽管牢记技术限制总是好的，但是这些被称为“用户故事”，而不是“开发人员故事”，甚至是“设计人员故事”。由于我们尝试使用用户故事来优先考虑用户的观点，因此更容易理解当前的问题并创建有用的最终产品。

下一步在UI设计上尝试用户故事时，需要记住以下几点：

1. 在进行任何视觉设计之前，请先确定一整套用户故事，不要直接进入设计环节，容易浪费大量精力，导致返工，对于每个用户故事，请查看是否可以将其分解为更小和更具体的小故事。

2. 很好地概述所需的功能，但不要太宽泛，应尽早深入细节，并从一开始就解决产品的可用性问题。

3. 切勿在没有相应用户故事的界面中放置设计元素，记录每个元素的内容和原因可促进发展，并后期向开发团队的移交时更加顺畅。