异步设计评审：获取反馈

“有什么意见吗？”可能是寻求反馈最糟糕的方式之一。它模糊且开放，没有提供任何我们正在寻找的指示。获得良好反馈的开始比我们预期的要早：它始于请求。

从问题开始

以问题开始接收反馈的过程可能看起来违反直觉，但如果我们意识到获取反馈可以被视为设计研究的一种形式，这就说得通了。就像我们不会在没有正确问题的情况下进行任何研究以获得我们需要的见解一样，寻求反馈的最佳方式也是提出尖锐的问题。

设计评审不是一个一次性的过程。当然，任何良好的反馈工作流程都会持续到项目完成，但对于设计来说尤其如此，因为设计工作会一次又一次地迭代，从高层次到最精细的细节。每个级别都需要自己的一套问题。

最后，与任何良好的研究一样，我们需要回顾我们得到的内容，深入其见解的核心，并采取行动。问题、迭代和回顾。让我们逐一看看。

问题

对反馈持开放态度是必要的，但我们需要明确我们正在寻找什么。仅仅在演示结束时说“有什么意见吗？”、“你怎么看？”或“我很想听听你的意见”——无论是面对面、通过视频还是通过书面帖子——很可能会得到各种不同的意见，或者更糟的是，让每个人都跟随第一个发言的人的方向。然后……我们感到沮丧，因为像这样模糊的问题可能会将高层次流程审查变成人们评论按钮边框。这可能是一个热烈的话题，因此当时可能很难将团队重新引导到你想要关注的主题上。

但我们是如何陷入这种情况的？这是多种因素的混合。一个是我们通常不认为提问是反馈过程的一部分。另一个是让问题隐含是多么自然，期望其他人能够理解。另一个是在非专业讨论中，通常不需要那么精确。简而言之，我们往往低估了问题的重要性，因此我们没有努力改进它们。

提出好问题的行为指导并聚焦了批评。它也是一种同意形式：它清楚地表明你愿意接受评论，以及你希望得到什么样的评论。它让人们处于正确的心理状态，特别是在他们不期望给予反馈的情况下。

没有单一的最佳方式来寻求反馈。它只需要具体，而具体性可以采取多种形式。我在辅导中发现特别有用的设计批评模型是阶段与深度的模型。

“阶段”指的是过程的每一步——在我们的案例中，是设计过程。从用户研究到最终设计的进展中，反馈的类型也在演变。但在一个步骤内，人们仍然可以审查某些假设是否正确，以及随着项目的发展，积累的反馈是否已正确转化为更新的设计。潜在问题的起点可能来自用户体验的层次。你想知道什么：项目目标？用户需求？功能？内容？交互设计？信息架构？UI设计？导航设计？视觉设计？品牌？

这里有一些精确且切中要点的示例问题，涉及不同层次：

• 功能：自动化账户创建是否可取？
• 交互设计：查看更新后的流程，让我知道你是否有看到我可能遗漏的任何步骤或错误状态。
• 信息架构：我们在这个页面上有两个竞争信息。结构是否有效地传达了两者？
• UI设计：你对页面顶部的错误计数器有什么看法，它确保你看到下一个错误，即使错误在视口之外？
• 导航设计：从研究中，我们确定了这些二级导航项，但一旦你进入页面，列表感觉太长且难以导航。有什么建议来解决这个问题吗？
• 视觉设计：右下角的粘性通知是否足够可见？

具体性的另一个轴是关于你希望对你所呈现的内容深入多少。例如，我们可能引入了一个新的端到端流程，但有一个特定的视图你觉得特别具有挑战性，并希望对其进行详细审查。这在从一个迭代到下一个迭代时尤其有用，其中突出显示已更改的部分非常重要。

当我们想要实现更具体——更有效——的问题时，还有其他事情我们可以考虑。

一个简单的技巧是从你的问题中移除通用限定词，如“好”、“很好”、“不错”、“坏”、“可以”和“酷”。例如，问“当块打开且按钮出现时，这种交互好吗？”可能看起来具体，但你可以发现“好”这个限定词，并将其转换为更好的问题：“当块打开且按钮出现时，下一步行动是否清晰？”

有时我们确实想要广泛的反馈。这很少见，但可能发生。在这种意义上，你仍然可以明确表示你正在寻找广泛的意见，无论是高层次还是细节。或者也许只是说“乍一看，你怎么看？”这样就很清楚你问的是开放式的，但专注于某人看它前五秒的印象。

