如何运行 UI 设计评论

批评很容易。 似乎每个人都有自己的意见，但是，正如作者哈兰·埃里森所指出的，“你无权发表自己的意见。 你有权获得你的知情意见。” 然而，要了解情况，需要探索。 设计评论是任何产品探索的重要组成部分。

设计评论——创作者与团队和/或客户的其他成员讨论和解释创作——并不是要纠缠设计师或推动他们为他们所做的每一个决定辩护。 那只是批评。 一个好的设计评论旨在探索设计，找到它在哪里工作以及在哪里可以改进。 如果做得好，设计评论会让团队中的每个人都感觉好像他们被听到了，并让客户提供有价值的反馈。

关于 SmashingMag 的进一步阅读：

• 网页设计批评：一个方法
• 面对你的恐惧：接近人们进行研究
• 如何有效应对设计批评
• Rainbow 电子表格：协作式精益用户体验研究工具

如果您是进行评论的人，那么获得建设性的批评通常是一个挑战，尤其是对于没有设计评论格式经验的团体。 在敏捷环境中，您通常会有编码员、项目经理、产品经理和其他学科的人员坐下来提供反馈，如果您想快速到达任何地方，您需要知道如何让他们快速达到预期.

运行出色的 UI 评论的原则

根据我自己的经验，我发现对用户界面 (UI) 的设计评论需要在整个产品设计和开发过程中进行，至少每周一次，甚至可能每天在某些时间进行。 它们使产品设计保持在正轨上，并且在交互式敏捷或精益 UX 产品环境中变得更加重要，其中设计在部署之前要经过多次迭代。 运行 UI 设计评论是一项挑战，不仅需要您解释决策，还需要仔细聆听其他想法。

在每次批评开始时建立明确的原则——而不是“规则”——势在必行。 与教条和限制性的规则不同，原则可以帮助每个人理解期望，但仍然允许所需的自由形式的讨论。

这些期望中最主要的是让每个人都同意为什么你实际上在批评你正在看的东西。 Jason Ulaszek 建议：

首先询问您要批评的设计背后的目的或意图。 我们为什么要询问这条信息？ 已经设定了哪些期望让我们能够要求它？ 我们将如何处理它？ 如果我们可以回答这些问题，那么我们将继续讨论各种选项，以解释对元素的需求以及每个选项各自的优缺点。

为了帮助您遵守本指南，我建议您遵循适用于任何设计评论的标准原则，无论是否涉及 UI 设计：

• 表示尊重。 . 这听起来可能有些陈词滥调，但如果批评中的每个人都不尊重桌上其他人的意见和技能，那么批评很快就会变成敌意。
• 指定角色。 . 在开始之前，请明确在评论期间谁将担任哪些角色。 最好将这些从批评到批评混合起来，这样就不会让人感到被忽视了，如果三个主角是不同的人，这是最佳的（但这并不总是可行的）。
  • 主持人。 这是负责展示设计及其背后的思想的人。 此人回答所有问题或将问题引导给评论中可以回答这些问题的其他人。
  • 主持人。 如果可能的话，这个角色最好由不直接负责设计的人来执行，通常是项目或产品经理。 主持人确保每个人都关注主题并听到每个人的声音。
  • 记笔记。 此人专注于记录所讨论的内容，对于确保在评论结束时明确定义要点（另一个原则，如下所列）尤为重要。 记录者不应该被排除在讨论之外，尽管他们的角色可能倾向于让团队的其他成员澄清他们所说的话。
• 说明项目的目标和预先的批评。 . 快速提醒每个人该项目的目标以及此特定评论将涵盖的内容。 让批评集中在手头的任务上，而不是让范围蔓延到会破坏讨论主要目的的其他考虑因素。
• 查看受众。 . 为了强调评论中的人不是产品的目标受众，提醒每个人谁是。
• 避免提出“答案”。 参与者会产生强烈的解决问题的愿望，并在评论中提出“答案”。 然而，最好的解决方案很少出现在实际会议中。 批评的重点是探索问题并讨论多种潜在的解决方案，供设计师带走和考虑。
• 同意外卖。 . 在评论中说完所有内容后，记录员需要为参与的每个人检查外卖任务，以确保每个人都在下一次评论的同一页面上。

