设计团队坐下来讨论他们为新客户设计的应用程序的第一轮模型。随着团队成员不断贡献想法，我们发现人们对这个应用程序的看法是什么？对于它的功能应该是什么样子，存在着截然不同的看法。后来，会议很快变成了谁对谁错的辩论，而不是什么是对什么是错。每个人都为自己的设计辩护，但没有人站在用户的角度说话。听起来很熟悉吗？正是在这样的时刻，我们迫切需要描述用户故事。今天，许多UI/UX专业人员开始意识到他们的工作环境已经进入敏捷状态。敏捷开发（和设计）流程需要快速移动，因此，我们需要能够实现快速高效协作的工具。这听起来可能有点矛盾，但实际上有很多工具可以帮助我们在不增加项目时间的情况下有效协作。用户故事是“敏捷方法”的工具。当应用于UI设计过程时，它们可以为后续的设计阶段提供坚实的基础。极简的用户故事几乎不需要时间来实施，但可以为使项目保持在正轨上创造奇迹。我们的UI设计团队在过程中会用到用户故事，在使用的过程中，我们发现用户故事帮助我们做了三件事。1.用户故事让产品以用户为中心。2.用户故事可以促进团队成员之间的合作。3.用户故事防止功能蔓延和设计死胡同。什么是用户故事？从根本上说，用户故事的目的是描述用户希望通过使用软件产品实现的目标。用户故事起源于Agile和Scrum开发策略，但对于设计师来说，用户故事主要是用来提醒用户目标，以及对各种界面设计进行整理整理。用户故事只是一个句子。您可以使用这句话作为模板：“作为用户我需要（基本用户目标）”。因为故事短小精悍，所以需要多个不同的故事来涵盖所有可能的用户案例。事实上，我们会找到一种方法来完善每个故事。例如，用户故事的开头是：“作为用户，我需要创建一个新帐户。”但是创建新帐户涉及哪些步骤？用户需要提供用户名、密码等相关信息。这些操作中的每一个都需要有一个相应的用户故事。故事越具体，就越方便后期的设计者和开发者。然后，“创建新帐户”可以进一步细化为：“作为用户，我需要输入一个新的用户名。“”作为用户，我需要输入密码。""作为用户我需要再次输入密码进行确认。""作为用户，我需要提交信息并创建一个帐户。“继续这样下去，你最终会得到一长串用户故事，其中大部分都需要融入到最终产品中。我们最近为Quiksilver服装设计了一个iPad应用程序，它允许销售商品的商店跟踪当前的实时状态，为了方便下单新品。就是这样一个看似简单明了的app，我们整理了266个用户故事（开头）。没想到细节这么详细！拿下user作为一名设计师，我在第一次与项目利益相关者会面时就开始考虑布局和配色方案。在倾听他们的目标并了解最终用户的同时，我可以想象应用程序应该是什么样的。但关键不是本末倒置——我们需要先确定用户故事，让用户故事来讲述设计，而不是相反。在对应用程序的所有用户故事进行头脑风暴之后，我们将把故事放在谷歌的协作电子表格中，这样那个铜用户可以在想到时添加其他用户故事。在客户和团队觉得他们已经筋疲力尽之后，我们给每个故事一个编号。这些数字在后面的项目中就派上用场了，我们将数字作为一个简洁的标签来表示在哪个时间段需要处理哪些故事。这张表的作用不仅仅是提醒我们应用的功能，更是在整个过程中将我们与用户紧密联系起来。每个用户故事都针对我们的最终用户，以确保始终满足他们的需求。这在一个关于约会应用程序的项目中尤为明显。对于这个应用程序，当我在构建用户配置文件页面时，起初我认为我需要添加一个“保存用户”按钮。然而，我随便看了一眼“用户资料”部分，突然想起了用户故事中的一个细节：“作为用户，我需要保存其他用户。”将“保存”一词改为“收藏”的决定是一个小小的决定但关键的决定，因为“保存”对用户来说听起来很冷，而“收藏”则符合用户约会的心态。设计师很容易陷入技术陷阱，尤其是在功能上投入了大量时间之后。用户故事可以提醒我们始终关注用户体验，因为用户体验最终决定了应用程序的特性。促进协作UI设计通常涉及不止一个人。根据公司的规模，这还可能包括客户、设计师、程序员和许多其他角色。在许多方面，它类似于在团队中划船。为了赢得比赛，团队中的每个成员都必须以相同的速度向相同的方向划桨。这并不意味着每个人都必须始终保持一致，而是每个人都必须有一个共同的目标并清楚自己在团队中的角色。虽然我们在CitrusBits采用的流程远非完美，但我们发现用户故事让每个人都朝着同一个方向前进。基于用户故事做出决策使我们能够清楚地定义应用程序的目标。这大大减少了团队合作的障碍，因为我们清楚地定义了一个共同的目标，简而言之，切中要点。此外，用户故事可以让不同地理位置的团队更容易协作。当我们为旧金山的客户开发问答应用程序时，我们在湾区的团队会不时与客户会面，讨论应用程序需求。他们编写了用户故事（但在项目期间没有进行其他更改）并将它们放在GoogleDrive上。而我们在洛杉矶的团队可以在绘制线框图的同时随时参考用户故事并进行必要的修改。如果没有这一步，该项目将花费更长的时间，并且需要大量冗长的解释工作来解决这些简短的用户故事可以在几分钟内解决的问题。防止功能蠕变和设计死胡同“功能蠕变”是UI设计中的常用术语。它指的是在不知不觉中不断添加新功能和扩展项目范围，无论是在硬件方面还是在软件方面。这部卡通片完美地说明了功能性蠕变。当然，我们不反对在项目进行过程中提出变更要求。但是，除非有明确的用户故事告诉我们原因，否则我们拒绝添加哪怕是一个简单的文本框。我们对此如此强硬的原因是因为我们已经看到项目失控、失去焦点并且未能实现我们设定的目标。例如，不久前，我们有一个客户忽略了用户故事的事情。我们正在为一家处理机密资产的公司构建一个应用程序，而客户希望制作一个可以管理员工之间通信的应用程序。主要的交流方式是公司内部对话平台（我们都同意），使用文本消息和图片，我们将其记录在用户故事中。后来，客户要求提供视频、语音消息和位置共享。为了保持我们“灵活”的形象，我们想办法把这个内容添加到新的通信系统中，于是我们扩大了项目范围，推迟了工期，当我们完成所有工作后，我们发现添加的内容实际上对最终用户没有用。使用。虽然新功能很酷，但我们的初衷是做一个尽可能简化沟通的应用程序，以促进团队建设和协作，而不是让它成为公司内部的Facebook。于是，我们回到用户故事，提醒客户做应用的初衷，最终成功组织了功能蠕变，重回正轨。虽然多方位的实验可以带来很多很好的结果，但如果产品不能满足根本的要求，再精巧也是没有意义的。通过这节课，我们在开发B2B公司的销售应用程序Quicksilver时严格遵循用户故事开发流程。最后，最终产品一丝不苟地遵循了最初的设计，这在很大程度上要归功于我们预先收集的一套全面的用户故事。以用户故事为基石，节省了后期大量的工作，也让我们的工作更加有序，更加以用户为中心。虽然产品的每一次迭代都带来了更多的用户和客户反馈，但产品理念的核心始终屹立不倒。产品从初始设计到最终产品变化很小。每个用户故事对设计和开发团队都有自己的一套含义。总是考虑技术限制是好的，但毕竟我们在谈论“用户故事”，而不是“开发故事”或“设计师故事”。因为我们通过用户故事梳理了用户的观点，所以我们更容易理解我们面临的问题并创造出真正有用的最终产品。
