北京
分享至
我做过三个设计系统。第一个从来没上线。第二个晚了六个月才上线。第三个到今天还在持续交付。
差别不在设计质量，也不在工具——Figma、Storybook，用什么都一样。差别在于：这个系统归谁所有。
产品设计师拥有它，系统就会为设计而优化。工程师拥有它，系统就会为基础设施而优化。没人拥有它——这是最糟的情况——它谁也不为，只为存在而存在。
作为一名设计工程师，我学到的是另一件事：设计系统应该为交付而优化。
不是交付一次，是持续交付。
设计工程师的视角
核心洞察在这里：大多数设计系统是自上而下建起来的。
设计师造组件 → 工程师实现组件 → 产品团队使用组件
问题出在哪？等工程师把设计师画的东西实现出来，真实的约束早就被焊死在里面了。工程师想重构、想简化、想重新组织结构。设计师想保住那套视觉体系。什么都交付不顺畅。
设计工程师走的是自下而上的路：
先理解约束 → 再造基础件 → 再组合成组件 → 最后在上面做设计
这意味着几件事：
- 我们带着代码的约束做设计，而不是无视它们
- 先造尽可能小的基础件
- 不为“未来的灵活性”过度架构
- 快速交付，然后迭代
结果是什么？交付速度提升 2 到 3 倍。
框架：构建能交付的设计系统
下面是我在用的框架，一共四个阶段。
第一阶段：从约束开始（第一周）
在你设计哪怕一个组件之前，先问清楚：
- 我们在造什么？（产品类型：SaaS、交易市场，还是企业工具？）
- 我们为之设计的数据是什么？（真实数字：100 个用户还是 100 万？结构简单还是复杂？）
- 团队结构是什么样？（一个设计师？五个？还是五十个？）
- 交付速度目标是什么？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