不幸的是，UI 设计评论经常集中在视觉上，而对设计的交互性（更不用说时间性）的本质关注不够。 对于 UI 设计评论，请添加以下元素：

• 识别演示媒体。 . 除了确定受众之外，还要查看用于创建产品的平台和技术。 这是一个 iPhone 应用程序吗？ 一个网站？ 你在使用 AngularJS 吗？ C＃？ 确保将这些都考虑在内，以避免提出行不通的解决方案。
• 概述工艺流程。 . 你需要知道路线图。 对于 UI 设计，这将是用户体验的流程。 这可能以故事板、旅程地图或其他描述过程的方式出现，但在考虑 UI 之前，每个人都应该熟悉它。
• 演示产品，但展示多于讲述。 . 这一点我怎么强调都不为过：出色的用户体验比说明要多得多。 最终用户需要以最少的解释准确地了解产品的工作原理。 您的演示还应该尽可能少地解释。 俗话说，好的 UI 就像一个笑话：非要解释，就不是很好。

提出正确的问题

在设计评论中，大量的问题和陈述不利于强有力的合作。 以下是我发现的一些问题，可以以协作而非好斗的方式探索设计，您可以向您的团队提出建议。

“你是怎么想出这个解决方案的？”

开始任何批评或对话的好地方是询问设计师是如何——而不是为什么——他们做了某事。 问为什么会立即让他们处于守势，同时问如何在不需要证明的情况下邀请对概念起源的探索。

“为什么”问题促使我们试图证明某事是“真实的”，而不是把它解释为一种可能性。 根据亚伦莫顿：

“为什么”引出一个故事，解释为什么某事是真的。 如果你问为什么一切都没有按照你想要的方式进行，你可能会创造一个故事，这可能是真的，也可能不是。 这是让你感觉不好的危险领域。

与其问“为什么”，不如考虑问“如何”的问题来引出一个关于创造过程的故事，而不是为它的存在辩护。 然后，您可以从那里询问设计师之前考虑过哪些可能性，然后才能探索他们可能没有考虑过的替代方案。 但在提供建议之前，请仔细聆听设计师已经尝试过的内容。 他们可能忽略了某些事情，但假设如此，请不要进入对话。

“你从哪里得到这样的想法？”

托马斯爱迪生有句名言：“天才是百分之一的灵感和百分之九十九的汗水。” 但他很大程度上从尼古拉特斯拉那里偷走了他的百分之一。 再一次，毕加索说，“优秀的艺术家借用，伟大的艺术家偷窃”（但他可能偷了那句台词）。

皮克斯动画公司总裁 Ed Catmull 的著作Creativity, Inc的中心思想是拥有一支优秀的团队比拥有一个伟大的想法更重要：

找到合适的人和正确的化学反应比获得正确的想法更重要。

我们很少在真空中构思想法，思考我们从哪里获得灵感可以推动我们自己的创新。 更好的是，将我们的灵感汇集在一个团队环境中可以产生新的想法。

提醒一句：小心不要听起来指责或居高临下——即暗示他们偷了这个主意。 不过，您确实希望设计师在不压制创新的情况下，推动他们对自己想法的动机和来源的理解。

“这需要什么时候发生？”

就像喜剧一样，时间设计就是时间设计的一切，事件需要在正确的时间以正确的顺序发生。 然而，当我们在设计时，这个顺序并不总是很明显，直到我们不得不坐下来解释它。

一个好的用户界面就像一个伟大的故事，这意味着你必须小心地调整它的节奏。 多少信息才足以开始使用表格？ 您是否在正确的上下文中显示数据以供用户理解？ 现在是揭示结论的正确时机吗？

