设计评审是每个设计文化中关键的一部分，也是不同设计团队少有的共有的设计仪式感之一。设计评审如果做得好，可以通过利用团队成员每个人独特的优势去提升单个个体的工作质量。评审应该让你受到启发，挑战，以及给你赋能。然而在实际情况中，结局不是一直朝这个方向发展，差的设计评审会让你的团队泄气，不知所措，甚至失去方向。在过去的一年中，为了避免踩这些坑，我们在 Figma 对设计评审的方式做了很多改进。
我们相信评审应该是鼓励人的而不是吓人的，应该是让人鼓气的而不是泄气的。它应该是好玩的并且让设计师为之期待的。如果你的团队没有这样的感受，现在是个很好的机会改变现状了。
我们常常忘记真正能和一群有能力的人协作是多么大的一个优势。重复的做设计评审是激励团队成员更好的协作的基本方式之一。如果一个会议没有好的产出或者氛围让人感觉不舒服，我们可能觉得这个会白开了，所以开好设计评审会将成为设计文化和品牌塑形，同时也极大的影响之后怎么招兵买马和留住人才。
在这篇文章里，我会分享在 Figma 大家如何一起让设计评审变得有趣，而不是让人感到害怕。
在 Figma 主持设计评审一年多之后，团队决定聚到一起聊聊对于设计评审这个东西我们在什么地方做得好，又在什么地方没做好。于是我们从检视设计评审本身开始，最后我们收集到了这些反馈：
- 会议室太挤
- 反馈过于浅显
- 在短时间内问题过于复杂
- 反馈不可行
- 很多附和
- 大家说好话多过于诚实
- 总体来说，并没有帮助到解决问题
我们把所有这些反馈放在了 Figma 文件里面，然后给它们分门别类。
于是有趣的事情发生了。在会议中，大家开始接连的提议各自的方案。
到底是什么情形会让大家更加放松并且富于创造力？是因为竞争较小？又或者是因为没有单个个体感觉到自己受到个人攻击了？无论是什么，我们能在一起好好地工作这感觉太好了。通过确定会议室里什么是积极的走向，并且承认它，那我们就知道目标在哪了。
我们认识到一次讨论不能解决所有的问题，这必然是一个持续的过程。我们建了一个在 slack 叫「#design-crit-crit」 的群一起保持迭代。尤其是当我们的团队成长，我们要解决的问题的类型在变化，我们希望保证流程也一直在随着公司的成长而进化。
△ 来自#design-crit-crit群里持续不断的建议
在任何好的设计流程里面，我们首先必须明确评审的目标。只有这样我们才能去衡量这个会开完了我们是不是拿到了我们想要的。我们决定做这些：
- 疏通问题，产生想法。很多时候设计师在解决一个问题很久之后发现被困住了，然后才发现利用团队的力量，一些错误完全可以被避免。其他时候当你刚刚开始解决一个问题的时候就开始向团队收集想法，他们有可能已经想过这些。
- 提升质量。所有事情从视觉设计，到交互细节，或者整体的产品方向。
- 鼓励一致性。我们希望尽可能的沿用已有的设计模式，或者在需要新的设计模式的时候及时的提出来。
- 分享情境。设计团队相比其他团队较小，比较容易了解到公司里面大家都在干什么。这样能让大家了解项目之间重叠和连接的部分，而其他部分可能没那么容易获取这些信息。
值得注意的是设计评审不是用来去 「做主要的产品决定」 或 「决定产品路线图」。团队应该有另外的定产品路线的流程去决定产品的方向。评审需要给探索和反馈提供充足的空间，并且独立于做路线图决策背后的压力。
终极意义上说，评审存在的意义是帮助设计师寻求支持和帮助。从这个角度来说，使用什么样的方法就取决于设计师自己。剩下的团队成员只需要准备好提供帮助就好了。
明确好目标后，我们准备了下面这 6 种不同的设计评审方法，每一种都有他们独特的优势和目的。取决于使用什么方法，它们可以是一个小时的会议（通常两个话题，每个20-30分钟）或者小一点的会议。除了纸质打印的例外，所有这些方法同样适用于远程团队。
1. 标准式（Standard）
标准形式。提供情境，收到反馈。
最佳时期：你希望大家理解项目背后的情境，并且向它们介绍你的想法。你能够接受一些讨论，最好是你清楚自己具体在找什么样的反馈。
准备：在大家走进来之前或当大家走进来的时候，将便利贴和笔放在椅子上鼓励大家在会议过程中把想法写在纸上。
第一步：分享情境和反馈内部化（约10-15分钟）
在会议开始的时候，先解释项目的情境（如果大家对该项目不熟悉的话）。为什么重要？目标是什么？项目的目标是项目的基础，如果大家错过这个部分，收到的反馈可能会走错方向。然后向大家说明你偏好的提出问题的时间，随时打断还是结束分享后。另外准备好一页幻灯片专门显示「这些是我想要找的反馈」，相反的「这些不是我想要找的反馈」，这样会让讨论更有针对性。提醒大家在你过内容的时候把想法写在纸上。
相比于在大屏幕展示，我们经常给每个人发一个 Figma 的链接去让它们打开「围观模式」（Observation Mode）。我们发现这样子更容易看到设计细节，对于远程参与者极其友好，网络链接也更可靠，比大多数屏幕共享软件更适合于高帧率分享。相比于查看大屏幕展示，用户在 Figma 文件里随意浏览有些小的风险，但是我们也发现有时候这样做有个好处就是如果有人错过了什么，他们不用因此让整个会议因此暂停。
第二步：澄清问题（约2-5分钟）
当你完成展示后，保留几分钟让大家随意提问。这个非常重要，因为如果一个人对某个点很困惑，很有可能其他人也是。所以在大家开始提出反馈前，阐明问题，解除疑惑，确保每个人都在同一个频道。
第三部：收到反馈（10分钟+）
我们有两种相当不同的方法用来在会议中收反馈。
轮流式 Round-The-Room（RTR ）：挨个询问会议室的人，让每个人都有机会发声，并且试着控制给每个人的时间在两分钟之内。不建议其他人打断，如果他们有一些想法急于表达，鼓励他们写下来等到轮到他们的时候再表达。这样的形式对于不适应在公众面前表达想法的人特别重要。有了这种组织好的形式，收集的反馈会对不同人和不同的偏好更具有包容性。
爆米花式 Popcorn──自由讨论。我们叫它爆米花的原因是各种意见会从各处不可预知的冒出来。这种自由式的讨论更加即兴，大家可以随时加入讨论说「是的，然后…」 我们通常会在时间有限的时候使用这种爆米花式的评审方式。我们会说「有什么你觉得关键的东西要分享的吗？」 然后我们之后会把这些意见文档化。请注意这种方法可能会因为其中一个人的意见特别鲜明而影响整个的包容性。为了对抗这种情况，我会鼓励大家去请没有发过言的人表达下意见（如果他们想的话），或者当讨论有些倾斜于一方的时候人为加以控制一些。
当你收反馈的时候，试着不要太具有防御性或一直辩解。最好是直接简单的表达对对方的反馈的感谢。你不用立即回复每个人提的建议，先花点时间想想他们要的是什么，然后回复他们。
第四步：感谢和跟进（1分钟）
不要忘记感谢大家，同时让他们知道如果他们想到别的意见怎么样告知你。发在 slack 上面？还是发给你一个文档？通过 Figma 文件？你有空和他们单独面对面吗？如果有，什么时间？你也可以让他们去想什么时间，这样可以过滤出非常想给你反馈的人。我更常倾向于让贡献反馈的过程非常简单，因为他们的意见通常非常有用。
2. 设计果酱/工作坊 (Jams/Workshops)
头脑风暴，Crazy 8’s，情绪板，草图等等。
最佳时间：项目早期。可能你希望尽可能多的吸收其他人以前已经想过或者探索过的见解。可能你想在缩减思路范围前尽可能的发散思路和探索更多的可能性。因为如果早期让整个团队一起参与讨论，不同的视角和技能树常常能启发全新的概念，会帮助避免视野过于狭隘。
怎么做：做头脑风暴的方法很多。如果你使用纸张，我个人推荐 crazy 8’s 方法。我们最喜欢在 Figma 里面执行。最近个有趣的例子，我们有个设计实习生叫 Andrew Shen，把我们一群人弄到一个房间去研究他的暑期项目──Figma 的评论功能。
Andrew 把 Figma 文件丢给我们，然后让我们回答几个提示性的问题。像是 「评论功能目前最大的问题是什么？」 「我们喜欢什么样的评论体验？」 「关于这个评论功能应该如何表现，你有什么主意吗？」 「应该更像邮件还是Slack？」然后我们就开始忙活了。
我们集中精力弄了半个小时然后开始往里面丢各种参考，文字片段，或者任何其他的东西去传达我们的想法。这个集中比一个简单的调查或者投票要深刻的多，因为你可以实时的看到其他人的主意，然后也可以互相借用。这些事情做完后，我们开始在屋子里和其他人交流想法，如果有需要，澄清令人困惑的部分。在短短的一个小时内，Andrew 集合利用了一个屋子六个人的脑力，当开始去画出一个想法的时候也有了很多可用的材料。
Andrew 的 Figma 文件不需要很多准备和主持，仅仅只是几个带着问题的画板，然后我们就可以在上面忙活了。
3. 结对设计
2-3 人的小组工作。
△ 注意：从左往后数第二个人是客户，不是Figma雇员
最佳时间：这个方法可能需要更多情境和深度的了解。有时候很难一次性的让大家聚在一个屋子里面想所有事情，所以组织 2、3 人去参与会更加有效率。
所以至今最受欢迎的相替代的方法，结对设计变成了在 Figma 的流程中一个订书针。过去有一阵子每个周我们会严格的使用这种方法去专门做一次评审，每次评审会议开始前，我们把大家分成少于三个人的组去解决问题。
因为我们不希望强迫大家使用一些他们没准备好用的方法，我们不再强制要求每周去用一次这个方法。相反的，我们开始鼓励设计师根据需要去计划做设计评审。现在，大家直接会在 Slack 群里面喊一嗓子 「谁有空搭档啊？」，然后一起把这个提上日程。
我们另一个鼓励频繁结对设计的方式是分配一个搭档给每个项目的主设计师。在 Figma 这样的创业公司，我们设计团队很小，没有足够的设计师去让一个项目有多个设计师全职管着。我们发现即使只是分配一个设计师的一部分时间去和另一个设计师搭档合作，也会让设计师感觉不再是孤军奋战。这种方法没有很完美或者很一致，对于很多项目我们或者忘了分配一个副驾驶员，又或者大家就是太忙没空。随着我们的成长，我们希望让这个进一步的标准化。
结对设计也不是什么新鲜事了。工程师结对编程去调试和找到错误。我们往过去追溯下，犹太教领袖强迫学生在一个叫学聚的流程下找学习搭档。这是一种学习塔木德的方法──小组分析，一起辩论文字：
学聚的关系给每个学生向他们的搭档澄清和解释地位的平台；然后两个人继续提问，辩护，说服，修改，完善，甚至通过严谨的智力协作得到完全不同的结论。
Nathaniel Deutsch 教授围绕着这个历史场景，讲了一个很棒的关于结对练习的益处的课。如果你有兴趣，可以点进链接了解更多。
然后如果你想继续讨论结对设计，我会建议你去找 Stephanie Engle，她对此思考过很多，在她工作于Cruise和Facebook的时候，结对设计相当有用。
4. 静默评审
禁言，并且给出数字化的反馈。像是参观艺术馆，除了馆员可能说明艺术品的背景，其他人一般不会有口头讨论。
最佳时间：当你需要大体量的反馈，又或者你在远程工作。
想象下一群人在一个会议室里面完全沉默不语一个小时，这个似乎有点好笑。我们第一次得到这个想法是因为我们一个叫 Niko 的设计师读了静默会议宣言这篇文章。在这篇文章里，作者 David Gasca 对于典型的公司会议感到非常沮丧，然后他提供了一个替代方法：
「静默会议」是一种大部分时间大家都在思考并且通过书写的方式讨论手头的话题的会议。具体是会议上的每个人不读出声，然后通过书写的方式提出观点并且讨论。──David Gasca
基本上规定成一次只能一个人发言，其他人全当倾听者。静默会议不依赖于口头表达，提供了同时有多条谈话的线路，这样呼声比较高的反馈可以在短时间内有效地被收到。
对于发表反馈的人，他们可以按着他们自己的节奏走，这样便于做一些更深入性的思考。对于接受反馈的人这个事情会变得累人的同时又让人特别振奋。Niko 在德国远程工作，他经常觉得需要花上半天的时间去处理大量的反馈。可能最开始会有点压力，但是随着时间的推移能够迸发很多新想法。
为了有效的同步信息，静默评审需要更多前期的准备工作；观众需要能从文档中获取必要的情境。这种方式对于远程工作者尤其行得通的另一个原因是，他们希望从有限的交流机会里面尽可能多的获取信息。
你也可以通过在 Slack 群组发送即时消息去完成静默评审，但是我们发现设定好一个时间或者面对面的执行这个的好处是保证参与者确实有去仔细查看被评人的工作。
△ 最近在Figma执行的一次静默评审的缩时摄影
5. 纸面评审
将要评的东西打印，然后贴出来。
最佳时间：当你拥有大量的想法，而这些想法很难在单个文件里浏览时，又或者当你想要鼓舞大家不要受屏幕上的像素点限制的时候。
不管你相不相信，设计师曾经没有电脑用来去执行评审。不敢信吧？有时候我们忽视了和实物打交道的价值，习惯了一整天都盯着屏幕，导致觉得评审理所应当的也应该在显示屏上进行。但是鼓励大家站起来，四周转一转会大有裨益，这样想法可以更自由的流动，不必受到像素点的限制。
如果你像我一样去过上过设计课，你一定记得在那个时候，教授会把所有学生的作品挂在泡沫板或者软木墙上，然后教我们怎么做评审。有时候他们会拿个红笔到处写上注释，然后讨论什么做得好什么做得不好。在我过去十年的产品设计经历中，只有极少次我在的设计团队试过这种方法。相反的，大多数时候我们坐在离屏幕 6 米多远的地方参与评审。
Jenny、Rasmus和Marcin，他们三个在 Figma 的产品设计师，尤其支持让我们远离桌椅和显示屏，回到最基本的方式。这种方式可以和前面提到的「标准式」很类似，只是变成了我们围在打印的作品面前，用贴便利贴的方式给出反馈。
基于这种方式不适用于远程工作者，我们会选一个记笔记的人，录下整个会议，同时也会拍下图像记录。如果参与者能实时加入，我们会准备一个附加的 Figma 文件（因为已经需要准备一个 Figma 文件用于打印，所以这个不会额外花太多时间）这样远程参与者也可以加入他们的想法。甚至可以让记笔记的人将远程参与者的数字笔记转成物理的笔记。
因为事实是我们最终还是需要把反馈给电子化，所以最终我们每个月用的不到一次，但是时不时的举行一次也让我们觉得是个很好的机会去从日常的工作中跳脱出来，长远来看也打开了我们对话的空间。
额外的好处：当涉及到和办公室内其他部门的人沟通时，这种方法附带的好处是让分享情境和激发想法变得更加轻量。如果可以的话，在会议之后，把工作内容先放在一边，或者如果东西被贴在泡沫板上面，你可以把它移到在办公室更可见的地方。当你下一次看到有人站在泡沫板面前，和他们聊一聊然后问他们在想什么。通过这样的方式可以让问题得到更多随机的曝光，说不定会有一些意外的收获。
6. FYI
项目中快速的分享情境。不需要反馈。
最佳时间：当你不确定大家是否看到你在 slack 里面发的「我在做新项目哦！」消息，借此机会告知大家你正在干嘛。
不得不承认这种方法是六种方法里面最少见的一种，但是有时候我们会分出五分钟的时间让想要分享他们在做的事情的人。在这种情况下，反馈不是必需的，但是你希望借此机会放出触角，去发现或许同伴已经探索过的一些方向，又或者了解下有没有其他设计师对这个感兴趣想要之后聊一下的。这是一个找到评审目标最简单的方法──分享情境。
这里我列了一些我们在 Figma 执行任何评审方式都通用的一些技巧。
1. 对症下药
准备多样的方法，并且设定好相应的名称，方便称呼。提前想好哪种方法对于手头的问题最为有效。困在某个问题中或某个 UI 难题了？试一下「即兴讨论」。开始一个新项目了？试试「工作坊」。评价多个选项？试试「站立评审」。致力于一个尤其复杂的问题？试试「结对设计」，去深挖问题。
2. 提早确定评审时间
在周一早上之前将评审时间定好，然后在会议日历里面阐明会议大概的内容。这样有助于给设计师一个小的截止日期，然后也便于尽可能让你认为重要的参与者能够最终参与进来。
3. 使用小会议室
我们觉得小的会议室容易营造一种舒适的氛围。会议室都被占用了？凑在一个人的电脑前或者大家坐在椅子上围成一圈也可以。又或者去一个咖啡店。总之尽量避免使用太大的会议室形成那种企业董事会的感觉。
4. 购买一个计时器
我们使用 60m 的计时器。试着保证每个话题都使用计时器，作为主持人，尽可能记录每个话题持续多久，进而在未来更好的计划时间。如你所想，每个话题都会比大家预想的至少多花上十分钟，因为我们最近开始每个一小时的评审最多允许两个话题。
5. 记录笔记
我们尝试不同的方法让因为各种原因（时差，假期，病假，或任何其他原因）没办法加入会议的人了解会议的情况。比如我们使用 Zoom 自动将录音转化成文字，但是这样子需要消化太多没有过滤的内容，所以我们最终决定让记笔记的人对录音做总结。
6. 会议前准备
每个人的时间都很宝贵，所以会议前半小时计划好你需要的东西。比如如果你需要在 Figma 文件里面收集反馈，保证你在文件里预留充足的空间。又比如如果你想要参与者在画布上留下注解，最好是提前在文件中加一些便利贴。
7. 考虑如何交付反馈
从Radical Candor，Playing cards method，到critique chart，这三本书中都介绍了很多关于如何提供有价值的反馈的框架。Niko 也建了一个提醒我们反馈也可以有多种样式的指南。
8. 放下戒备心
很多方法可以提高安全感和团队间的信任，这些对于不让你的团队在给出和收到反馈的时候感到不适至关重要。Adam Grant 有个叫 WorkLife 的播客，我建议你们去听 The Daily Show 这集，这一集是 Trevor Noah 举了一个关于放在戒备心的例子，例子是说在会议的开端分享一些让人很尴尬的故事，从而奠定一种「弄砸了也没关系」的基调。Jon Bell 也在文章 The McDonald’s Theory 里给过一个有趣的概念，你可以在发现会议室的人特别害羞的时候用这个概念破冰。
9. 记住不要在周会内做评审
你不必等一两个周去接收反馈，直接找到你的团队的人，和他们安排一些结对设计或线下评审，这样如果你已经准备好接收反馈便不必等待。
10. 实验和迭代
不用害怕去持续的实验和迭代，设计永远没有真的做完的时候，设计流程也是同样的道理。如果能把一次实验当成提高的机会，你的团队会更放心大胆的做改变。从开始建立一个设计评审的群组开始吧！
原文链接：《Design critiques at Figma》
译文链接：zhuanlan.zhihu.com
译者：Fragile peculiar
暂无评论内容