1.2 典型的设计过程

典型的设计过程和需要付出的努力程度，见图1。

当然，实际的努力程度将取决于每个具体项目的复杂程度和整个团队间沟通协作的效率。不过，图1给我们列出了在每个不同的阶段所需的交付物都有哪些。

我们来进入细节，仔细检查每一步的设计过程。我会解释每个阶段的目标，提供一些有用的提示和常用的技术，并且描述应该在什么时候进入下一个阶段。

1.2.1 研究

设计的第一阶段不是设计，而是询问一系列问题（研究），见图2。这听上去可能会令人惊讶，不过静下来思考两分钟，你会认识到设计之初本该如此。

如果要尽可能快地开始设计，总会面临压力，而压力主要来自效果。成熟的设计师、开发人员和项目管理人员都清楚研究时间是整个过程中必要的部分。事实上，这是开工的序幕。但是，当遇到以下这些情况时，即使是经验丰富的专业人员也经常忘记第一步的重要性。他们会陷入将要设计出伟大产品的激情中（市场潜力巨大，想要尽快进入市场以寻求优势），以至于忽略某些看上去很简单但实际上却至关重要的研究。在开始动工前，获得几个关键问题的答案是至关重要的。

如果是创建全新的网站或APP，问题如下。

■ 谁会使用这个网站或APP？

■ 用户想要完成什么任务？

■ 网站或者APP的制作者（老板、投资人、客户）想用它来做什么？

■ 网站或APP中要用到什么技术（指纹、声音识别、NFC近场通信等，是否有技术限制需要考虑）？

■ 用户为什么选择使用你的网站或APP而不是别人的？

■ 是什么内容支持用户完成目标任务或需求？

如果是重新设计现有网站或APP，找到下面问题的答案是很有价值的。

■ 哪些现有功能或复杂性正在阻碍用户，或者说对用户体验产生了负面影响？

■ 用户或者发行者（你）发现增强哪些附加功能（或增加新功能）对下一个版本有帮助？

要找到上述问题的答案，需要掌握一些研究方法。我们的研究工作可以采取竞争性分析的形式，通过采访预期的终端用户来确保产品具有正确的功能。下面是一些最常用的研究技术和方法。

■ 卡片分类

■ 焦点小组

■ 用户调研

■ 投资人访谈

■ 设计原则

■ 创建人物角色和用户资料

■ 情景调查

■ 启发式教育

■ 竞争分析

研究的重要性

研究的数量和质量也会直接影响到用户的需求，还会影响到完成设计所需要的时间。

为了描述这个问题，请参考图3和图4。

图3显示了这个过程应该是怎样工作的。在设计工作开始之前，即便没有完成所有的研究工作，也要完成绝大多数必要的研究，这意味着一个相当明确的设计周期，设计师要明确并清晰地认识到所有需要解决的问题。第一回合的设计通常都需要一些改进，这样安排便于随时对照项目时间表，随时进行调整，让整个团队成员都感觉到项目的每个环节处于可控范围内。

图4描述的是错误的设计过程，在设计前未进行充分研究，导致项目延期。这是我的个人经验总结，客户（投资人、老板）通常都不能一次性把功能和需求考虑周全，所以在第一个设计周期时可以进行适当的缓冲。向他们询问一些必要的问题，而且在这个环节他们通常也会给出更多细节。如果看不到第一回合（阶段）的设计，他们很难回答我们提出的问题。一旦他们看到第一阶段设计草图或者线框图，他们就会变成信息的源泉。在设计之初，有依据的步步推进是符合设计逻辑的，完全胜过空洞的想象和抽象的描述。

当通过研究得到有价值的结果很少时，就应该创建一些草图。所以，制作这些草图要快、要简单，要确保让客户（老板、投资人）参与这个过程。如果在没有获取充分信息之前就开始第一轮设计，那我们很快就会意识到，这是在浪费时间。

