批评从来都是很容易的事情，似乎人人都能拥有自己的观点。但正如作者Harlan Ellison指出“你无法把控（他人）对你自身的意见，但你能把控（他人）对你观点的意见。” 观点的形成需要探索，而设计评审正是产品探索的重要环节。

创意者与团队或客户讨论并解释其创意时的设计评审，并非缠着设计师要求解释验证每一项设计决策，那仅仅是批评。优秀的设计评审是探索整个设计过程，找到亮点并发掘改进机会。理想状况下，设计评审让团队中每个人都有被倾听的感觉，允许客户给出有价值的反馈。

设计评审中提出建设性意见往往是个挑战，尤其在团队缺乏设计评审的经验时。在敏捷开发团队中，程序员、项目经理、产品经理及其他相关人员坐在一起反馈，你得明白如何应对他们，并且把事情迅速往你的期望方向引导。

UI 设计评审的原则

根据我的经验，针对UI的设计评审应当在整个产品设计与研发过程中开展，或者至少以定期的方式，每周甚至每日开展。这么做可以让产品设计可控，尤其在设计需要进行多次迭代的敏捷或者精益产品流程中。开展UI设计评审是一项挑战，不仅需要解释决策，还得耐心听取其它建议。

在每次设计评审前建立清晰的原则而不是“规矩”至关重要。与规矩不同，原则不是教条式和限制式的，而是帮助每个人对焦期望，并允许进行自由形式的讨论。

这些期望中的重点是让每个人对你提及的点评细节达成共识。Jason Ulaszek推荐道：

「在你点评的设计细节上开始询问背后的原因及意图。为什么我们需要这条信息？对于允许索取这条信息我们设置了哪些期望？我们会用它做什么？如果我们能回答它们，再进入讨论解释各种元素的优劣以及与之对应的不同意见会比较好。」

为了更好的遵循这个方针，无论是否包含UI设计，我建议遵守适用于任何设计评审的标准原则：

1、表示尊重

听起来很老套，但如果每个人都是在批评而不是尊重台面上的意见和他人的技能，那评审会迅速形成敌意。

2、指定角色

开始之前就澄清在设计评审中每个人的角色，最好在逐个点评时也把角色都重申，避免有人感到被遗忘。理想状况是以下三类角色是不同人（往往不大现实）。

-演示者

负责进行设计提案并解释背后思路的人，他需要回答所有的问题，或找出能够回答评审提问的人。

-主持人

最好由不是直接负责设计的人来担任，比如项目经理或产品经理。主持人确保每个人聚焦在主题上，并且每个人的意见都能被听到。

-记录者

此人侧重于记录讨论内容，尤其是确保会议相关结论（另外一条原则，后续会说明）在评审后能够清楚传递。会议记录者不应该被排除在讨论范围之外，尽管他们的职能倾向于让他人更清晰的表达观点。

3、针对当前评审描述项目目标

快速提醒每个人项目目标以及评审涉及的范围。确保整个评审集中在手头任务上，而不是东扯西扯，偏离话题。

4、回顾目标用户

强调参加评审的人都不是产品目标用户，提醒谁才是目标用户。

5、避免给出答案

参与者将会带有强烈的解决问题欲望，而且会在评审中提出解决方案。然而，最佳方案往往不会在评审时产生。评审的关键是探索问题及讨论潜在的多个方案，帮助设计师拓宽思路并最终决策。

6、对结论形成共识

记录者需要回顾每个参与评审人员提到问题的结论，以便在下次评审中大家形成共识。

不幸的是，UI设计评审经常在视觉细节上死磕，而忽视交互层面的更影响设计的内容。因此，对UI设计评审，我们增加了几条原则：

7、澄清设计媒介

在跟听众讲解设计时，记得提及产品界面展示的平台及相关技术。这是个iPhone应用？一个网站？是否使用AngularJS技术或者C#开发？确保这些都充分考虑，否则你的设计方案可能完全无效。

8、勾勒流程

你得了解路线图。对于UI设计来说，应该是用户体验的流程。或许是故事板、用户旅程图或者其它描述流程的方式，每个参会者都应该在点评界面之前充分了解整个流程。

9、演示产品，而不只是描述

我得再次强调：伟大的用户体验应该更多的展示出来，而不是口头描述出来。用户在不必解释的情况下就应该明白产品如何工作。你的演示需要尽可能少的语言解释，就好比老话说的：好的UI就像笑话一样，如果需要解释，那么肯定很糟糕。

