前言：嗨，小伙伴儿们，这里是愿得同理心场景不分离的「交互坊」。在需求分析阶段，交互设计师是作为产品经理的补充，一方面了解需求，一方面帮助产品更好的细化和完善用户需求，其工作的重点还是在需求分析之后的部分。所谓高级交互设计师等于半个产品经理，就是这个道理。

一支设计团队坐下来讨论为一家新客户所设计的应用的第一轮模型情况。随着团队成员不断提出想法，我们发现大家对于这个应用是什么？其功能应该是什么样有着截然不同的看法。后来，会议迅速变成了“谁对谁错”而不是“什么对什么错”的争论。大家纷纷为自己的设计辩护，但没有一个人站在用户角度说话。听着耳熟吗？正是在这种时刻，我们迫切需要描绘用户故事。

今时今日，很多UI/UX专业人士都开始意识到自己工作的环境进入了Agile状态。Agile开发（和设计）流程需要快速推进，相应地，我们也需要能够实现快速、高效协作的工具。这个听起来像是个矛盾，但实际上确实有很多工具能够帮助我们在不增加项目时间的情况下有效合作。用户故事就是针对“Agile法”的工具，在运用到UI设计流程时，其能够为后续的设计阶段提供坚定的基石。简约版的用户故事操作起来几乎不用时间，但却能对保证项目按轨道运行带来奇迹般的效果。

我们的UI设计团队会在流程中运用用户故事，而在运用过程中我们发现，用户故事帮我们做到了三件事。

1.用户故事可以让产品以用户为核心。

2.用户故事可以促进团队成员之间的合作。

3.用户故事可以防止出现功能蔓延以及设计死胡同。

什么是用户故事？

从根本上说，用户故事的用途是描述用户通过使用软件产品想要实现的任务。用户故事起源于Agile和Scrum开发策略，但是对于设计师来说，用户故事主要用来提醒用户目标以及对各个界面设计进行整理和排序。

一个用户故事就是简单的一句话。可以用这句作为模板：“作为用户我需要（基本用户目标）”。因为故事都很简短而且有针对性，所以需要多个不同的故事来覆盖所有可能的用户案例。事实上，我们会想办法把每个故事进行细化。

举个例子，一个用户故事刚开始时是：

“作为用户我需要创建一个新帐户。”

但是新建帐户的过程中又涉及到哪些步骤呢？用户需要提供用户名、密码以及其他相关信息。其中每个操作都需要有相对应的用户故事，故事越具体，到后期对设计师和开发来说就会越方便。那么，“创建新帐户”就可以进一步细化为：

“作为用户我需要输入一个新用户名。”

“作为用户我需要输入密码。”

“作为用户我需要再次输入密码进行确认。”

“作为用户我需要提交信息，创建帐户。”

这样继续下去，最后就会得到一大长串用户故事，其中大部分都需要加入到最终产品内。

我们最近为Quiksilver服装设计了一款iPad应用，可以让销售其货物的店铺跟踪当前存活状态，以便轻松下单订新货。就是这么一款看似非常简单明了的应用，我们想出了266个用户故事（刚开始时）。你们都没想到细节能够细到这种程度吧！

以用户为中心

作为设计师，我在第一次和项目相关人员开会的时候就会开始考虑布局和配色方案。在听他们说目标以及了解终端用户情况的同时，我就能想象出这款应用应该是什么样的。但关键在于不能本末倒置——我们要先确定用户故事，让用户故事道出设计，而不能倒过来搞。

在对应用的所有用户故事做完脑暴之后，我们会把故事放到Google的合作电子表格上，以便客户在想到有其他用户故事时随时添加。在客户和团队感觉已经穷尽所有内容之后，我们会给每个故事一个编号。这些编号到项目后期会派上大用场，我们会用编号作为一个简明的标签来表示哪些故事需要在哪个时间段处理。

这个表格的功能不仅是提醒我们应用的功能，还能让我们在整个流程中与用户紧密相联。每个用户故事都是针对于我们终端用户的，以便保证始终照顾到他们的需求。这一点在一个有关约会应用的项目中表现的尤其明显。

关于这个应用，我在给“用户资料”页面做线框图的时候，最开始以为需要添加一个“保存用户”功能按钮。但是，我不经意瞟了一眼“用户资料”部分，突然想起来用户故事中的一个细节：“作为用户我需要收藏其他用户。”

把“保存”一词改成“收藏”这个决定虽小但很关键，因为“保存”用户听起来冷冰冰的，而“收藏”则契合了用户有关约会的心态。设计师容易陷入到技术的陷阱中，特别是在对功能投入了大量时间之后。而用户故事可以提醒我们时刻以用户体验为核心，因为用户体验是最终决定应用性格的东西。

