在整个设计过程，反馈是一个关键的组成部分，本文为管理者和团队领导提供了一套设计评论基本规则，具体使用要根据实际情况来进行修正。

反馈是整个设计过程的关键组成部分，因此它需要的不仅仅是一些好的遵循的指导方针和最佳实践。一个礼貌的提醒，遵守适当的批评礼仪，并没有切断它。为了充分利用反馈会议，管理者和团队领导需要为设计评论设定基本规则。

与设计生命周期中的任何其他步骤一样，涉众反馈会议应该具有相同的严密性、一致性和勤勉性。即使是一个单一的设计评估，正确的意图，有潜力，推动设计从好到伟大。不幸的是，设计批评常常受到不明确的期望、不明确的议程、缺乏重点——或者对周边问题的不适当的专注——不受控制的偏见、不恰当的观点、不恰当的声音的干扰。

要使设计批评会议富有成效和有价值，唯一的方法是在团队之间清晰地交流和社会化设计批评的基本规则。每当涉众和用户体验设计师聚集在一起对一个新版本的设计进行评估时，你应该提前提醒每个人注意基本规则。

这样，你可以确保团队的注意力不会从设计转向设计师，从经验主义到个人独断独行，或沦为个人扩张的牺牲品，而不是围绕集体努力。

本文提出了一套给出和接收反馈的基本规则。当然，您可以根据团队的环境、文化和化学要求对其进行剪裁。

首先，反馈的接受者和分配者都必须坚持作为这些基本规则基础的四个重要的批评：

1. 尊重。虽然它是好的队友不同和不同意，每个人都必须保持最大的尊重和敏感性，对彼此。假设房间里的每一个观点都来自最好的意图、智力、专业知识和经验。永远不要贬低或轻视任何人的意见。

2. 责任。涉众是反馈会议的一部分，因为他们对满足用户的需求负有共同的责任，交付最优的设计解决方案，并作为一个团队来交付业务结果。为了最好地履行这个责任，每个人都必须保持开放的头脑，关注设计师展示的解决方案和随后的讨论，并提供建设性的想法和建议。

3. 正确的意图。队友必须为正确的理由提供批评——设计师必须以优雅的姿态接受他们，使设计解决方案更好地为用户服务。给每个人提供反馈的机会。任何人都没有机会展示他的天才或发泄他的感情。

4. 反思。反思反馈会的真正焦点：问题、上下文和用户。团队应该意识到，会议不是关于他们的能力、声音或个人偏好。

接收反馈的基本规则

在设计回顾的背景下，用户体验设计者几乎总是呈现设计，并且是反馈的接受者。因此，他们有责任提醒利益相关者关于建设性批评的基本规则。

规则1：传达基本规则

在反馈会议的一开始就设置正确的语调，外交地但权威地传达基本规则，然后再钻研你的演讲。用演讲的第一张幻灯片写出基本的规则。它们应该是简洁的，可浏览的，一目了然的理解。你可以是有创造力的，视觉的，甚至是机智的表现他们。如图1所示，第一个幻灯片可能包括四个批评，提供反馈的基本规则：

如果任何涉众对团队来说都是新的，那么这个项目刚刚启动，或者这是一个初步的设计评审会议，那么您可能需要快速解释基本规则。否则，最好暂停几秒钟，让每个人都浏览一下基本规则，然后再继续。

规则2：尽早设定预期

在开始展示线框图或原型之前，设定一些期望值，如下：

让人们知道你何时以及如何接收反馈，例如，在会议结束时或在会议进行过程中。让他们知道他们在任何时候打断你问问题或寻求澄清是否合适，或者你会在特定的时间间隔停下来允许他们这样做。

清晰地描述设计的阶段，例如，初始阶段、中间阶段或最终阶段。另外，他们可能会认为设计是早期和流动性，所以建议在游戏后期的大变化。

如果您正在呈现设计的修订版本，请列出在修订历史中已经进行的任何更改。提到谁审查了设计和谁提供了反馈。如果房间里有人提供了意见，提醒他们说，更重要的是，你要重申这是集体的努力，而不是个人的努力。