10、提出正确的问题

设计评审中的大量提问与评述跟协作精神有较大冲突。我推荐一些在探索设计时的开放对话中可以用到的问题，比起导致激烈PK更容易促成协作，你可以推荐给你们团队试试。

“这个方案你是如何想出来的？”

在任何评审或者交流中比较适合的切入问题，询问设计师如何做出某个方案，而不是为什么做某个方案？询问为什么立马会让设计师进入防备心态，而询问如何进行的会让设计师在不需要澄清理由的情况下去表达自己设计理念的初衷。

“为什么”相关的问题让我们急于证明某件事情的真实性，而不是解释它作为一种可能性。根据Aaron Morton的观点：

「“如果你问为什么，一切都无法奏效。与询问“为什么”不同的是，考虑询问“如何”能够引出一个创造流程的故事，不必为它的存在辩护。

然后你可以问设计师之前考虑过的各种可能，认真倾听设计师在提供方案之前做过的尝试。他们也许过于看重某些东西，不过没必要深究。」

“你想要这样做的想法来自何处？”

爱迪生说过一句著名的话“天才是1%的灵感+99%的汗水”，但他那最重要的1%来自Nikola Tesla。毕加索也说过“优秀的艺术家借鉴，伟大的艺术家偷窃”。

皮克斯动画总裁 Ed Catmull的《创造力》一书的中心思想就是，一个伟大的团队远胜于一个伟大的想法：让合适的人产生合适的化学反应比得到正确的想法更重要。

我们极少在隔绝情况下形成想法，看看想法来自何处能推动我们自己的创意。更妙的是，在团队中把灵感汇集很容易产生新的创意。

一个忠告：避免指责或者居高临下，比如暗示他们的想法是偷来的。尽管你希望在不影响创新的情况下，设计师推动对于自己创意驱动的理解和创意来源。

伟大的UI就像一个好故事，你得小心编排。开启表单填写时需要展示多少信息恰到好处？是否展示了对应上下文的信息方便用户理解？是否已经到了揭露结论的正确时刻？

「优秀的适时交互是让产品（服务）吸引或失去客户的关键区别。将间歇性的互动变为持久关联的秘诀在于一系列精彩微交互，以及当用户需要时恰好出现的信息内容。 在设计评审流程中，应当询问每一个行动、每一次询问或者每一次数据展示是否出现在正确的时机，以确保界面在切换时传递信息时顺畅。」

“我们是否可以运用动效来添加视觉线索？” 这个问题可能会让不少已习惯于静态设计多年的设计师们感到意外。不过，动效、动画与转场过渡将成为体验设计的标准。动效将在设计中成为颜色一样的重要元素。

「随着扁平化设计与用户体验趋势的摇摆变化，我们能预感到页面部件缺少视觉线索的风险，因此动画能减少这种风险。

这种动效可能是颜色、透明度的变化，也可能是用猴子的手臂延伸页面这种细节，或者用户完成任务后展示太阳升起的效果。在UI设计中加入动效将极大的推动设计师改善设计，使得设计师思考时间维度的设计细节，而不只是局限在空间维度。」

“我们如何使它更简单？” 要做到简单很难，增加东西比移除东西更容易，因此许多界面得了“暴雪中的雪花”综合症，当然这里的每个雪花都是独一无二的，只是在暴雪中容易被忽略罢了。在UI设计中，我们常看到界面上充斥着链接、按钮、控件和图片，客户往往认为需要将用户可能用到的东西都放出来，这样一来用户根本无法找到实际需要的东西。

对用户的真实目标来说，页面或屏幕上的任何元素都不是解决方案的一部分，而是噪音和干扰。 在设计的每一步中，我们都需要自问：我们如何能够创造更小思考成本下能发挥同样作用的产品？在设计评审中，这是要求把方案简化的最佳表达。在设计中保持界面清晰很重要，使用尽可能少的点击、文案和输入框来达成目标更好。踏踏实实的把用户需要完成工作的消耗降到最低，用户会感激不尽。

“接下来会发生什么？”

优秀的设计评审与优秀的采访类似：他们都是一种探索。一名优秀的采访者Studs Terkel说过：

采访不是审讯，而是一种探索，对过去发生事情的探索。因此我认为最绅士的问题就是最好的问题，“请问接下来如何呢？”

将它应用到UI设计上，我们通常问设计师接下来发生什么。这个问题帮助他们进一步思考后续考虑事项。因为每一步行动后用户终归得有一个地方可去。

