「习以为常」的未必是最好的，多一点自己对于人性化、创新细节的思考

最近在推动手头负责的一个 C 端移动产品的组件化体验升级，这个产品因为复杂业务场景和一些历史遗留问题，许多最基本的组件线上样式与交互体验都可以用「惨不忍睹」来形容，而对业务组件做系统整理和重新设计优化，也是项目组普遍认可的事情。虽然才起步不久，但也在过程中积累了一些对于组件化设计升级的思考和心得，在此总结一下，欢迎补充。

什么情况下做组件化设计

组件化设计在前期有较大的整理、设计与开发成本，并不是所有项目都适合，在驱动组件化设计及升级之前，我们需要对项目现状有比较清晰的评估和认知。

01 是否存在多人协同的情况？

如果只是 1 个设计 + 1 个前端之类的配置，很多细节体验问题靠面对面口头沟通也能解决，但如果项目中有多个设计师或多个前端，没有统一的组件规范的话，就容易造成样式混乱、重复设计开发一类的问题。这时推动组件化设计是一件有必要的事情。

02 产品是否进入相对成熟的阶段？

组件化设计会考虑很多对于细节的打磨和规范，对于从 0 到 1 的产品，有时候最基础的业务/用户价值都还很模糊，快速上线验证迭代更加重要，一个 60 分的 MVP 可能就够用了；而渡过这一阶段、产品形态又未完全固化的时候，就需要更多对于体验细节的关注和打磨，组件化设计时机相对成熟。

03 线上组件体验是否影响核心业务指标？

发起组件化设计升级之前，线上通常已经积累了一部分「能用」的组件，开奖，但是组件基础体验不佳，造成用户误判概率大、操作效率低、满意度低等情况，有些会影响到核心业务指标，所以需要升级优化。

组件化设计有什么好处 01 思考角度更全面

如果只是跟着某一个具体业务场景出方案，我们可能只会考虑组件在当前场景能否满足诉求，而没有跳出来看全局，后续组件在其他场景里可能有被「滥用」的风险。而在组件化设计过程中，我们需要更完整地走查和整理所有已有 & 潜在业务场景，全链路考虑解决方案。

以我们最近设计的一个「图片」组件为例，这个组件在好几个场景都会被用到。最开始接到的是其中一个场景下的业务需求，用户可以浏览自己之前上传的图片、定位具体问题在哪，当时处理得比较简单，就是常见的固定尺寸居中裁剪展示缩略图。结果后面业务方把这个组件复用到其他地方，就出现了问题：被复用的是一个图片审核的场景，用户需要浏览业务给出的若干图片，判断是否符合要求，而这些图片可能非常奇葩，可能是一张很长的图片然后顶部有文字，裁剪后文字默认是看不到的，对于「图中是否有文字」一类问题用户就可能误判。在前一场景里我们注重的是浏览效率、帮助用户快速定位，图片本身由用户上传也不会存在「裁剪误判」一类问题；而在后一场景里我们注重的是准确率、减少用户误判，不能简单复用前一场景的方案。

具体到方案设计阶段，需要平衡的因素也很多，准确率、效率、可用性、美观度、一致性等，要考虑很多极端场景下的展示效果是否会有问题，制定相应的处理规则等，这个过程比较累，但有助于我们进行更完整全面的思考，产出更能灵活适应不同场景的方案。

02 细节打磨更充分

在做业务需求的时候，因为时间、优先级等原因，我们可能更注重整体的流程体验的通畅，而不会花太多精力去打磨其中某一小块的创新动效等细节。即使做了，在开发评估优先级时也会往后排甚至直接砍掉。

但如果单独拎成一个组件去优化，组件化的设计交付节奏一般由设计师自行把控，而不是和业务需求一样受制于业务方，我们也会有更多的时间来进行充分的打磨，加入更多人性化思考、微交互创新、动效细节等，捆绑交付给开发。

03 想法落地更容易

好的想法无法落地是困扰过很多设计师的问题，具体原因我之前的文章也有思考过，除去业务价值之外，开发成本也是影响我们将想法变为现实的重要因素。而我近期解决这个问题的一个尝试，就是将之前的想法「化整为零」，把原先完整的设计优化方案肢解成好几个组件的组合，然后按优先级去推动每个组件的优化，直到将所有组件都优化完毕。这样的一个好处是在开发资源节奏紧张的时候，可以更好地见缝插针推动迭代，适用于在已有完整线上方案的基础上进行体验优化。

组件化设计流程

具体的组件化设计升级流程我总结成了下图：

01 类目梳理