图2中所示的幻灯片实现了所有这些目标。

您还可以在设计批评会议之前共享这些信息，方法是将其包含在会议邀请函中。

规则3：重新创建上下文

详细说明设计的业务目标。分享人物角色，提醒每个人你正在为他们设计解决方案。强调高级别的用户需求和使用上下文。重申您在创建设计时考虑到的时间框架、技术和业务约束。

另外，谈论任何最近的研究，需求变更，或者新的信息，这些信息已经影响或者需要对设计的变更。这似乎是一个重复或多馀的步骤——特别是如果您经常进行反馈会议。尽管如此，至少花几分钟来做这件事已经成为了习惯。许多涉众都参与到多个并发的项目中，因此很容易使他们失去对上下文和背景的跟踪。快速复习可以帮助他们保持正确的观点。

规则4：从用户角度描述设计决策

永远保持你的用户的正面和中心。在浏览你的设计时，从相关人物角色的角度进行解释。

不要用你的个人想法或感觉来表达你的设计决定。例如：“我宁愿把这个按钮放在右上角。”“我觉得这是最好的选择和编辑方式。”相反，要围绕用例和场景来制定你的设计决策。

场景是涉及人物角色的简短故事，它们建立了使用的上下文。例如，“约翰在处理工资单。他的最后期限快到了。他正在使用我们的系统来创建新的工资项目并编辑现有的项目。”

用例是用户为实现某个目标或期望结果而可能承担的特定的、逐步的任务。以下是几个例子：

用例1：“John想要创建一个新的工资项目。步骤1：他单击new按钮……”

用例2：“约翰想编辑现有的工资单条目。步骤1：他显示工资单。步骤2：他选择入口。步骤三：他点击编辑图标。…”

规则五：解释，不要辩护

没有必要为你的工作辩护。如果你发现自己这样做了，有意识地检查自己。设计师有时会被他们所创造的设计所吸引，这可能会妨碍他们对新的想法和建议保持开放。

记住，设计是一个集体的努力。确保每个人都知道这不是你的设计，而是我们的设计。如果有人有更好的主意，就对它敞开心扉。不要防守。保持中立，用简单的分享来解释你的设计决策。

• 为什么用户可能需要或想要这个解决方案？
• 你还考虑过哪些其他选择？
• 谁或什么影响了决策——例如，竞争对手评论、涉众、专家输入、标准或用户体验研究

规则6：一定要记笔记

使用你的电脑，白板，或一支笔和记事本捕捉每个人的反馈。重要的是要做清晰的笔记，让你的听众知道你正在这么做。每次有人提出了相关的观点，让团队知道你已经注意到了。这使他们放心，你正在认真地对待他们的反馈。当然，接受或丢弃某些反馈是你的特权，但不是没有给予适当的考虑。

尝试捕捉重要的洞见、问题或关注点，并赋予其特征，包括任何偏离主题而需要稍后讨论的内容。如果有必要，你可以让每个人等一会儿，这样你就可以写下一个笔记了。在反馈会议之后，与团队分享你的笔记以避免“他说，”她说“或者模棱两可”。

图3显示了一个建议的记事模板。

规则7：不要只接受表面价值的反馈

勤奋地记录下所有的反馈，不立刻拒绝任何东西。然而，在必要的时候，你应该恭敬地要求澄清或质疑批评背后的基本原理。稍后，这可以帮助您决定是否以及如何将反馈合并到您的设计中。如果反馈是模糊的，基于个人偏好，与你的一般思维方式相矛盾，或者可能会对设计产生相当大的影响，那么这一点尤其重要。

询问细节——例如：

• 能否请您详细说明为什么您认为这是比目前的建议有所改进？
• 请你告诉我，约翰，我们的目标人物，将如何受益于这变化？

你所建议的改变也会影响设计的其他部分。你认为做出这样的改变是值得的，让所有这些其他级联的改变？

你的建议和我对这个设计的看法有很大不同。[解释它有何不同。]只是为了让我更好地理解这个变化的价值，请告诉我为什么你认为我可能错了？

