TL;DR
设计系统的卡点很多时候不在工作本身，而在「谁来负责」。
把它当成谁有空谁做的附加任务、或者交给新人练手，都会让推行变得困难。
设计系统不是一套文档，而是一套需要持续运转的机制：必须有清晰的所有权和稳定的资源投入，才能真正在产品研发流程中发挥价值。
设计系统所有权问题：为什么这么难？
在聊到设计系统这个话题时，很多人都有一个困惑。那就是在团队中，设计系统的工作究竟应该由谁来负责？这个问题表面上看似简单，但在实际操作中却远比想象中的复杂。
有些设计团队会认为，设计系统只是一套需要偶尔更新的文档，它只是在做项目时随手查找参考的工具。因此大家会认为，设计系统的工作并没有特别的重要，谁的资源相对空一些就安排谁来做。
我曾经也见过一些团队，会将设计系统的工作交给新入职的设计师。让新人熟悉团队和业务的同时也可以顺便梳理一下文档，分担一些工作。这种“谁做都行”的心态，最终的结果就是权责不清，导致设计系统的推进和落地变得异常艰难。
设计系统不是文档，而是一套需要运转的机制
在过往讨论设计系统的文章里，很多次和大家说设计系统绝对不能仅仅停留在一套文档的层面上。它必须在产品的研发过程中运转起来才能发挥出它真正的价值。这种运作的要求使得设计系统不可避免地与团队内以及上下游的协作关联起来。从这个角度来说，设计系统也不再是单一团队的责任，而是涉及到整个组织的流程和协作方式。
在设计中台的那个阶段里，我的团队非常重要的职责之一就是协作各个业务设计团队推进设计系统的落地。在这个过程中，我们看到了各式各样的问题。有的希望能快速迭代，有的希望极度收敛，还有的希望高度定制…
而这些看上去非常专业向的工作，很多时候出现的卡点并不是工作本身，而是其背后的机制和保障问题。直白点来说就是，这个事情究竟应该由谁来负责？
不同团队模式下的负责机制对比
在有的团队里，设计系统是设计师的“附加任务”，大家需要在完成日常设计工作的同时，负责系统的更新和管理，而在另一些团队，设计系统则由专人或者是团队负责。无论哪种，多多少少都会存在一些劣势，这些工作投入很多时候也不被业务所认可。
因此，在今天的文章中，我想从「谁来负责」这个问题切入，和探讨在设计团队中，设计系统究竟应该通过什么样的机制来推动。需要强调的是，每个团队的业务背景和工作模式不同，所以这里并不存在标准答案。这篇文章只是希望分享我的一些思路，能够为大家提供参考，帮助大家在各自的业务中找到合适的推进方式。
阅读全文
以上内容节选自OFF DESIGN 专栏 47 期文章「设计系统究竟应该由谁来负责？」。
💡 延伸阅读：
- 📚 主题枢纽：设计系统完整指南 ｜涵盖三层架构、案例、AI 时代的完整路径
- 入门基础：设计系统 · 我们为什么要做 Design System
- 角色演变：成为架构型设计师
- 推行话术：如何向你的主管和团队介绍 Design System 的重要性
欢迎加入我的知识星球，阅读本期文章全文内容以及过往所有文章。