异步设计评审：给予反馈

反馈，无论以何种形式呈现或被称为什么，是我们最有效的软技能之一。它能够帮助我们协作改进设计，同时提升自身技能和视角。

反馈也是最被低估的工具之一。我们常常自认为已经擅长反馈，从而安于现状，忘记了这是一种可以训练、发展和改进的技能。糟糕的反馈会在项目中造成混乱，降低士气，并长期影响信任和团队协作。而高质量的反馈可以成为变革的力量。

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

在网络上，我们可以找到异步反馈的悠久传统：从开源的早期开始，代码就在邮件列表上分享和讨论。如今，开发人员在拉取请求中交流，设计师在他们喜欢的设计工具中评论，项目经理和Scrum大师在工单中交换想法，等等。

设计评审通常是一种反馈类型，旨在协作改进我们的工作。因此，它与一般反馈共享许多原则，但也有一些差异。

内容

每个良好评审的基础是反馈的内容，所以我们需要从这里开始。有许多模型可以用来塑造你的内容。我个人最喜欢的是Lara Hogan的模型，因为它清晰且可操作。

虽然这个方程通常用于给人反馈，但它也非常适合设计评审，因为它最终回答了我们工作的一些核心问题：什么？在哪里？为什么？如何？想象一下，你正在给一些涉及多个屏幕的设计工作提供反馈，比如一个 onboarding 流程：有一些页面展示、一个流程蓝图和一个决策概述。你发现了一些可以改进的地方。如果你记住方程的三个元素，你将有一个心智模型，可以帮助你更精确和有效。

这是一个可能作为反馈一部分给出的评论，乍一看可能合理：它似乎表面上满足了方程中的元素。但真的吗？

不确定按钮的样式和层次结构——感觉不对。你能改一下吗？

设计反馈的观察不仅仅是指出你的反馈涉及界面的哪个部分，还指提供尽可能具体的视角。你提供的是用户视角吗？你的专家视角？业务视角？项目经理视角？首次用户视角？

当我看到这两个按钮时，我期望一个向前，一个向后。

影响是关于为什么的。仅仅指出一个UI元素有时可能足够，如果问题很明显，但更多时候，你应该添加一个解释，说明你指出的内容。

当我看到这两个按钮时，我期望一个向前，一个向后。但这是唯一发生这种情况的屏幕，因为之前我们只使用一个按钮和一个“×”来关闭。这似乎破坏了流程的一致性。

问题方法旨在通过激发接收反馈的设计师的批判性思维来提供开放指导。值得注意的是，在Lara的方程中，她提供了第二种方法：请求，这反而提供了针对特定解决方案的指导。虽然这对于一般反馈是一个可行的选择，但根据我的经验，对于设计评审，默认使用问题方法通常能达到最佳解决方案，因为设计师通常更习惯于被给予一个开放空间来探索。

两者之间的区别可以用问题方法示例：

当我看到这两个按钮时，我期望一个向前，一个向后。但这是唯一发生这种情况的屏幕，因为之前我们只使用一个按钮和一个“×”来关闭。这似乎破坏了流程的一致性。统一它们是否有意义？

或者，请求方法：

当我看到这两个按钮时，我期望一个向前，一个向后。但这是唯一发生这种情况的屏幕，因为之前我们只使用一个按钮和一个“×”来关闭。这似乎破坏了流程的一致性。让我们确保所有屏幕都有相同的前后按钮对。

在某些情况下，此时整合一个额外的为什么可能有用：为什么你认为给定的建议更好。

当我看到这两个按钮时，我期望一个向前，一个向后。但这是唯一发生这种情况的屏幕，因为之前我们只使用一个按钮和一个“×”来关闭。这似乎破坏了流程的一致性。让我们确保所有屏幕都有相同的前后按钮对，这样用户就不会感到困惑。

选择问题方法或请求方法有时也可能是个人偏好的问题。不久前，我花了很多精力改进我的反馈：我进行了几轮匿名反馈，并与其他