异步设计评审：给予反馈

反馈（无论以何种形式呈现或命名）是我们最有效的软技能之一，它能够通过协作让设计更趋完善，同时促进个人技能和视角的成长。然而，反馈也是最被低估的工具之一——我们常自认为擅长反馈而止步不前，却忘了这是一项可以通过训练和提升的技能。低质量的反馈会导致项目混乱、打击士气，并长期影响信任与团队协作；而高质量的反馈则能成为变革的催化剂。

虽然练习是提升技能的好方法，但若能与良好的基础框架结合，学习效果会更快。什么是提供良好反馈的基础要素？如何调整反馈方式以适应远程和分布式工作环境？

在互联网领域，异步反馈有着悠久的传统：从早期的开源时代，代码就通过邮件列表分享和讨论；如今，开发者在拉取请求中交流，设计师在常用设计工具中评论，项目经理和敏捷教练在任务单中交换想法等等。

设计评审（Design critique）通常指为改进工作而提供的协作式反馈。它既包含一般反馈的原则，也有其独特之处。

反馈内容#section2

所有优质评审的基础在于反馈内容，这是我们首先需要关注的。有多种模型可帮助构建内容，我个人最喜欢的是Lara Hogan提出的模型（因其清晰且可操作）：

观察（Observation）+ 影响（Impact）+ 问题（Question）= 有效反馈

虽然该公式通常用于人际反馈，但也非常适合设计评审，因为它最终回答了核心问题：什么？哪里？为什么？如何？假设你正在评审一个多屏幕的设计工作（如用户引导流程）：展示了一些页面、流程蓝图和决策概述。你发现某处可改进。若牢记公式中的三要素，你就有了一个心智模型来帮助更精准、有效地表达。

以下是一条看似合理的反馈评论，它表面上满足了公式要素，但真的有效吗？

“按钮样式和层级不太确定——感觉不对。能改一下吗？”

在设计反馈中，“观察”不仅指指出界面中反馈所涉及的部分，还要提供尽可能具体的视角：是用户视角？专家视角？业务视角？项目经理视角？还是首次使用者的视角？

“当我看到这两个按钮时，我期望一个前进，一个后退。”

“影响”关乎原因。仅指出UI元素有时可能足够（若问题明显），但更多时候应补充解释。

“当我看到这两个按钮时，我期望一个前进，一个后退。但这是唯一出现此情况的屏幕，之前我们仅使用单个按钮和‘×’关闭。这似乎破坏了流程的一致性。”

“问题”方法旨在通过激发接收反馈的设计师的批判性思维，提供开放式指导。值得注意的是，在Lara的公式中，她还提供了第二种方法：“请求”（Request），即指向特定解决方案的指导。虽然这对一般反馈可行，但根据我的经验，在设计评审中默认使用问题方法通常能达成最佳解决方案，因为设计师更倾向于在开放空间中探索。

两种方法的区别可通过以下示例说明：

• 问题方法：
  “当我看到这两个按钮时，我期望一个前进，一个后退。但这是唯一出现此情况的屏幕，之前我们仅使用单个按钮和‘×’关闭。这似乎破坏了流程的一致性。统一它们是否合理？”

• 请求方法：
  “当我看到这两个按钮时，我期望一个前进，一个后退。但这是唯一出现此情况的屏幕，之前我们仅使用单个按钮和‘×’关闭。这似乎破坏了流程的一致性。确保所有屏幕都有相同的前进和后退按钮。”

在某些情况下，补充一个“为什么”可能有用：为什么你认为给定建议更好。

“当我看到这两个按钮时，我期望一个前进，一个后退。但这是唯一出现此情况的屏幕，之前我们仅使用单个按钮和‘×’关闭。这似乎破坏了流程的一致性。确保所有屏幕都有相同的前进和后退按钮，以免用户困惑。”

选择问题方法或请求方法有时也取决于个人偏好。我曾努力改进我的反馈：进行匿名反馈轮次，并与他人复查反馈。经过几轮工作和一年后，我得到了积极回应：我的反馈显得有效且 grounded。直到我换了团队。令我震惊的是，下一轮反馈来自某人的评价并不好。原因是我之前尽量避免在建议中显得专断——因为之前的同事更喜欢开放式问题而非请求式建议。但在新团队中，有人更偏好具体指导。于是我调整反馈，包含请求。

我多次听到的一种评论是：这种反馈相当长，似乎效率不高。不……但也对。我们来探讨两面性。

