编辑导语：设计系统对于B端产品组件设计来说十分重要，本篇文章作者分享了有关B端产品组件设计细节方面的内容以及分析了大厂做设计系统的原因，具体分析了其作用等，感兴趣的一起来看一下吧。
本文源于读者和粉丝的提问，以及我前段时间在做 Ant Design 设计与运营工作中的经验沉淀和总结，希望对你有帮助。
一、Q1 为什么大厂都要做设计系统最近随着TDesign、ArcoDesign 等设计系统陆续发布，经常会有同学问我这样的问题：
- 为什么这些设计系统感觉差异不大？大厂连这也要卷一卷？
- 设计系统虽然要注重普适性，但是不是也要有自己的品牌表达呢？
- 这些设计系统要怎么比较、分析和学习呢？
各大厂都有自己的设计系统，你可能会觉得大厂们太卷了，简直就是神仙打架。但大厂的设计系统绝对不是为了“卷”而做。之所以要做，原因至少有这几点：
1. 业务多
大厂的业务和产品多且繁杂，业务中可复用的能力和经验在长时间的积累下也会越来越多。
沉淀下来的设计系统会对自己业务起到强有力支撑和提效作用。有沉淀且不缺少应用场景，也可以保证设计系统有较高的使用频率，促进其良性发展。
2. 资源足
相对于小公司来说，大厂有更多的成本和资源可以用于做资产类的沉淀、研究和输出。大厂也理应在相应的领域多做探索和经验积累，回馈用户和市场的信任。
3. 权威高
大厂的设计水平相对来说具备较强的稳定性，输出的质量更有保证，可以发声、传播的渠道和方式也更多，也有实力在行业内树立起可靠、标准的规则话语权。
从以上几点不难看出设计系统之于大厂来说，对于内部可以赋能业务、降本提效；对于外部可以提升自己的话语权，这其实是一个双赢的过程。
二、Q2 设计系统间的共性与个性抛开代码层面不谈，仅从设计师的使用场景出发，用过 Ant Design 和 Arco Design 的设计师大概会觉得二者并没有什么差异 —— “这些设计系统好像都差不多哎。”
早些年 Ant Design 在设计系统领域已打过比较牢靠的框架基础，其他大厂进行借鉴是很正常的事情，没有必要重复造轮子。
因此这些设计系统最基础的结构和框架层面是大差不差的，看上去就好像都长一个样子。
但其实基于我们上一节说到的原因，究其细节，各家也都有各家的特点和看家本领，在应用和功能层面并不完全一致。
那作为设计师该如何对大厂们的设计系统做分析和学习呢？这里给大家提供几个比较方法和学习思路，你可以尝试从以下方面入手：
1. 功能场景
对于设计系统的功能和应用场景做分析，包括但不限于以下内容：
1）侧重的用户和场景
- 是以设计师为主、开发为主还是两者兼备；
- 是初级组件（基础组件）还是高级组件（业务组件）二者区别可阅读这里；
- 用于哪些特定的业务场景和领域等等。
2）侧重 C 端还是 B 端
支付宝设计体系曾经就有一套针对 C 端的移动端设计体系（不过也在和 AntD mini 版本进行整合）。
3）侧重国内还是国外（国际化）
国内大厂的设计系统很少考虑国际化应用场景，只有个别会提及一些国际化的设计方法和思路。这一点，国外的设计系统考虑得相对全面。
4） 独特的功能应用或外挂服务
各个设计系统在这一点上可谓百花齐放，比如 AntD 还可以与 AntV 的可视化图表联动；Arco Design 产出一套配色编辑器和图标平台等功能。
2. 体验感受
这里既要看应用设计系统做出的产品带给用户的体验和感受，也要看设计师和开发在使用设计系统的过程中的体验感受。包括但不限于以下内容：
- 设计整体基调：包括设计系统的价值观和设计原则等，奠定整个设计系统的基调；
- 视觉语言特征：包括全局样式、排版效果、动效特征等，会使用户产生最直观的视觉感受；
- 交互体验特征：包括交互反馈和针对用户操作的细节处理，决定用户的使用过程是否流畅舒适；
- 系统品牌建设：这点不仅仅是指设计系统中的组件的风格与品牌特性，也包括阅读和了解整个设计系统（网站、品牌运营与推广等内容）的体验。
3. 搭建方式
这指的是设计系统在搭建过程中的思路和工作方法，包括但不限于以下内容：
- 触达方式：指的是设计师和开发使用设计系统的方式。大部分设计系统依赖官网，提供 Figma 或 Sketch 两种 Toolkits。也有一些独特和有时效性的方式，比如 AntD 提供的 Sketch 插件 Kitchen；
- 协作机制：利用人脉资源，看看在这些设计系统中有没有你的熟人可以约着聊聊，更好地了解背后的工作和搭建方式；
- 更新频率：小迭代和大迭代的更新速率和通知方式等。
因为设计系统内容繁杂，所以建议大家在分析之前，先思考做对比的目的和目标。
不同的目的，对于以上三个方面比较的侧重点也会不同。比如，如果你是在对已有组件库进行品牌升级，就应该对于设计整体基调和整体系统的品牌建设做更深入的调研和比较。
三、Q3 页面级别的组件，到底有什么用这是我收到的一个读者朋友的提问：
“我看到一些公司在搭建页面组件库，将一些产品通用的布局整合起来直接用。我们这样做真的可以提高效率吗？这样做是否正确呢？”
相信很多朋友也都有类似的疑问。我曾经在文章：「基础组件」和「高级组件」的区别一文中聊过沉淀业务组件的必要性。
页面级组件与前两者又有所不同，它的功能更为整体，但应用的场景更为基础。
我们首先需要明白，真正有效的组件，都是设计师和开发共建的结果，其本质功能就是降本提效和达到一致性。
页面级组件的作用和意义有以下几点：
1. 框架稳定
页面级组件可以使产品在响应式布局和整体框架上保持统一。简单来说，就是对于任何新增的页面，都不会出现模块所占的面积比例不一致、行间距不一致或表单宽度不一致等问题。
2. 交互简明
一致的页面框架，在用户体验的层面上不会做过多变化，交互更加简单明了，符合用户预期。也更有利于用户将注意力集中在任务操作上。
3. 视觉统一
产品的视觉风格在框架一致的基础上，也更容易做到统一，在同产品中可以保持视觉风格的稳定；在不同产品线中也可以保持相对一致，更有利于传递公司 / 品牌心智。
4. 降本提效
不论设计师还是开发，在沉淀此类组件之后，都可以快速从 0-1 搭建出符合及格线质量的产品页面。开发对于设计稿的还原度会更高，节省的时间可以用于调整细节和优化功能。
但并不是所有的页面都值得被沉淀成页面组件。页面级组件是否真的能发挥出以上优势，取决于你的业务特征，主要看以下几个方面：
1）业务需求量大且为初期
业务对于设计和开发的需求量很大，且需求的类型相似，比如都是 B 端金融场景类或都是 G 端政务服务类。
尤其是项目处于0-1 的初期阶段，对用户体验没有太多复杂需求，以实现基本功能为主要目标。
2）功能和布局的特征明显
业务中的功能模块的特征和页面布局的框架足够明显，且该类型的页面出现的频率很高，如表单页面、卡片选择页面。
3）业务的体验风格要求统一
业务比较重视品牌一致性和用户心智的养成。在交互体验和视觉风格上，多个产品线的产品希望保持一致，不需要做过多个性化的交互或视觉上的处理。
4）合理的工具及应用规范
对于页面级组件来说，选择好用的设计工具，并制定有效的组件使用规范尤为重要。页面级组件在使用中一定会涉及到修改和补充，设计工具和规范可以帮助设计师在需要修改时快速做出局部修改和替换。
关于设计规范如何编写，可以阅读文章：如何编写设计规范？；关于设计规范如何有效的落地与执行，可以阅读文章：如何让设计规范被有效执行？
符合以上情况的业务，就可以尝试沉淀页面布局和框架。但如果业务不具备以上特点而盲目沉淀，很有可能会为设计师带来额外的工作量和无效的积累，也有可能会变成限制设计师能力和创造力的枷锁。
可以说，沉淀页面框架这个行为，本身没有正确与否的评价标准，关键是看它是否适合你的业务诉求、能否匹配你的工作方法。
毕竟，组件的本质功能就是降本提效和达到一致性，不是为了设计组件而做组件。
作者：元尧；长弓小子。
本文由@ 元尧 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
,