帮助非营利组织通过新闻与人们建立联系的初创公司 Public Good 的首席执行官 Jason Kunesh 告诉我：

对我们的客户而言，在合适的时机进行良好的互动是产品或服务的快乐粉丝与失去联系机会之间的区别。 将随意的互动转变为持久的关系取决于一系列微小的、积极的互动和当人们准备好时的信息。

批评过程的一部分应该是通过每一个机会询问这是否是执行操作、提出问题或提供数据的正确时机来消除界面时间上的皱纹。

“我们可以使用运动来添加视觉提示吗？”

这个问题会让很多习惯了多年来主导 UI 设计的静态特性的设计师感到惊讶。 然而，运动、动画和过渡正在成为体验设计的常态。 运动很快将在设计中与颜色一样重要。

根据 UI 动画专家 Rachel Neighbors 的说法：

随着扁平化设计的兴起和随之而来的用户体验问题，我们已经看到从网站组件中剥离视觉线索是多么危险。 动画可以用于相反的效果。

移动或变化可以简单到不透明度或颜色的变化，或者猴子的手臂在页面上伸展，或者用户完成任务时太阳升起。 询问在 UI 设计中添加即时运动通常会促使设计师以良好的方式改变他们的观点。 推动设计师超越离散时刻进行思考，及时讨论设计，而不仅仅是空间。

“我们怎样才能让它变得更简单？”

简单是很难的。 似乎添加总是比删除更容易，而且许多 UI 都患有我喜欢称之为“暴风雪中的雪花”综合症：当然，每一片雪花都是独一无二的，但在暴风雪中你永远不会注意到这一点。 在 UI 设计中，我们经常看到充满链接、按钮、控件和图像的界面。 客户通常会认为他们需要包含观众可能需要的所有内容，以至于您无法找到您真正需要的任何内容。

我把简单的问题提给了《不要让我思考》的作者史蒂夫·克鲁格（Steve Krug）：

我认为这是一个非常有用的问题。 我原以为这是每个人现在都吸收的一课，但我知道他们没有。 我总是喜欢说页面或屏幕上的任何不属于解决方案的部分——对于用户的真正目标——都是噪音，并且可能被抛弃。

在设计的每一步，我们都需要问自己，我们如何才能创造出不需要思考却又保持同样力量的东西？ 在批评中，最好通过询问如何使事情变得更简单来表达这一点。 保持设计的清晰很重要，但要做到这一点，需要更少的点击、更少的文本和更少的表单域。 降低完成工作所需的最低限度，您的用户会感谢您。

“接下来发生什么？”

出色的设计评论与出色的采访有很多共同点：它们都是关于探索的。 最伟大的采访者之一，Studs Terkel 说：

[采访]不是审讯； 这是一种探索，通常是对过去的探索。 所以我认为最温和的问题是最好的，最温和的是，“然后发生了什么？”

将此应用于 UI 设计，我们总是需要让设计师思考接下来会发生什么。 这个问题邀请他们思考超越他们认为的目的。 用户必须始终有下一步可去的地方。

设想任何 UI 的最大挑战之一是考虑所有可能的路径，而不仅仅是我们希望用户采取的“快乐路径”。 他们点击按钮后会发生什么？ 如果出现错误会怎样？ 他们提交表格后会发生什么？ 询问接下来会发生什么，直到你考虑了所有可能的情况，否则你会冒着让用户挂起的风险，这总是一种糟糕的体验。

不要只是问问题来回答他们

当问这些问题时——或任何其他问题——不要简单地问，这样你就可以回答自己。 当有人问你一个问题不是为了听到你的答案或理解你的想法而只是为了听到他们自己的声音时，这很烦人。

如果你是这些人中的一员，请立即将其删除。 问你所有的问题，敞开心扉接受给出的答案。 然后，根据这些答案而不是您想听到的答案来制作您的回复。

好的用户界面评论是什么样的

批评会因参与者的技能、目标和职责而有很大差异。 然而，好的评论总是关注产品的特定方面，并彻底探索提出的解决方案。