不，这种反馈风格实际上高效，因为长度是清晰度的副产品，花时间给出此类反馈可为良好修复提供足够信息。此外，从宏观角度看，它能减少未来的来回对话和误解，提高协作的整体效率和有效性。想象一下，若上例中的反馈仅是：“确保所有屏幕都有相同的前进和后退按钮。”接收反馈的设计师没有太多依据，可能只是应用更改。在后续迭代中，界面可能变化或引入新功能——也许该更改不再合理。没有“为什么”，设计师可能认为更改关乎一致性……但如果不是呢？因此，可能存在潜在担忧：更改按钮会被视为回归。

是的，这种反馈风格并非总是高效，因为某些评论的点不需要总是详尽，有时因为更改明显（“使用的字体不符合我们的指南”），有时因为团队可能有大量内部知识，某些“为什么”可隐含。

因此，上述公式并非建议严格的反馈模板，而是作为反思和改进实践的助记符。即使经过多年积极评审工作，我仍不时回顾此公式，反思刚写的内容是否有效。

语气#section3

grounded的内容是反馈的基础，但这还不够。提供评审者的软技能可以倍增反馈被接受和理解的可能性。仅语气就足以决定内容被拒绝或欢迎，且已证明只有积极反馈能带来持续改变。

由于我们的目标是被理解并拥有积极的工作环境，语气至关重要。多年来，我尝试将所需软技能总结为一个与内容公式镜像的公式：接受度方程。

尊重（Respectful）+ 时机（Timing）+ 态度（Attitude）+ 形式（Form）= 可接受的反馈

尊重的反馈显得 grounded、 solid 和建设性。这种反馈无论积极还是消极，都被视为有用和公平。

时机指反馈发生的时间。若时机错误，切中要点的反馈也很难被接受。在新功能即将发布时质疑其整个高层信息架构可能仍相关（若质疑突出了无人看到的主要障碍），但更可能的是，这些担忧必须等待后续重做。因此，通常应根据项目阶段调整反馈：早期迭代？晚期迭代？进行中的抛光工作？这些都有不同需求。正确时机使反馈更易被接受。

态度相当于意图，在人际反馈中可称为“激进坦率”（radical candor）。这意味着在写作前检查我们心中的内容是否真能帮助对方并整体改善项目。这有时是艰难的反思，因为也许我们不愿承认我们并不真正欣赏那人。希望不是这样，但若发生，也没关系。承认并拥有这一点可帮助你弥补：若我真正关心他们，我会怎么写？如何避免被动攻击？如何更建设性？

形式在多样化和跨文化工作环境中尤其相关，因为若写作方式导致误解，再好的内容、完美时机和正确态度也可能无法传达。原因可能多种：有时某些词可能触发特定反应；有时非母语者可能不理解句子的所有细微差别；有时我们的大脑可能不同，对世界的感知也不同——必须考虑神经多样性。无论原因如何，重要的是不仅审查我们写什么，还有如何写。

几年前，我请求关于我如何给予反馈的反馈。我收到了一些好建议，但有一条评论让我惊讶。他们指出，当我写“哦，[…]”时，让他们感到愚蠢。这不是我的意图！我感到非常糟糕，并意识到我向他们提供反馈数月，每次可能都让他们感到愚蠢。我震惊……但也感激。我快速修复：将“oh”添加到我的替换词列表中（可选择：macOS的文本替换、aText、TextExpander或其他），这样当我输入“oh”时，它立即被删除。

需要强调的是，在团队精神强烈的团队中，人们往往拐弯抹角。重要的是记住，积极态度并非意味着对反馈轻描淡写——它意味着即使你提供艰难、困难或具有挑战性的反馈，也以尊重和建设性的方式进行。你能为某人做的最好的事是帮助他们成长。

书面反馈有一个巨大优势：它可以由未直接参与的他人复查，这有助于减少或消除可能存在的偏见。我发现，对我而言最 insightful 的时刻是当我分享一条评论并问我高度信任的人：“这听起来如何？”、“我如何能做得更好？”甚至“你会怎么写？”——通过并排比较两个版本，我学到了很多。

格式#section4

异步反馈还有一个主要固有优势：我们可以花更多时间精炼所写内容，确保其满足两个主要目标：沟通的清晰度和建议的可操作性。

假设有人分享了一个项目的设计迭代。你正在评审并留下评论。有多种方式可以做到这一点，当然上下文很重要，但让我们思考一些可能有用的元素。

在清晰度方面，首先通过提供上下文来 grounded 你即将给出的评审。具体来说，这意味着描述你的背景：你对项目有深入了解，还是第一次看到？你来自高层视角，还是在弄清楚细节？是否有回归？在提供反馈时，你采取哪个用户的视角？设计迭代是否处于可以发布的状态，还是有哪些主要问题需要先解决？