在设计网站或APP时，有太多需要考虑的内容。在设计过程中，如果客户较晚地引入某个（些）功能或需求，那么目前所有的设计可能都要作废，再重新制作。通过研究的彻底执行和对研究结果的书面化记载，我们能减少自己的一些痛苦，并在这个过程中甄别出客户与用户对产品的真实需求。然后，我们将结果呈献给客户和团队，征得他们的同意并敲定最终设计方案。确保从一开始就让每个人都参与进来，可以有效减少后期意外变动的数量。而且，当客户在后期提出修改时，他们会明白这些请求会影响到当初所敲定的预期。这样，如果要对时间表进行调整，就可以很自然且融洽地进行商讨。

■ 在敏捷环境中设计

一些设计师可能会发现，在设计较大的综合性解决方案时很难与使用敏捷开发方法的开发团队合作。敏捷是一个迭代的开发方法，试图通过减少文档数量和其他开销来加快开发团队的工作效率，这是一种与瀑布式开发相对的方法。瀑布式开发方法是指在产品投入市场前已经将大部分或全部产品设计完毕，这种方法需要大量的讨论和文档，严重减缓产品的开发过程。虽然瀑布式方法仍在使用，但它已经是昨日黄花了，因为它的效率低下、不够灵活。

较小的项目，在研究的初始阶段不会发现太多问题。然而，大型或者复杂的项目可能是一个挑战。在敏捷环境中设计，通常要求我们开个好头。在开发团队需要之前，我们就要将研究结果和设计结果交付给他们。研究越提前，我们就有更多的时间来审查和优化工作内容。

总而言之，研究的数量和质量将直接影响和关系到我们创建的解决方案的质量。仓促的设计解决方案，不研究关键细节（如市场竞争分析、目标用户和用户需求等），都意味着我们只是在猜测成功的可能性。当然，这种情况一定要往坏处想，也就是仅凭猜测设计出的产品不可能取得成功。

不管使用什么方法，在开发和设计方案中保证研究的时间是至关重要的。

1.2.2 信息架构

在讨论完研究阶段的大量问题后，我们过渡到设计过程中的信息架构部分，见图5。

虽然将步骤分解成不同的阶段，当要改变焦点时，自然要对研究持续一段时间。目前还没有必要在每一步之间划清界线。根据项目的范围和复杂性，项目设计过程中的任何一个时间点都有不同的阶段。但下面列表中的第一点是例外。我们的初始研究应该旨在获得足够的信息来制定一个全面的（用户想要在网站或APP中想要完成的）任务图。

这个阶段的目标如下。

■ 创建网站或APP的高级地图。

■ 在每个页面上标出发现的任务。

■ 定义支持每个任务所需的内容。

■ 审查并测试设计。

■ 完善设计方案。

■ 将用户体验模式规范化、文档化。

■ 介绍开发流程

这一阶段的努力致力于制定网站和APP的结构。项目越复杂，在进入下一步之前，研究定制页面结构和任务流就越重要。如果要创建一个简单的网站或APP，那么对彻底调查和工作流程文档的要求就会降低很多。无论如何，这是一个好习惯，它能帮助我们将计划传达给客户和团队成员。如果我们要创建一个复杂的网站、网站APP，或其他APP，这绝对是至关重要的，我们要首先制定任务流和用户尝试完成任务时的交互。

我们应该考虑建立一个完整的任务流程图和产品的站点地图，这是主要问题之一。在某些必要情况下，可以根据目前已经完成的研究，单独制作这张地图。某些情况下，我们要排除噪音意见，这样有助于我们拿出建议性的解决方案。不过，我建议应该与客户/投资人和团队重要成员一起展开一场头脑风暴。因为重要成员们在同一个房间里共同讨论解决方案时，可以加快制定速度。

