设计系统是一个知识生产和应用的系统
tags
Design
Tool
Works
date
Jul 24, 2022
设计系统的意义
在《设计心理学3》中作者提到设计的本质：
有一堆选项，其中一些选项比其他好，但没有哪一种选项是完美的。
这些选项可以称为设计材料。
设计是与材料对话，我们需要知道有什么材料并且熟悉各种材料的特质才能做出更好的设计。
设计系统是一个材料清单，可以帮助我们实现上述目标。
此外，设计系统沉淀的设计模式、通用规则可以提高设计的效率、减少团队的沟通成本。
设计系统的维护
设计系统也是一个知识生产和应用的系统，下面会基于这个认识梳理组件的生命周期。
生产
团队共建
设计系统关系到团队的每一个成员，即便从搭建的工作量上一两位设计师也可以胜任，但团队共建仍然存在一些好处
- 设计系统对产品有重要影响，需要成员理解系统的内容，最好直接参与建设
- 培养团队成员积累设计模式、经验的意识
- ……
依赖成员自觉是行不通的，需要建设一套共建流程进行推动。
轮班制
按照一个固定的周期（例如每周、每月）选取部分成员完成指定的任务；未被指定的成员也可自主加入。
可以自行从以下任务中选择
- 新建组件：拥有一个新组件想法时，可以新建组件；
- 迭代组件：通过收集组件使用反馈、通过数据评估组件上线效果跟进与优化寻找迭代方向
组件创建流程
在创建前（主要针对新建组件的场景），设计师需要先自查这几个问题
- 有无必要，例如使用场景较少的控件则不建议做成组件。
- 能否用已有组件完成，如果不能，能否在已有的组件基础上迭代？而不是新建组件
- 组件还能用在哪些地方，尝试创造更多使用案例
每个周期，利用Figma 分支功能创建一个设计系统的分支；周期内所有的新增和修改在分支内完成。
创建组件的第一步需了解已有方案，搜索线上截图、历史文档罗列目前已有的方案，找出方案的共性与个性，打造出适用性更强的组件。
组件编辑原则，可参考 Figma 组件库搭建与易用性优化
组件评审
评审可增加设计系统的修改摩擦，避免一次性的设计，控制好组件的迭代与稳定性的平衡。
每个周期举行至少一场会议用于评审（或可在站会中完成），主要围绕上述「创建组件前的 3 个问题」展开讨论。
- Figma 组件迭代也要做好新旧版本兼容
周期内评审通过的组件统一推送更新到主文件，供团队成员使用。
更新日志同步
组件更新后需要与包括策划、QA、技术等多个职能的同事同步。
在每次组件的修订中，可通过 Figma 的批注功能标记修改点；待评审后统一整理更新日志，在设计系统对接群中同步更新信息。
应用
掌握基本的软件操作技能
在实际的组件使用中，不熟悉组件、自动布局等功能会给使用者造成一定程度的使用障碍；除了编辑者在设计组件时通过创造案例等方式提升易用性之外，组件用户也需要掌握以下基本的软件操作技能
需要将上述学习作为新人入职培训流程的一环。
比起减少使用障碍，不如直接去除障碍
最好的组件/规范使用体验，就是不需要使用
对于团队形成共识，基本不存在需求/项目差异的设计模式，可以推动技术开发成产品的默认逻辑；或者在设计层面打包成一个可以直接复制粘贴到文档中的组件。从而实现设计师无需花费精力关注的效果。
例如浮层的弹出动效可以作为基础的逻辑进行开发；同时也可以输出逻辑描述模板，设计师可以直接粘贴到文档中快速完成设计需求交付。
对于设计验收中的常见问题且这些问题的解决方案存在共识，则可以整理自查清单并与技术、QA 同学共享，减少验收环节的沟通成本，也避免验收时即将上线来不及修改导致的产品质量下降。
反馈
通过反馈机制促进组件的持续发展。
组件上线效果跟进与优化
Figma 提供了组件的数据看板，我们可以借此分析组件的使用情况，具体可参考 组件上线效果跟进与优化
其中使用次数高的组件可以推进到下游完成视觉/UI 组件、技术组件的搭建，同步给 QA、策划等岗位。
建立跨职能的协作群，除了本文「应用」环节中提到的「更新日志同步」外，协作群也提供了与其他职能沟通设计系统的环境。
小结
设计系统的生产重点在于团队共建，需要构建完善的分类、命名规则更好的沉淀设计知识；应用环节设计师本身需要掌握基本的软件操作技巧，此外还会总结通用的设计模式减少用户使用的障碍、推进跨职能的协作。通过构建反馈机制促进设计系统的持续发展。