再次，通过友好的双向对话，以恭敬的方式进行提问。一旦你注意到一个建议背后的基本原理并告知你将考虑它，马上停止讨论。在任何时候，这种谈话都不应该变成一场激烈的来回的争论，也不应该成为一场关于一切的讨论。

但是，如果某人的反馈是有争议的，或者与你最初的思路相冲突，请其他涉众参与进来。看看多数人怎么想。如果你强烈地感觉到反馈是错误的，要求一些时间来反思它，然后寻求利益相关者的共识。如果可能的话，与提供反馈的人进行离线的讨论。有时一对一的谈话要比在试图解决有冲突的观点时进行小组讨论好得多。

规则8：积极管理反馈会议

在设计评审期间，你必须戴多个帽子——演示者、记事本和主持人。

最终，这些会议直接有益于您的工作。因此，确保会议井然有序和富有成效，符合你的最大利益。主持会议的责任在于演示者——他通常是用户体验设计者。确定您正在寻找的反馈的格式和焦点。决定邀请哪些涉众参加会议以及在设计的哪一阶段。

超过六、七个人的大型团队缺乏设计评审所要求的亲密感和专注力。因此，将邀请列表缩小到那些在特定阶段对设计过程至关重要并且最有可能提供有意义的反馈的涉众。

在反馈过程中，确保每个人都保持参与。礼貌地要求人们集中注意力，如果他们变得分心或多任务。如果某些声音主导了谈话，干预和鼓励其他人也表达他们的想法。如果人们很安静和被动，在桌子周围，以确保每个人都参与进来。如果你需要一个特定的个人对某一问题的观点，它是好的问一个直接问题的那个人。

如果太多人同时发言，有些人在进行侧谈，或人们表达相互矛盾的观点，可以随时提醒该团体一次表达自己的观点，这样你就可以记录他们的反馈并确定他们的优先顺序。适当地记录每个人的反馈有助于你正确地看待问题并反思问题。

提供反馈的基本原则

提出设计的用户体验设计者并不是唯一在反馈会议上有利害关系的人。参加反馈会议的涉众有同等的责任对解决方案进行权衡，并提供建设性的、可采取行动的反馈。他们必须遵循给出反馈的基本规则。

规则1：在熟悉背景和背景之前避免插嘴动作

对你不完全理解的东西发表评论是有风险和不负责任的。作为一名设计评审员，您必须坚持为您所评审的内容获取上下文和背景。即使您认为自己理解了上下文，也要询问自上次审阅会议以来是否有任何更改或是否有任何新信息可用。您需要注意以下几点：

• 相关用户角色；
• 主要利益相关者或中小企业的投入（专题专家）；
• 主要限制、挑战或阻碍因素。

规则2：专注于为什么

当回顾设计时，如果你发现一些错误，在没有理解其背后的原因之前不要做出反应。请设计师解释一下这个设计决定背后的原因。不要简单地认为那是由于缺乏应有的思想、疏忽或无能。

用问题的形式表达你的关切。“请解释为什么你选择在这里使用下拉列表而不是单选按钮。”这使设计师有机会澄清是否有合理的理由作出这一决定。这种办法鼓励进行开放式讨论。另一方面，“我认为你应该在这里使用单选按钮”，这听起来可能是指令性的，让主持人处于守势。

规则3：戴上你的用户帽

当你回顾一个设计的时候，把你自己放在用户的位置上。这有助于减轻你的偏见和与你个人偏见的距离。对自己要保持个人好恶。相反，要根据用户使用解决方案完成其任务的难易程度来判断设计。如果您对用户、用户需求和使用的上下文了解不够，请一定要询问他们。

即使您是从特定的专业领域——例如，业务、开发、内容或合法领域——对

设计进行评审，也要始终将用户放在最前沿，并确保将您的反馈与对用户最有利的内容保持一致。

规则4：让反馈更有意义

对设计师来说毫无用处的反馈包括这样的评论：“这看起来很奇怪。”“我不喜欢这个。”“我不喜欢这样。”这样的陈述缺少两个关键的信息，这些信息可能会使它们变得有意义和可行。