要列出常用的用户体验方法的原创者是谁是比较困难的。不过通过网络搜索可以得知，流程图最初是由Frank GilbrethSr．发明的，并于1921年递交给美国机械工程师协会。Frank是一个特别迷人的历史人物，他像虚拟世界中的用户体验设计师那样改善现实物理世界。他的图表方法已经被很多不同的行业应用和修订。第一个用于用户体验设计的标准流程图方法是由Jesse James Garrett于2000年发明的。

■ 定义流程图中的形状

如果在互联网上搜索流程图形状的意义，我们会得到成千上万个结果，但是对形状和线条的定义会有所不同。采纳更深层次的视觉语言可以极大扩展我们的信息量并将其融入我们的交互图中。话虽如此，我们不必完整地采用这些图标语言。熟悉行业中的标准流程图是再好不过的（如标准建模语言UML这是另外一门更加专业的领域，不属于本书讲解范围），不过我们自定义对其进行修改也是可以接受的，只要能清晰容易地传达你想传递的信息即可。理解任务流创建的基本原则，可以帮助我们顺利熟悉并掌握这些图标。

下面是一些常见的流程图形状和它们的含义，见图6。

下面是一个简单流程图演示，见图7。

这个流程图表达的是，当用户安装一个APP时的预期体验，这里的主要任务是确定用户已有账户或创建一个新账户。

从这张图中我们可以看出，每个矩形代表一个页面或任务。最开始的部分是下载并安装APP。文档的读者只需跟着箭头指示就可以查看用户的可用选项以及他们做出决定和输入数据之后的后续步骤。

这里我们可以看到，当用户被要求输入一个已有账户时的体验分支。如果他们已有账户，直接输入并登录后进入用户控制面板。如果没有账户，他们会被要求创建一个新的账户，然后他们被送到该APP的教学页面（引导页），这里可以看到多个页面的教程，用户可以选择跳过教学直接进入用户控制面板。这里的虚线代表一种暗示作用，观看APP使用教学是用户的首选路径（希望用户这样做），但这一步是可选的（大多数情况下，用户体验一款全新APP的耐心是有限的，他们希望尽快使用APP来完成任务或满足他的某种需求，如果你的APP不能让用户得以满足的话，也许一分钟之内用户就会将你的应用卸载掉）。

这虽然只是众多经验中的一个小片段，但我们扫上一眼就能体会到它传达了多少信息。做出分支决定是非常重要的，我们提供的选择越多，地图就越复杂。如果每个问题都引出更多问题，体验的复杂性就会以指数增加。像这样添加几个分支问题的话，用户体验便难以使用文本文档解释清楚。即便能解释清楚，也要花费过多的时间和脑力劳动来阅读和理解。

曾经有一位同事（项目经理）给我一份功能规范文档（来自客户），里面的每个功能都使用文字描述，而且很详细。虽然不是一个特别长的文档，但我们花了半天时间来读懂它并试图理解它描述的过程，可惜到最后也没有完全理解他试图表达的过程。我们最终决定放弃继续研究文档，直接约见客户面谈。经过几番讨论后，我们理解了他的目的并在谈论过程中得到了一个明确的任务流。之后我们在一页纸上绘制出了他想要的任务流，砍掉了80%的文本，并使用一个超轻量级且容易理解的文档敲定了客户的最终需求。

■ 过渡到线框图

当项目的客户（投资人、老板）看过我们的任务流程图并同意这正是他们想要执行的任务，我们就该进入线框图阶段了。

线框图是产品的基本蓝图，用来描述网站或APP在每个页面（屏幕）上的核心功能。这些线框图会随着我们的改进越来越详细。不过，在第一个版本中我们只用到黑白的轮廓和形状来暗示导航、文本、按钮和图像等元素的位置。这些线框图应该勾勒出我们对整个产品的看法，表达出最初的产品设计理念。

下面附上一个网站主页的初稿线框图，见图8。

