B 端设计组件，该如何做好评审？

如果你是组件设计师，一定会对组件设计完成之后的评审过程深有体会。很早之前我在负责我们团队的组件库建设工作时就经历过这样的事情：

每次我把组件的设计方案和使用规范全部制定好后，在设计师组内开“组件设计评审会”，大家通常都会因为方案和规范的细节吵得不可开交，各执一词。经常是定不下来最终方案，好几个组件不了了之。

后来我总结出了几个实用经验，不仅让组件评审顺畅进行，也能让设计结论快速敲定。这些经验不仅可以用在组件的设计评审上，还可以用在其它设计稿的评审中。希望对你有帮助。

更多干货：

一、为什么组件设计难以评审？

在我刚做组件那几年，发现组件设计的评审会通常会比普通的业务设计稿评审会难搞得多。分析下原因，大概是以下几点：

1. 参会对象

参会的人员全是设计师，有时也会视情况叫上一到两名前端开发。在大多数都是通晓设计理论并将“用户体验”牢记于心的设计师面前，涉及到专业领域相关的讨论内容，大家就更习惯于锱铢必较，对细节严格要求。

2. 设计前提

组件的设计方案本来就不存在绝对的最优解。组件是要为业务服务的，所以不能脱离业务场景空谈组件的质量和解决方案。因此组件设计师经常需要解决业务需求和组件本身的设计体验之间如何平衡的问题，同时还要考虑到多场景的通用性。这是大部分的业务设计师都不了解的组件设计前提。

3. 使用方式

做好后的组件会变成其他设计师未来做业务需求设计时要用到的提效工具，所以一些业务设计师是有那么一点“私心”的，比如总希望这个组件可以更贴合自己负责的业务场景，这样在做需求设计时就可以付出更小的改动成本，开箱即用。

以上几个方面都会让组件的设计评审变得更加冗长和复杂。

二、组件评审的几个技巧

经过很长时间的“摸爬滚打”之后，我总结出来了几条实用经验，分享给你：

1. 建立组件的评判标准。

这里要涉及到的是你在做组件设计时的价值观和基本原则：组件在设计过程中要注重哪些规则、符合哪些标准；如果这些规则和标准如果相互冲突时，应该按照什么顺序进行遵守。

在组件库建设的初期，先确立这类设计原则很重要，团队中的其它使用组件的设计师也要先对于这些基本规则达成一致。我在文章：如何判断一个组件设计的“好”与“坏”中，也提到过一些衡量标准，可以参考。

这样，当你在评审时遇到其他设计师提出的设计建议和修改要求时，可以先判断是否符合既定的设计标准，如果不符合，可以凭此原因拒绝修改建议。

2. 设计和规范有依据支撑。

你的设计角度要客观，要有依据、有来源。各位设计师会产生争论的原因，也可能在于没有一个能够完全占据“压倒性优势”的证据或依据可以说服所有人。

当然，这种“压倒性优势”的证据其实很难找，所以你在评审时可以采用 “积少成多”的方法，也即将“很多条小证据累加起来“的方法，一条小证据可能不足以支撑你的设计成果，但 3、4、5 条小证据叠加在一起，就足以构成 “压倒性优势”。

设计师之间的交流需要有充分的证据和逻辑，所以组件设计的推理和分析过程很重要，一定要保留并在评审时有所呈现。评审时可以先给大家讲解下你的组件设计思考和分析过程，让大家既能够了解你的设计思路、理解你的设计产出，也能够感受到你对于组件设计工作的投入和付出。

3. 找有决策权的人来支持。

你可以在评审之前，先将方案拿给团队中最有设计公信力、话语权和决策权的领导看看，听听 Ta 建议、获得 Ta 对方案的认可。

在评审时如果最终实在无法说服其他设计师，或者无法选择出一个最优解，也可以根据领导的意见来做决策，一锤定音。毕竟不伦怎样都先确定出一个方案，在实际使用的过程中才可以更精准地检验方案的优劣。再正确的组件也不可能万年不变，如果发现问题，及时优化即可。

4. 疑难问题会后单独沟通。

如果有些问题实在讨论不出结果，也没有必要立即拿个定论，你就需要在大家僵持不下的时候先控场，将问题记录成待定项，往下进行其他会议内容。

在会后，你可以单独找到每一个相关方，确认方案的可行性。这样看上去是“复杂工序”，实际上却比群体讨论拿结果要快得多。等结论确定之后，可以在工作群里、月报或是日常组件的发布会中将结论进行全员发布。

欢迎关注作者微信公众号：「长弓小子」