异步设计评审：获取反馈

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

问题构建 (#section2)

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

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

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

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

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

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

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

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

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

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

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

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

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

迭代管理 (#section3)

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

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

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

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

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

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

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

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

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

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

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

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

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

并非所有迭代都相同。早期的迭代不需要如此紧密聚焦——它们可以更具探索性和实验性，甚至可能打破一些设计语言指南以查看什么是可能的。然后 later，迭代开始确定解决方案并完善它，直到设计过程结束并发布功能。

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

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

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

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

反馈分析 (#section4)

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

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

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

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

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

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

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

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

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

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

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

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