如你所见，这是一张非常简单的线框图，可以看出，该页面的内容所支持的任务是：帮助用户找到他们想要的产品并了解更多信息。

为了支持这项任务，我们创建了帮助用户访问不同商品的“入口”，如图中的导航和主推商品的轮播幻灯。但目前我们还不知道文本应该描述些什么，导航栏应该包含什么，还有图像应该是什么样子。所有这些还需要更多的讨论和探索，所以我们目前只使用一些占位符，继续向后推进。

如果是对已有网站或APP进行重新设计，这一步会变得更容易。不过，如果这是产品的第一个版本，我们不应该在一开始就考虑太多细节，这样会扰乱我们的设计步伐。只需想象一下页面中需要支持任务正常执行的内容是什么样子，然后将其落实到线框图中就可以了。

当我们对线框图逐渐增加细节进行迭代时，线框图的保真度会随之增加。随着线框图的不断完善，我们将越来越清晰地看到应该在哪里增加功能或添加新的内容。我们还需要定义最优化导航模型并对内容进行分类。

现在应该与开发团队碰面详细介绍当前项目计划的详情，包括一些特殊的技术问题或比较少见的功能需求。此时，我们应该弄明白网站的优化方案中是否包含跨平台（台式机、平板电脑、手机或其他移动设备），也就是响应式设计。现如今，这已经成为创建网站的标准方法了。也就是说，我们要考虑在不同尺寸的显示器屏幕上，页面的内容和布局应该怎样转变。不过，随着移动设备的兴起，越来越多的设计师都在追求“移动优先”的设计方法，也就是先创建一个针对移动设备进行优化的设计，然后再设计桌面优化版本。无论你追求哪种设计方法，在设计线框图阶段你都要考虑到响应式设计。不过，客户需求第一，在与客户进行详细沟通得到确认后再执行。

最近几年，有很多关于响应式设计与自适应设计孰优孰劣的话题。笔者建议广大读者不要盲目陷入无休止的争论中。牢记，目标是满足用户需求，而不是讨论哪项技术更胜一筹。在设计初期，使用自适应设计可以更高效地制作出目标效果与客户进行沟通，这可以节省大量时间和精力。

■ 可用性测试

虽然这一步经常在制作出模型之后进行，但现在是时候测试一下设计的可用性了。不管我们是使用纸原型、可交互截图还是其他方法，尽早审查我们的想法是非常重要的，这样可以帮助我们节省更多时间来修改。如果等到完整的模型制作出来或者完全开发完毕再进行测试的话，我们很难再去修改核心功能。如果一定要修改的话，很可能意味着我们要全部重新设计，这是极大的资源浪费，是项目中所有人都不希望遇到的糟糕情况。

1.2.3 视觉设计

当团队成员和客户（投资人、老板）对我们设计的任务流、导航和页面布局达成共识后，就该进入设计流程的视觉设计部分了，见图9。

到这里，通常是创建模型（使用Photoshop、Adobe Illustrator、Sketch或其他软件），并使用Axure制作可交互模型的时候了。在此阶段，应该尝试制作代表终极产品的像素级模型了。所有的内容和图像应该定义好并放在合适的位置上。应该强调的是，这里所说的像素级概念是在采用响应式设计（或自适应设计）的前提下，增加网站的交互性。

■ 视觉层的应用

如前所述，用户体验设计师是一个多学科的职业，一些公司发现通过招聘内容架构师可以更容易地将设计过程划分清晰。然后将内容架构师制作的文件传递给视觉设计师，让视觉设计师设计出视觉层。

当同一个设计师制作线框图和视觉设计时，他可以更容易地提高线框图的保真程度，让同一个设计师进行视觉设计也将会对产品设计进行自然延伸和优化。然而，如果这里的工作是分开的（由不同的设计师来做），建议给视觉设计师多留一点空间来探索视觉解决方案。一个较好的方法就是，不要标注线框图中的部件位置、尺寸、颜色等属性，以便让视觉设计师有足够的发挥空间。

