高效的设计批评是如何进行的

注：本文译自 Running productive design critiques，作者是 Gustavs Cirults。

设计不分对错，只分适合与否。

要做到在正确的设计道路上持续产出，你需要做的是真正地去了解和探究目前需要处理的问题，并且通过某种渠道不断地获得用户反馈。获得用户反馈的渠道很多，例如使用聊天应用、发送邮件等等。但即使是设计师能够与用户进行直接对话，设计师也很容易会被自己本身的认知所限制，从而陷入设计的僵局。

和自己的同事来一场设计批评（design critique），这能很好地帮助你获得设计的新视角。在这个过程中，设计师不仅可以对想法和理念进行再一次自我探讨，一些从未有思考的设计问题也会被引出。显而易见的是，人们常常会因为一些琐碎的、不重要的事情所分心，因此在设计批评的过程中，要做到针对问题本身及所在来提出不同观点。如果同事对你所提出的的解决方案存在疑问或者误解，这也未尝不是一次对设计进行反思和解决的机会。

我们（指 Intercom 设计团队，下同）一直在对自己的设计进行批评，在本篇文章中，你将了解到我们是如何进行设计批评的。我们也有一套对此适用的 Sketch 模板，在这里与你一起分享。

确定设计批评的目标 #

在展现设计案例前，确保每个人都清楚地了解问题本身与所在。 进行设计批评，将需要 1-5 人对问题提供不同视角（如设计师、工程师、服务支持代表等）。在开始设计批评前，确定批评的目标并对他人提供指引是至关重要的。你需要做些什么改进才能推动作品进步？需要哪种类型的、针对哪些问题的反馈呢？一场合理的设计批评，应由设计师自己进行领导和指引，帮助同事（或其他提供不同视角的角色）理解问题的复杂性，或正确的思维过程，并一起确定设计和批评的目标、目前需要解决的问题，以及可能需要的解决方案。

在这方面，可以把问题的描述和提出的解决方案打印下来，贴在墙上供大家参考使用。这能让每个人都理清整个设计作品与问题的关系和解决的程序流程，并且提供针对性的观点。至此，你将永远与「你能滚动回上一张设计页面吗？」「不对，是另外一张」这些原型测试中可能出现的问题说再见。不过在我们需要讨论交互上的设计时，原型测试（interaction design）仍是一个不可或缺的环节。

Set the scene 做好开始前的准备 #

在展现设计案例前，确保每个人都清楚地了解问题本身与所在，以及问题出现的前因后果。如果问题没有了解明白，对设计案例的批评也会出现偏颇，在过程中也很容易出现误解。因此，请针对性地给问题起一个名字，用较小的篇幅（最好是一段话）简洁明了、通俗易懂地描述问题。下面是一段示例：

Inviting colleagues Only 5% of new sign ups invite their colleagues in the first 7 days. We’ve seen that users who invite their colleagues tend to be more active and stick around longer.

如果问题能够以可视化的方式呈现，通过绘制图表或者使用案例的 screenshots 是不错的选择。（我们用 Job Stories 了解用户的动机，也推荐你采用。）

让批评人员团队参与进你的解决方案 #

当大家都以同种方式思考，并充分了解正在尝试解决的问题时，是时候提出你的解决方案了。在理想情况下，你可以给不同方案标上序号，这有助于人们对方案作出批评、同时了解方案间的异同及方案适合与否的原因。

不仅仅问题需要 set the scene，所给的解决方案同样需要。针对性地给方案起一个名字，用较小的篇幅（最好是一段话）简洁明了、通俗易懂地描述方案，便于大家参考。

在开始绘制 UI 细节前，制作一个关于解决方案运作程序的图表能够起到不错的作用，特别是在设计和优化一些互联产品（interconnected products）时（如 Intercom），用一张高层次的关系图，对设计的运作系统进行描述是必不可少的。

再继续，用打印的形式或通过原型向他人阐述，来展示你所提出的界面设计。

最后，心狠手辣地分享你针对每个方案的看法，提出仍然需要解决的问题。（如果有）

进行有效讨论 #

在参与批评的人员都了解问题和你的解决方案时，开始进行有效讨论（productive discussions）。可以从你的看法说起，为什么这个方案能够脱颖而出？脱颖而出的依据是什么？对参与人员进行引导性解释说明，点到即可，最主要的还是收集他人的批评意见。肯定的是，讨论人员会有不同的意见，在其围绕某一方案进行争论、或者认为没有最佳方案时，认真聆听，思考如何能够进一步深入改善。

要牢记的一点是，脑海中要保有这次设计批评最初的目的和目标。有时候你获得的反馈似乎并不是自己所需的：例如，你想获得有关特定交互的反馈，但人们会问：「为什么先做这个？」这是需要我们进行思考的问题，「我为什么要获得关于这个问题的反馈？」、「进行这次批评的目标是什么？」。始终明确自己的目的和目标（当然目的和目标本身要足够有效、确切），并在设计批评的过程中不断提醒自己。

但如果你只是想弄明白某种系统的运作形式，但获得的反馈始终纠结于在这个系统上交互的一些细节，及时告知参与批评的人员「跑的有点儿偏」，在明白系统运作形式前开始掐交互细节，未免过早了。告知的同时，发挥作为设计批评发起人的作用，对批评（conversation）进行指导，引回先前所需他们提供反馈的批评主题。

批评从未结束 #

取决于这次设计批评定下的目标，你或许能够提出具体的决策及决策理由，亦或者关于设计本身的想法可供消化吸收。但一定做好具体的后续工作，这是最重要的一点。我们在进行设计批评时，将讨论得到的成果写在 Slack channel #design-notes 上，确保没有将其遗忘，同时能够允许非设计小组内部成员的用户提出反馈。

定期进行有效的设计批评可以产生非常大的作用。有趣的想法一被提出，其他人就可以以这个想法为基进行延伸拓展，再与不同的各个延伸进行连接。单凭设计师一己之力（哪怕这个设计师有三头六臂），可无法创造这样卓越的效果。

为了简化这个过程，我们制作了一个 Sketch 模板，在这里与你分享，现在就可以下载，并试着在下次展开设计批评时使用。如果该模板能够帮助到你，记得告诉我们！