异步设计评审：获取反馈

“有什么意见吗？”可能是寻求反馈最糟糕的方式之一。它模糊且开放，没有指明我们真正需要什么。获取优质反馈的起点比预期更早：始于请求本身。

从提问开始接收反馈的过程可能看似违反直觉，但若将获取反馈视为设计研究的一种形式，这就合理了。正如没有正确问题就无法获得所需洞察的研究一样，寻求反馈的最佳方式也是 crafting 尖锐的问题。

设计评审不是一次性过程。当然，任何好的反馈工作流都会持续到项目结束，但这对设计尤其如此，因为设计工作会从高层次到最细微的细节，迭代复迭代。每个层级都需要自己的一套问题。

最后，如同任何好的研究，我们需要回顾所得，深入其洞察核心，并采取行动。问题、迭代和回顾。让我们逐一探讨。

问题

开放接受反馈至关重要，但我们需要精确知道自己在寻找什么。仅仅在演示结束时说“有什么意见吗？”、“你觉得怎么样？”或“我想听听你的意见”——无论是面对面、视频还是书面帖子——很可能会得到各种不同的意见，或者更糟，让每个人都跟随第一个发言者的方向。然后……我们感到沮丧，因为那些模糊的问题可能将高层次流程评审变成人们对按钮边框的评论。这可能是个热门话题，因此那时很难将团队重定向到你原本想关注的主题。

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

提出好问题的行为引导并聚焦了评审。它也是一种同意形式：明确表示你开放接受评论，以及你希望得到哪种评论。它让人们处于正确的心理状态，尤其是在他们没想到要给出反馈的情况下。

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

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

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

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

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

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

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

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

有时项目特别庞大，某些领域可能已经详细探索过。在这些情况下，明确说明某些部分已经锁定且不接受反馈可能有用。我不一般推荐这样做，但我发现它有助于避免再次陷入可能 leads to further refinement but aren’t what’s most important right now 的兔子洞。

提出具体问题可以完全改变你收到的反馈质量。批判技能较不精炼的人现在能够提供更可操作的反馈，甚至专家设计师也会欢迎只关注所需内容的清晰和效率。它可以节省大量时间和挫折。

迭代

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

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

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

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

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

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

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

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

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

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

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

为了高效讨论，你还应包括一个来自 previous iteration 的更改项目符号列表，让人们专注于新内容，这对较大的工作尤其有用，其中跟踪迭代复迭代可能成为挑战。

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

并非所有迭代都相同。早期的迭代不需要那么 tightly focused——它们可以更具探索性和实验性，甚至可能打破一些设计语言指南以查看什么是可能的。然后 later，迭代开始 settling on a solution and refining it until the design process reaches its end and the feature ships.

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

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

• 唯一——它是一个清晰的唯一标记。在每个项目中，人们可以轻松地说“这是在 i4 中讨论的”，每个人都知道他们可以去哪里 review things。
• 谦逊——它像版本（如 v1、v2、v3）一样工作，但相比之下，版本 creates the impression of something that’s big, exhaustive, and complete。迭代必须能够是探索性的、不完整的、部分的。
• 未来证明——它解决了你可能遇到的“最终”命名问题。不再有名为“final final complete no-really-its-done”的文件。在每个项目中，最大的数字总是代表最新迭代。

为了标记设计何时完成 enough to be worked on，即使可能还有一些部分仍需关注并需要更多迭代，可以使用措辞发布候选（RC）来描述它：“with i8, we reached RC” or “i12 is an RC.”

回顾

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

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

• 它消除了回复每个人的压力。
• 它减少了来自 swoop-by comments 的挫折感。
• 它减少了我们的个人 stake。

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

• 一个是让下一次迭代自己说话。当设计演变我们发布后续迭代时，那就是回复。你可能标记所有参与 previous discussion 的人，但 even that’s a choice, not a requirement。
• 另一个是简要回复确认每条评论，如“明白了。谢谢”、“好观点——我会 review”或“谢谢。我会在下次迭代中包含这些。”在某些情况下，这也可能只是一个单一顶级评论，如“谢谢大家的反馈——下一次迭代即将到来！”
• 另一个是在继续前进前提供评论的快速摘要。根据你的工作流，这可能特别有用，因为它可以提供简化清单，然后你可以用于下一次迭代。

第二个摩擦点是 swoop-by comment，这是一种来自项目或团队外部的人的反馈，他们可能不知道上下文、限制、决策或要求——或 previous iterations’ discussions。在他们方面，有 something that one can hope that they might learn：他们可能开始承认他们在这样做，并且他们可能更有意识地在 outlining where they’re coming from。Swoop-by comments 经常触发简单想法“我们已经讨论过这个……”，并且不得不一遍又一遍重复相同回复可能令人沮丧。

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

Swoop-by commenting 仍然可能有用，原因有二：他们可能指出仍然不清楚的东西，并且他们也有可能代表第一次看到设计的用户的观点。当然，你仍然会感到沮丧，但那可能至少有助于处理它。

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

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

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

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