在这个阶段更改内容是很常见的，在优化模型时会更新文本和图像。但是，在视觉设计阶段要改变功能或增加其他特性的话，会浪费大量的时间和精力。因为在创建模型时很难再退回到线框图阶段，这意味着线框图和模型都要重新设计，也就是你和视觉设计师两个角色都要重新再来一次。如果是创业团队中优化产品方案，这是很好的流程，不要嫌麻烦。但如果是个人顾问的话，这会浪费掉你太多时间和精力，你不得不重新规划项目时间表。

如果一定要对信息架构做出较大变化，应该立即停止模型设计，重新设计一组线框图并与团队成员（尤其是投资人、老板）共同探讨，并且要在争得团队全体人员的同意后，再重新制作模型。

1.2.4 交付

当我们将模型和内容都准备好后，就可以进入设计过程的交付阶段了，见图10。

这个阶段基本分为三个任务。

■ 优化网站或APP中使用的图像。

■ 创建规范文档，帮助开发人员构建设计。

■ 评估开发完整的工作，以确认它匹配设计。

最后一步是最困难的。开发成果和设计方案之间可能会有一些明显的视觉差异。即使我们在规范文档中注明了边距、字距、行距和其他属性，事情还是会略有不同。这是因为在Photoshop（或其他设计工具）中，对设计的控制级别要大于在浏览器中。虽然HTML5和CSS3提供了更多的控制，但有些细节仍然达不到你在Photoshop等设计工具中的预期效果。

这是一个相当普遍的问题，我们可能将所有注意力都集中到最终结果上。我们应该让团队中的全体成员认识到，这是大家共同的责任，以确保最终开发出的产品与我们设计的模型尽可能保持一致。毕竟，开发人员都是按照我们提供的文档和模型工作的。有许多人对于产品细节和细微差别持有强硬的观点（在互联网浪潮中对产品细节吹毛求疵是正常现象），不过一旦产品进入开发阶段这些现象会逐渐变淡。先推出最小化可行产品投入市场，接受广大用户的反馈，然后再对产品进行调整以及细节优化。

解决这一问题的诀窍是，在设计过程的一开始就将开发人员包括在内。因为设计师与开发人员之间似乎天然存在一道屏障（尤其是当设计师完全不懂开发的情况下），毕竟开发人员“说”的是一种完全不同的语言，并且在设计过程的不同阶段才融入战斗。尽早将开发人员包含在内，是大有好处的。

此外，我们应该确保让开发人员（或开发团队代表）尽早参加项目讨论，这样便于他们决定应该使用何种技术开发项目。在讨论设计用户体验过程中想要的功能和特色时，也应该与开发人员共同商讨，便于他们获取足够的信息来确定使用何种技术。他们会提出适当的建议，比如会遇到何种限制（如消耗开发团队大量精力仅是为了华而不实的特效，而且某些特效会造成移动设备硬件性能严重消耗导致卡机情况发生），或者有哪些替代选择，便于我们及时处理（笔者建议，无论是视觉设计师、用户体验设计师、项目经理、产品经理，都应该至少熟悉一种主流编程语言，熟悉并不等于可以开发产品，但这可以帮助你更深层次地理解产品，也可以更融洽地与天才程序员们沟通协作，目标是要让项目的设计过程保持在可控范围内）。

除此之外，在后续的设计回顾中也应该包括开发人员，这将帮助他们理解为什么要做出某些重要决策，以及这些决策的重要性。在头脑风暴和设计回顾环节要包含一个开发团队负责人，这样可以帮助我们让整个团队对项目在不同阶段的认知保持同步，避免扰乱开发团队的安排。

所有这些都可以帮助防止设计和开发出现大幅改动或沟通不畅而导致的严重问题出现，让整个团队从一开始就清楚项目中任何阶段的任何变化。