有时项目特别广泛，某些领域可能已经被详细探索。在这些情况下，明确说明某些部分已经锁定且不接受反馈可能有用。这不是我通常推荐的事情，但我发现它有助于避免再次陷入可能导致进一步改进但并非当前最重要的兔子洞。

提出具体问题可以完全改变你收到的反馈质量。批评技能较不熟练的人现在将能够提供更可操作的反馈，即使是专家设计师也会欢迎仅关注所需内容带来的清晰和效率。它可以节省大量时间和挫败感。

迭代

设计迭代可能是设计工作中最可见的部分，它们为反馈提供了自然的检查点。然而，许多具有内联评论的设计工具倾向于在同一个文件中将更改显示为单个流体流，这些类型的设计工具一旦解决对话就会消失，自动更新共享UI组件，并强制设计始终显示最新版本——除非这些本应有用的功能被手动关闭。这些设计工具似乎隐含的目标是达到一个所有讨论都关闭的最终副本，可能是因为它们继承了书面文档协作编辑的模式。这可能不是处理设计批评的最佳方式，但即使我不想在这里太规定性：这对某些团队可能有效。

我发现最有效的异步设计批评方法是创建明确的讨论检查点。我将使用术语迭代帖子来表示。它指的是设计迭代的书面说明或演示，后跟某种讨论线程。任何可以容纳这种结构的平台都可以使用这个。顺便说一句，当我提到“书面说明或演示”时，我也包括视频录制或其他媒体：只要是异步的，它就有效。

使用迭代帖子有许多优点：

• 它在设计工作中创造了一种节奏，以便设计师可以回顾每次迭代的反馈并为下一次做准备。
• 它使决策对未来回顾可见，对话同样始终可用。
• 它创建了设计随时间变化的记录。
• 根据工具，它可能还使收集反馈并采取行动更容易。

这些帖子当然并不意味着不应使用其他反馈方法，只是迭代帖子可能是远程设计团队使用的主要节奏。其他反馈方法（如实时批评、配对设计或内联评论）可以在此基础上构建。

我不认为迭代帖子有标准格式。但有一些高层次元素作为基线包含是有意义的：

• 目标
• 设计
• 更改列表
• 问题

每个项目可能都有一个目标，希望它已经在其他地方用一句话总结，如客户简报、产品经理的提纲或项目所有者的请求。所以这是我会在每次迭代帖子中重复的内容——字面意思复制粘贴。想法是提供上下文并重复对使每个迭代帖子完整必不可少的内容，这样就不需要查找分布在多个帖子中的信息。如果我想了解最新设计，最新迭代帖子将拥有我需要的一切。

这个复制粘贴部分引入了另一个相关概念：对齐来自重复。因此，拥有重复信息的帖子实际上非常有效，可以确保每个人都在同一页上。

设计然后是实际的信息架构大纲、图表、流程、地图、线框图、屏幕、视觉以及任何其他已完成的设计工作。简而言之，它是任何设计工件。对于工作的最后阶段，我更喜欢术语蓝图，以强调我将展示完整流程而不是单个屏幕，以便更容易理解大局。

用清晰的标题标记工件也可能有用，因为这样可以更容易地引用它们。以便于人们理解工作的方式编写帖子。这与组织良好的现场演示没有太大不同。

为了高效讨论，你还应该包括一个从上一次迭代的更改项目列表，让人们专注于新内容，这对于较大的工作尤其有用，因为跟踪迭代可能成为一个挑战。

最后，如前所述，你必须包括一个问题列表，以将设计批评引导到你想要的方向。将其作为编号列表也可以帮助更容易地通过编号引用每个问题。

并非所有迭代都相同。早期的迭代不需要那么集中——它们可以更具探索性和实验性，甚至可能打破一些设计语言指南以查看什么是可能的。然后 later，迭代开始确定一个解决方案并对其进行细化，直到设计过程结束并发布功能。

我想强调，即使这些迭代帖子被编写和设想为检查点，它们绝不需要是详尽的。一个帖子可能是一个草案——只是一个开始对话的概念——或者它可能是每个迭代中添加的每个功能的累积列表，直到完整图片完成。

随着时间的推移，我还开始对增量迭代使用特定标签：i1、i2、i3，等等。这可能看起来像一个小标签提示，但它可以在多个方面有所帮助：