• 背后的原因-而不是个人偏好。
• 哪些方法可能会更有效？

在提供反馈时，始终将其与逻辑的、客观的需求联系起来。例如，用户或业务需求、标准、约定、可用性、用户体验或技术或法律约束。

此外，试着举一个例子，什么可能是合适的替代。如果您没有现成的示例，请在以后提供。或者要求设计师和其他利益相关者参与到可能更好的工作中。

如果你的评论是基于一个主观的观点，承认这一点，并敦促设计师做一些测试，以确保它不是一个问题的用户以及。

规则5：避免只关注消极方面

设计评审不仅仅是寻找设计的缺陷。他们还提供了一个机会，以加强什么好。这有助于为未来的设计建立更好的标准和基准。积极的加固也使并鼓励设计师始终朝着正确的方向前进。正面正面的强化也有助于设计师不那么防御性和更开放的建设性批评。

在提供反馈时，如果可能的话，先指出积极的一面，然后再指出消极的一面。突出什么工作得好加强了什么工作和什么不工作之间的对比。这使得设计者更容易识别设计的缺点。

规则6：考虑后果

有时候，你建议的一个看似简单的改变也许并不那么简单。例如，建议移动一个按钮在一个页面上的位置，可能会引发在许多页面上进行类似的更改以确保一致性的需要。或者您向用户流添加一个简单的附加步骤的请求可能会在后端打开一个由技术约束组成的潘多拉盒子。

通常，用户界面上看似很小的变化都会引发一系列的相关变化。所以，不要认为任何建议的改变都是琐碎或简单的。问问设计师和其他利益相关者，他们是否认为这可能会导致任何并发症。意识到你所提倡的潜在的巨大的变化可以帮助确保你的反馈是平衡的和实际的。

规则7：注意你的语气

时刻注意你的评论或反馈的语气。你的语气暴露了你的意图——不管是建设性的还是支持性的，还是轻蔑的和轻蔑的。例如，考虑下面两个评论的不同语气：

“我不知道你为什么在这里使用下拉列表。单选按钮会工作得更好。”

“你能帮我理解你为什么选择了一个下拉列表吗？你不觉得收音机的按钮可能会工作得更好吗？”

第一个评论有一种判断性的，僵硬的语气。它对设计者的智慧提出了质疑，并给出了解决方案。另一方面，第二条评论，虽然让你的偏好充分清晰，却给解释和公开的讨论留有馀地。

规则8：知道如何推进争论

有时设计师不会很好地接受你的反馈。他们可能提出相反的论点，可能会说服你改变你的想法，也可能不会。即使在你做出了合理的尝试后，设计师也可能会钻研并拒绝你心目中的临界点。那你该怎么办呢？有力地争论直到你如愿以偿？表现出没有被听到你的不悦？静静地接受现状？

的确，争论没有赢家。所以，即使你赢得了一场争论，你也有可能失去设计师的好感，破坏你们的关系。不满或沉默同样会适得其反。所以要确保设计师记下你的反馈。这提供了一个文件线索的讨论和可能性，团队可以探索的设计方案，你已经建议在未来。

通常，最好的方法是询问其他利益相关者的意见，看他们是否同意或不同意你。或者，您可以要求与设计人员进行一对一的讨论以跟进。有时，人们在亲密的交谈中比在一个充满人的房间里，对新思想更开放、更容易接受。

如果您认为在设计中没有考虑或纳入您的反馈可能会带来潜在的风险，那么标记问题，记录您的反馈，并与其他涉众分享，甚至将问题升级到组织的领导。

结论

大家理解设计批评的重要性，并遵循这里概述的基本规则。

优秀的设计评论可能会给优秀的设计带来启发和启发，然而，如果一个设计评论缺乏结构或礼仪，它可以退化成空洞或痛苦，这对团队和用户都是有害的。因此，给设计批评以应有的评价是绝对重要的，在帮助他们的时候，要确保每个人保持正确的严密性和遵循这些基本规则。

本文由 @小光蛋 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议