在整体设计流程中，顾客故事可以说是点亮应用绝对目标的那一点星光。该片文章的作者将给咋们讲解为什么哪怕是小范围的采用顾客故事也能给整体UI设计流程提供巨大的好处。

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

今时今日，好多UI/UX专业人士都开始意识到自个工作的环境进入了Agile状态。Agile开发（和设计）流程必须要迅速推进，相应地，咋们也必须要可以实现迅速、高效协作的工具。这样的听起来像是个矛盾，但具体上确实有好多工具可以赞助咋们在不增加项目時间的情况下有效合作。顾客故事便是针对“Agile法”的工具，在运用到UI设计流程时，其可以为后续的设计阶段提供坚定的基石。简约版的顾客故事操作起来差不多不必時间，但却能对项目按轨道运行提供奇迹般的成效。

咋们的网站开发UI设计团队会在流程中运用顾客故事，而在运用过程中咋们发现，顾客故事帮咋们做到了三件事。

1.顾客故事可以让产品以顾客为关键。

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

3.顾客故事可以防止出现基本功能蔓延以及设计死胡同。

什么是顾客故事？

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

一个顾客故事便是简单的一句话。可以用这句作为模板：“作为顾客我必须要（基本顾客目标）”。由于故事都很简短而且有针对性，故此必须要多个不同的故事来覆盖所有可能的顾客案例。事实上，咋们会想方法把每个故事开展细化。

举个例子，一个顾客故事刚开始时是：

“作为顾客我必须要创建一个新帐户。”

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

“作为顾客我必须要输入一个新顾客名。”
“作为顾客我必须要输入密码。”
“作为顾客我必须要再次输入密码开展确认。”
“作为顾客我必须要提交信息，创建帐户。”

这样子继续下去，较后就会获得一大长串顾客故事，其中大部分都必须要加入到较终产品内。

咋们较近为Quiksilver服装设计了一款iPad应用，可以让销售其货物的店铺跟踪当前存活状态，以便轻松下单订新货。便是这么一款看似特别简单明了的应用，咋们想出了266个顾客故事（刚开始时）。你们都没想到细节可以细到这种水平吧！

以顾客为中心

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

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

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

关于这样的应用，我在给“顾客资料”页面做线框图的时候，较开始以为必须要增加一个“保留顾客”基本功能按钮。不过，我不经意瞟了一眼“顾客资料”部分，突然想起来顾客故事中的一个细节：“作为顾客我必须要收藏其他顾客。”

把“保留”一词改成“收藏”这样的确定虽小但很关键，由于“保留”顾客听起来冷冰冰的，而“收藏”则契合了顾客有关约会的心态。设计师简单陷入到技术的陷阱中，特别是在对基本功能投入了大批時间之后。而顾客故事可以提醒咋们时刻以顾客体验为关键，由于顾客体验是较终确定应用性格的东西。

促进合作

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

虽然咋们在CitrusBits所采用的流程远算不上好，不过咋们却发现顾客故事可以船上的人劲都往一处使。以顾客故事为基准做出决策让咋们得以明确定义出应用的目标。这样子一来就大大降0了团队合作时的障碍，由于咋们用简短、有针对性的词句明确定义出了共同的目标。

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

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

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

当然，在项目进展期间咋们是不反对更改需求的。不过，除非有明确的顾客故事告知咋们原因，咋们会拒绝哪怕增加一个简单的文本框。咋们之故此在这方面这么强硬，是由于以前看到过有的项目超出控制、丢掉中心较后无法实现较初设定的目标。

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

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

产品从较初设计到较终成品改变特别小

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

后续:

下边是几条大伙做UI设计时思考顾客故事的提示：

在开始视觉设计以前确定出完整的一套顾客故事。抑制住自个直接跳入设计的冲动可以节省時间，防止不用要的头痛和无用功。相对每个顾客故事，看一看能否能继续细化成更具体的故事。

长篇大论适合于从宏观角度概括所需要基本功能，不过细枝末节的地方也不能忽略。在早期深入细节，从一开始就解决实用性问题。不要把设计元素放到没有对应顾客故事的界面上。

对每个元素的信息和产生原因开展记录可以让条理更清晰，在向开发团队移交时会更加顺利。

【网站制作速成三部曲】

Step 1：打好设计基础是关键呦！
《从现实到网站！暖到心窝里的情感化设计》

Step 2：进阶诀窍！向高手模仿是捷径！
《视觉盛宴！利用色彩冲突的网站制作》

Step 3：直接开挂！不高级但一定正确！
《解读：高级banner成就高大上的网站》