坦白来说，刚开始实习/工作的时候，我一度对设计评审（本文主要指 UX 团队内部评审）这件事儿感到过恐慌，完全不知道该说什么，如何引导听众思路得到建议等；也因此出现了一些语无伦次、或者只是沉默演示设计稿的情况。后来随着评审次数的增多慢慢好转，也看似能从评审中得到不少建议反馈，但在后续修改到设计稿细节、和项目组沟通的时候，却常常发现这些建议反馈存在之前未考虑到的局限性，最终没有实际转化为方案落地。本文就写写我对自己做得还不够好的地方的一些反思吧。

1.传达限制条件不完整

我们知道交互设计需要在商业、用户与技术三方面之间取得平衡，完全从纯用户角度出发得出的理想方案在商业产品设计中并不太现实。业务目标的冲突、技术框架的限制、甚至不同用户角色目标之间的矛盾，都会影响到我们最终的设计方案，使其看起来体验并不是那么完美顺畅。

但是团队里面每个设计师负责的具体业务不一样，别人对这些限制条件的具体了解程度也不会有你来得深入，所以在评审会议上，他们可能会从更理想化的角度出发思考，给出和限制条件矛盾的思路、建议与解决方案。所以在讲解自己的设计方案之前，也应当提前和项目组沟通清楚细节，把这些业务/技术上的冲突点清晰、全面地描述给团队其他设计师。

比如描述限制条件的根本原因，大家共同判断是否确实需要进行妥协，探讨是否有已经实现的现成案例来证明限制不存在，是否有能取得更好平衡的方案等。像技术限制，是组件改动困难（牵一发而动全身）？是实现成本过高（投入产出的性价比不够）？是影响速度等性能（实际用户体验不佳）？还是其他一些原因等；而如果只是简单说一句「前端/开发说这个做不了」的话，并不是那么令人信服。

2.目标优先级引导不够

对于平台、协作型产品来说，业务目标与用户目标冲突、不同类型用户角色目标之间冲突，都是比较常见的事情，设计方案想让所有相关方都达到最满意并不现实。

所以在设计评审的时候，也应该引导大家聚焦在当前最重要最核心的目标上，而不是为一个偏离核心目标的体验优化点纠结良久。比如一个内容型网站的业务目标是提升内容质量维持良性运转，因此产生一系列监督机制的设计，但这些机制会让一些用户感到麻烦、不爽、有心理压力，那么就需要在优先保证业务目标的基础上再去探讨怎么给用户带来更好的体验；比如产品有多类用户且用户目标存在冲突，那就描述清楚哪些用户是核心，哪些用户次要一点，优先围绕核心用户的体验探讨解决方案。

3.用户描述代入感不强

作为 B 端产品设计师，我之前和别人解释目标用户时都比较简略，用词类似「天猫商家」或者「业务方」这样，可能对于负责类似用户产品线的设计师来说理解起来还好，但整体给人的印象是很模糊的，不能很好地引导别人代入用户视角来思考。比如常做 C 端产品设计的同学可能会建议一些普通用户喜欢的趣味微交互动效、情感化设计等，但实际的产品目标用户却有可能并不关心这些，反而觉得过于花哨、影响了自己的工作效率等。

所以我觉得自己之前的那种解释用户的方式并不合格，在听众对这类用户并没有具象认知的时候，应该像设计文档里一样，和大家描绘更具体的目标用户画像、用户使用产品的真实场景、面临的痛点和关注的核心目标等，引导大家更好地代入核心目标用户而非普通用户或设计师的角度进行思考。

4.方案演示还原感不够

在方案演示效果方面，可交互 Demo 的效果大多数时候是胜于静态设计稿的。有时口干舌燥解释上一大段某个交互流程中界面如何变化，别人还未必能准确理解；而如果拿一个接近真实效果的 Demo 出来演示具体的转场过程，就可以在短短的时间内一目了然，大家也能理解得更准确。

不过静态设计稿也有它自身的好处，比如呈现各种边界场景更方便、注释说明更清晰等，而可交互 Demo 如果想顾及到每一个细节场景会耗费非常高的时间成本，在紧张的实际工作中难以践行。在时间允许的条件下，可以用效率更高的工具（如 Principle ）做一些关键转场的 Demo 来辅助静态设计稿说明演示，营造更好的场景还原感，帮助大家来准确理解感受设计方案的实际效果、给出更有针对性的建议。

5.私下沟通跟进不到位

设计评审的会议时间最长也就几小时，在这么短的时间内得到的建议反馈，其实是有不少考虑不够周到全面之处的，而这些往往要到具体修改方案的环节才发现。所以除了发起评审之外，私下找其他熟悉业务的有经验设计师沟通探讨也很重要，这样得到的建议启发也更加成熟和思虑周全。