促进合作

UI的设计通常涉及到的人不止一个。其中还可能包括客户、设计师、程序员以及一大堆的其他职位工作人员，具体要取决于公司的规模大小。从很多方面说，这就类似于一队人划船。要赢得比赛，团队的每个成员都要以相同的速度朝着相同的方向一齐划桨。这并不是说所有人的意见都要始终统一，而是说所有人都要有统一的目标并且清楚自己在团队中的角色。

虽然我们在CitrusBits所采用的流程远算不上完美，但是我们却发现用户故事能够保证船上的人劲都往一处使。以用户故事为基准做出决策让我们得以明确定义出应用的目标。这样一来就大大降低了团队合作时的障碍，因为我们用简短、有针对性的词句明确定义出了共同的目标。

另外，用户故事还能让身处不同地理位置的团队更加轻松的合作。我们在为一家旧金山客户开发一款问答类应用时，我们在海湾地区的团队会时不常的和客户碰面讨论应用要求。他们写出了用户故事（但并没有在项目期间进行其他修改）然后放到了Google Drive。而我们身处洛杉矶的团队则可以在画线框图的同时随时参考用户故事，并进行必要的改动。要不是有了这个步骤，这个项目所花费的时间会长的很多，而且还会需要通过大量漫长的解释工作来解决这些简短用户故事几分钟就能解决的问题。

防止出现功能蔓延以及设计死胡同

“功能蔓延”是一个UI设计中常见的词。它是指相关人员会不自觉地不断增加新功能，扩展项目范围，这既包括硬件也包括软件方面。

这幅漫画完美地诠释了功能蔓延。

当然，在项目进展期间我们是不反对更改要求的。但是，除非有明确的用户故事告诉我们原因，我们会拒绝哪怕添加一个简单的文本框。我们之所以在这方面这么强硬，是因为之前看到过有的项目超出控制、丢掉中心最后无法实现最初设定的目标。

举个例子，不久之前，我们有个客户忽略了用户故事这回事。当时我们正在给一家处理保密资产的公司搭建应用，客户想要做一款能够管理员工之间通讯的应用。主要的通讯手段是一个使用文字信息和图片的公司内部对话平台（这一点我们都认可了），这个我们记录到了用户故事里。后来，客户又要求增加视频、语音信息和位置分享。为了保持我们“灵活”的形象，我们想办法把这些内容加入了新的通讯系统，也因此扩大了项目范围，推迟了时限，在做完了全部工作之后我们却发现添加的内容其实对终端用户没用。

尽管新增的功能也很屌，但我们最开始的初衷是做一款尽量简化通讯的应用以便促进团队建设和协作，不让他变成一个公司内部的Facebook。于是，我们又回到了用户故事并重新提醒了客户做应用的初衷，最后成功组织了功能蔓延，回到了正轨。多方面的实验尽管能带来很多很棒的成果，但是如果产品无法满足根本要求，再精巧也没意义。

通过这次教训，我们在开发Quicksilver这个针对B2B公司的销售类应用时严格遵照用户故事开展流程。最后，最终产品一丝不苟地遵守了最初设计，这主要归功于我们在前期积累了一套全面的用户故事。以用户故事为基石为后期节省了大量工作，同时也让我们的工作更加有序、更加以用户为中心。尽管产品的每次迭代都带来了更多的用户和客户反馈，但产品理念的核心一直屹立不倒。

产品从最初设计到最终成品变化非常小

每个用户故事对于设计团队和开发团队来说都有自己的一套意义。时刻思考技术限制虽然说是好的，但是毕竟我们说的是“用户故事”，不是“开发的故事”也不是“设计师的故事”。正因为我们通过用户故事对用户的观点进行了排序整理，我们才能更轻松地了解所面临的问题进而创造出一款真正有用的最终产品。

后续

下面是几条大家做UI设计时思考用户故事的提示：

在开始视觉设计之前确定出完整的一套用户故事。抑制住自己直接跳入设计的冲动可以节省时间，避免不必要的头痛和无用功。

对于每个用户故事，看看是否能继续细化成更具体的故事。长篇大论适合于从宏观角度概括所需功能，但是细枝末节的地方也不能忽略。在早期深入细节，从一开始就解决实用性问题。

不要把设计元素放到没有对应用户故事的界面上。对每个元素的内容和产生原因进行记录可以让条理更清晰，在向开发团队移交时会更加顺利。

来源：网秦UEC