任何UI设想的最大挑战之一就是考虑所有可能的用户路径，而不仅仅是我们希望用户去走的“happy path”。用户点击按钮后发生什么？如果出现错误怎么办？用户提交表单后会发生什么？一直询问接下来发生什么，直到你们考虑到每一个可能的场景，否则就可能存在让用户无所适从的风险，这是一种糟糕的体验。

不要只是提问，还要回答它们 对与此有关的任何人提问时，不要只是简单的问一些你想听到的答案。当某人向你提问但又不听你的解释或者理解你的思路，只愿意听到它们想要的答案时，这会让人反感。

如果你曾经这样，马上改掉。问完问题后洗耳恭听，接下来基于听到的回答，而不是那部分你想听到的内容，来构建你的回复。

优秀的设计评审有什么特征？

评审的质量取决于参与者技能、目标和责任。不过一个优秀的设计评审通常都聚焦在产品某个具体细节，并针对当前的方案进行透彻的探索。

UI设计评审不只是在关注到视觉方面，而应该在交互和用户需求满足上聚焦。参与者经常会问为什么事情没有按照他们预期的方式进行，而不是考虑用户的需求。来自UX for Good公司的Jason Ulaszek告诉我他的观点：

「在讨论中保持客观，考虑该设计使用用户的心智模型，这是我们探讨方案的关键。」

时刻记住，像逐帧动画一样，最终成品的1秒影响需要数周甚至数月的努力。尽管我们可能在界面的某个小细节上就需要花费很多精力，可能它在用户的使用体验中也只是很小的一部分。

我们认为，很棒的产品描述（比如产品手册）对用户来说就跟“坐在60码时速的车上看到的广告牌一样”，UI设计师们比较难理解用户是如何忽略这些产品界面细节的，尽管设计师为此付出诸多努力。 优秀的设计评审放慢节奏，考虑每个元素，但是能认识到这些设计细节可能不会被用户注意到。如果参加评审的人员在颜色、字体及体验设计方面没有专业知识，他们可以考虑以下重要因素：

1）一致性

在产品中的设计是否保持一致，包括颜色、字体、控件、图像及任何使用超过一次的界面设计元素（静态、动态）。

2）上下文

你是否统一考虑了用户使用产品时的上下文？不断去询问这个问题是关键，因为在设计或测试中很可能你只是在模拟，而不是在上下文环境下共情。

3）调性

品牌和设计是否有清晰一致并且可辨识的调性。

4）转场过渡

界面上重要变化状态之间的过渡是否使用了转场效果？现代设计不仅仅是视觉方面的因素，考虑所有的界面元素在用户交互时是如何移动和变化的。

5）简单

对于完成任务，设计是否足够简单？

避免敌对批判

评审时常充斥着PK，团队成员不管出于何种原因，总习惯忽略创造过程中的思考而进行批判。他们带着自身偏见看待设计，而不是从用户出发，有时候只是为了显得自己牛逼。

你一定能想起出现过激争论的评审：设计师开始对设计决策进行辩护，而不是解释如何得到的方案并且讨论其它替代可能。避免变成争论的关键在于设定清晰的原则并且提出开放的建设性意见。记住，评审时用来加强设计协同共建，而不是竞稿。

评审变成PK的话毫无意义并且会伤害团队。对抗性的批判会强迫设计师进入一种防卫姿态，只想护卫完成的工作，而不是拓展和改善它们。设计本身就是大部分依赖直觉，并不容易量化评估。

不过，这并非意味着评审只是讨论对设计师的看法，应该讨论对设计师通过经验形成的方案的看法。

「经验告诉我，不要试图一概而论。例如我会问“我不确定开放的banner是否足以传达品牌？”，而不是问“哇，用户根本不会理解我们的品牌价值。”」

结语：设计评审不是可用性测试

我们很容易认为自己是站在用户角度共情，或者通过使用用户角色，或者自身带有偏见。无论使用多少用户角色，经历多少轮评审，你仍然不是你的用户。

「这就是为什么我认为每个设计师应该花时间观察用户并且使用自己的产品（又称可用性测试）。」

如同激光测量精度跟肉眼估算测量精度对比一样，可用性测试比设计评审更加精确，也更加费时费力。常规设计评审对于项目实现目标没有直接价值贡献，也无法取代真实用户现场测试。如果只进行评审而不去做可用性测试，得到的结论就是自high。