• 唯一——它是一个清晰的唯一标记。在每个项目中，人们可以轻松地说“这是在i4中讨论的”，每个人都知道他们可以去哪里回顾事情。
• 低调——它像版本（如v1、v2、v3）一样工作，但相比之下，版本给人一种宏大、详尽和完整的印象。迭代必须能够是探索性的、不完整的、部分的。
• 面向未来——它解决了你可能在版本中遇到的“最终”命名问题。不再有名为“最终最终完成真的完成了”的文件。在每个项目中，最大的数字总是代表最新的迭代。

为了标记设计何时完成到可以工作的程度，即使可能还有一些部分需要注意并因此需要更多迭代，可以使用术语发布候选（RC）来描述它：“随着i8，我们达到了RC”或“i12是一个RC”。

回顾

在设计批评期间通常发生的是开放讨论，人们之间的来回可以非常富有成效。这种方法在实时同步反馈期间特别有效。但当我们异步工作时，使用不同的方法更有效：我们可以转向用户研究心态。来自队友、利益相关者或其他人的书面反馈可以被视为用户访谈和调查的结果，我们可以相应地分析它。

这种转变有一些主要好处，使异步反馈特别有效，尤其是在这些摩擦点周围：

• 它消除了回复每个人的压力。
• 它减少了来自临时评论的挫败感。
• 它减少了我们的个人利益。

第一个摩擦点是感到有压力要回复每一条评论。有时我们编写迭代帖子，然后得到团队的回复。只有几条，很容易，感觉不是问题。但其他时候，一些解决方案可能需要更深入的讨论，回复量可能迅速增加，这可能在试图通过回复每个人来成为一个好团队成员和进行下一次设计迭代之间产生紧张关系。如果回复的人是利益相关者或直接参与项目的人，我们觉得需要倾听，这可能尤其如此。我们需要接受这种压力是绝对正常的，试图容纳我们关心的人是人性。有时回复所有评论可能有效，但如果我们将设计批评更多地视为用户研究，我们意识到我们不必回复每一条评论，并且在异步空间中，有替代方案：

• 一个是让下一次迭代自己说话。当设计演变并且我们发布后续迭代时，那就是回复。你可能会标记所有参与先前讨论的人，但即使那也是一个选择，而不是要求。
• 另一个是简要回复以确认每条评论，如“明白了。谢谢”、“好观点——我会回顾”或“谢谢。我会将这些包含在下一次迭代中。”在某些情况下，这也可能只是一个单一的高级评论，如“谢谢大家的反馈——下一次迭代即将到来！”
• 另一个是在继续之前提供评论的快速摘要。根据你的工作流程，这可能特别有用，因为它可以提供简化的清单，然后你可以用于下一次迭代。

第二个摩擦点是临时评论，这是一种来自项目或团队外部的人的反馈，他们可能不知道上下文、限制、决策或要求——或先前迭代的讨论。在他们方面，人们可以希望他们可能学到：他们可以开始承认他们正在这样做，并且他们可以更有意识地概述他们的来源。临时评论常常触发简单的想法“我们已经讨论过这个……”，并且不得不一遍又一遍地重复相同的回复可能令人沮丧。

让我们首先再次承认没有必要回复每一条评论。然而，如果回复一个先前已讨论的点可能有用，一个带有链接到先前讨论以获取额外细节的简短回复通常就足够了。记住，对齐来自重复，所以有时重复事情是可以的！

临时评论仍然可能有用，原因有二：它们可能指出仍然不清楚的事情，并且它们也有可能代表第一次看到设计的用户的观点。当然，你仍然会感到沮丧，但至少这可能有助于处理它。

第三个摩擦点是我们可能对设计有的个人利益，如果回顾感觉更像讨论，这可能使我们感到防御性。将反馈视为用户研究有助于我们在给予我们反馈的人和我们自我之间创造健康的距离（因为是的，即使我们不想承认，它也在那里）。最终，以聚合形式处理一切使我们能够更好地优先处理我们的工作。

始终记住，虽然你需要倾听利益相关者、项目所有者和具体建议，但你不必接受每一条反馈。你必须分析它并做出你可以证明的决定，但有时“不”是正确答案。

作为领导项目的设计师，你负责那个决定。最终，每个人都有自己的专业，作为设计师，你是拥有最多知识和最多上下文来做出正确决定的人。通过倾听你收到的反馈，你确保它也是最好和最平衡的决定。

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