UI 评论不仅关注产品目前的外观，还关注它随着时间的推移如何工作以及这是否最适合用户的需求。 参与者往往不考虑用户的需求，而是想知道为什么某些事情没有按照他们预期的方式完成。 UX for Good 的 Jason Ulaszek 表示同意，并告诉我他自己的批评：

在我们的讨论中保持客观并考虑负责使用设计的个人[即用户]的心理模型对于我们如何讨论解决方案至关重要。

永远记住——就像基于单元格的动画一样，一秒钟的最终电影可能需要数周或数月才能制作出来——虽然我们可能会花费数小时来苦恼界面中的一分钟细节，但它可能只是昙花一现用户的雷达。

当我问史蒂夫克鲁格这个问题时，他有这样的说法：

我们在想，“伟大的文学作品”（或至少是“产品手册”），而用户的现实更接近于“以每小时 60 英里的速度行驶的广告牌”。 对于 UI 设计师来说，很难意识到人们正在以多快的速度浏览——或过去——他们辛辛苦苦开发的界面，以及他们实际使用的界面有多么少。

一个好的 UI 评论会放慢考虑每个元素的速度，但要认识到这不是用户看到设计的方式。 如果您的评论中的参与者没有接受过直接与颜色、排版或体验设计对话的正式培训，他们仍然可以在所有 UI 设计中考虑这些重要因素：

• 一致性。 整个产品的设计及其实现是否一致？ 这包括在界面中多次使用的颜色、排版、控件、图像和任何设计元素（静态或交互式）。
• 上下文。 您是否始终尊重用户在使用产品时的环境？ 不断地问这个问题是关键，因为你可能不在那个环境中，而只是在设计或测试时模拟它。
• 声音。 品牌和设计是否有清晰、一致和可识别的声音？
• 过渡。 您是否使用从状态到状态的转换来进行 UI 中的任何重大更改？ 现代设计远不止视觉。 考虑所有界面元素在用户交互过程中如何移动和变化。
• 简单。 设计是否尽可能简单以完成工作？

避免敌意批评

批评可以——而且经常是——以一种好斗的方式进行，无论出于何种原因，团队成员都倾向于批评工作，而不听其创作过程中的思考过程。 他们将自己的偏见带入设计中，而不是考虑用户，而且他们经常只是试图展示自己的聪明程度。

当批评变得过于激进时，你总能看出：设计师往往对他们的决定变得棘手，而不是解释他们是如何得出这些决定的并讨论替代方案。 避免激进批评的关键是制定明确的原则并提出开放式的建设性问题。 请记住，这个想法是加强协作设计，而不是赢得设计战。

我发现激进的批评是无益的，而且通常是有害的。 对抗性的批评迫使设计师采取防御姿态，使他们在所做的事情中根深蒂固，而不是授权他们去扩展它。 设计在很大程度上是直观的，并不总是容易量化的，更不能量化。

然而，这并不意味着批评纯粹是关于设计师的意见； 它是关于设计师通过多年研究获得的明智意见。 Agentic 的网络制作人 Phillip Djwa 认为关键是……

……根据我的经验说话，而不是试图一概而论。 例如，我会问，“我想知道开幕横幅是否充分传达了品牌？” 而不是“哇，人们永远不会明白我们有什么品牌价值。”

最后一句话：批评不是可用性测试

通过使用角色或您自己的偏见，很容易欺骗自己认为您是在为观众说话。 无论您创建了多少角色或经历了多少批评，您都不是您的听众。 史蒂夫克鲁格告诉我：

这就是为什么我认为每个设计师都应该花时间观察人们尝试使用他们所构建的东西（也称为可用性测试）的原因之一。

就像激光水平仪与气泡水平仪一样，可用性测试比内部批评更精确和准确，但通常也更耗时和昂贵。 定期的设计评论对于保持项目的目标是非常宝贵的，但永远不能取代进入现场并与现实生活中的用户进行测试。 否则，你所做的就是自言自语。