即使你在已有项目信息的团队内分享反馈，提供上下文也有帮助。而在跨团队反馈时，上下文绝对必要。如果我评审一个可能与我工作间接相关的设计，且我对项目如何到达该点一无所知，我会说明，强调我的看法是外部的。

我们常关注负面，试图概述所有可改进之处。这当然重要，但关注正面同样重要（甚至更重要），特别是若你看到从前一迭代的进展。这可能显得多余，但请记住，设计是一个有数百种可能解决方案的学科。因此，指出所选设计解决方案是好的并解释为什么好，有两个主要好处：它确认所采取的方法是 solid 的，并帮助 grounded 你的负面反馈。长期来看，分享积极反馈有助于防止在进展良好的事情上出现回归，因为这些事情已被强调为重要。作为奖励，积极反馈还有助于减少冒名顶替综合症。

有一种强大方法结合了上下文和关注正面：框定设计如何比现状更好（与前迭代、竞争对手或基准相比）及为什么，然后在此基础上添加可改进之处。这很强大，因为针对 already in good shape 的设计的评审与针对尚未到位的设计的评审有很大区别。

另一种改进反馈的方法是去个性化反馈：评论应始终关于工作，而非制作它的人。是“这个按钮没有对齐好” versus “你没有对齐好这个按钮”。这很容易通过在发送前复查来改变写作。

在可操作性方面，帮助阅读反馈的设计师的最佳方法之一是将反馈分成 bullet points 或段落，这样更容易逐条复查和分析。对于较长的反馈，你还可以考虑将其分成部分甚至跨多个评论。当然，添加截图或标记你所指界面特定部分的符号也特别有用。

我个人在某些上下文中有效使用的一种方法是用四个表情符号标记增强 bullet points。红色方块 🟥 表示我认为是阻塞性的；黄色钻石 🔶 表示我可以被说服，但在我看来应该更改；绿色圆圈 🟢 表示详细的积极确认。我还使用蓝色螺旋 🌀 表示我不确定的事情、探索、开放替代方案或仅是注释。但我只在已建立良好信任水平的团队中使用此方法，因为若我不得不提供许多红色方块，影响可能相当 demoralizing，我会重新框架沟通方式。

让我们通过重用之前的示例作为此列表的第一个 bullet point 来看看如何工作：

• 🔶 导航—当我看到这两个按钮时，我期望一个前进，一个后退。但这是唯一出现此情况的屏幕，之前我们仅使用单个按钮和“×”关闭。这似乎破坏了流程的一致性。确保所有屏幕都有相同的前进和后退按钮，以免用户困惑。
• 🟢 整体—我认为页面 solid，这足够好作为我们1.0版本的发布候选。
• 🟢 指标—指标区域按钮的良好改进；改进的对比度和新焦点样式使它们更易访问。
• 🟥 按钮样式—在此上下文中使用绿色强调色会给人积极行动的印象，因为绿色通常被视为确认颜色。我们需要探索不同颜色吗？
• 🔶 瓷砖—鉴于页面上的项目数量和整体页面层级，在我看来瓷砖不应使用副标题1样式，而应使用副标题2样式。这将保持视觉层级更一致。
• 🌀 背景—使用轻纹理效果很好，但我想知道在此类页面中是否添加了太多噪音。使用它的思考是什么？

直接在Figma或其他允许就地反馈的设计工具中给予反馈如何？总的来说，我发现这些难以使用，因为它们隐藏讨论且更难跟踪，但在正确上下文中，它们可能非常有效。只需确保每个评论是分开的，以便更容易将每个讨论匹配到单个任务，类似于上述拆分想法。

最后一点：说出显而易见的。有时我们可能觉得某事明显好或明显错，因此不说。或者有时我们可能有疑问但不表达，因为问题可能听起来愚蠢。说出来——没关系。你可能需要稍作 rewording 让读者更舒适，但不要忍住。好的反馈是透明的，即使它可能明显。

异步反馈还有另一个优势：书面反馈自动跟踪决策。特别是在大型项目中，“我们为什么这样做？”可能不时出现，没有什么比可随时复查的开放、透明讨论更好。因此，我推荐使用保存这些讨论的软件，而不在解决后隐藏它们。

内容、语气和格式。每个主题都提供了一个有用模型，但同时改进八个领域——观察、影响、问题、时机、态度、形式、清晰度和可操作性——是大量工作。一种有效方法是逐个处理：首先确定你最缺乏的领域（从你的视角或他人反馈），然后开始。接着第二个、第三个，依此类推。起初，你必须为每条反馈投入额外时间，但一段时间后，它会成为第二天性，你对工作的影响将倍增。

感谢Brie Anne Demkiw和Mike Shelton审阅本文初稿。