---
title: 设计系统究竟应该由谁来负责？
date: 2024-09-25
tags: [设计思考, 设计系统]
description: 在聊到设计系统这个话题时，很多人都有一个困惑。那就是在团队中，设计系统的工作究竟应该由谁来负责？这个问题表面上看似简单，但在实际操作中却远比想象中的复杂。因为它不能仅仅停留在一套文档的层面上，必须在产品的研发过程中运转起来才能发挥出它真正的价值。
author: 5key
source: https://www.thefivekey.com/who-should-own-design-system/
---

# 设计系统究竟应该由谁来负责？

> 在聊到设计系统这个话题时，很多人都有一个困惑。那就是在团队中，设计系统的工作究竟应该由谁来负责？这个问题表面上看似简单，但在实际操作中却远比想象中的复杂。因为它不能仅仅停留在一套文档的层面上，必须在产品的研发过程中运转起来才能发挥出它真正的价值。

**作者**：5key　·　**发布于**：2024-09-25　·　**原文链接**：https://www.thefivekey.com/who-should-own-design-system/

---

![设计系统究竟应该由谁来负责？](images/who-should-own-design-system.png)
## 篇首语
在聊到设计系统这个话题时，很多人都有一个困惑。那就是在团队中，设计系统的工作究竟应该由谁来负责？这个问题表面上看似简单，但在实际操作中却远比想象中的复杂。

有些设计团队会认为，设计系统只是一套需要偶尔更新的文档，它只是在做项目时随手查找参考的工具。因此大家会认为，设计系统的工作并没有特别的重要，谁的资源相对空一些就安排谁来做。

我曾经也见过一些团队，会将设计系统的工作交给新入职的设计师。让新人熟悉团队和业务的同时也可以顺便梳理一下文档，分担一些工作。这种“谁做都行”的心态，最终的结果就是权责不清，导致设计系统的推进和落地变得异常艰难。

在过往讨论设计系统的文章里，很多次和大家说设计系统绝对不能仅仅停留在一套文档的层面上。它必须在产品的研发过程中运转起来才能发挥出它真正的价值。这种运作的要求使得设计系统不可避免地与团队内以及上下游的协作关联起来。从这个角度来说，设计系统也不再是单一团队的责任，而是涉及到整个组织的流程和协作方式。

在设计中台的那个阶段里，我的团队非常重要的职责之一就是协作各个业务设计团队推进设计系统的落地。在这个过程中，我们看到了各式各样的问题。有的希望能快速迭代，有的希望极度收敛，还有的希望高度定制...

而这些看上去非常专业向的工作，很多时候出现的卡点并不是工作本身，而是其背后的机制和保障问题。直白点来说就是，这个事情究竟应该由谁来负责？

在有的团队里，设计系统是设计师的“附加任务”，大家需要在完成日常设计工作的同时，负责系统的更新和管理，而在另一些团队，设计系统则由专人或者是团队负责。无论哪种，多多少少都会存在一些劣势，这些工作投入很多时候也不被业务所认可。

因此，在今天的文章中，我想从「谁来负责」这个问题切入，和探讨在设计团队中，设计系统究竟应该通过什么样的机制来推动。需要强调的是，每个团队的业务背景和工作模式不同，所以这里并不存在标准答案。这篇文章只是希望分享我的一些思路，能够为大家提供参考，帮助大家在各自的业务中找到合适的推进方式。

## 阅读全文

以上内容节选自设计有得聊专栏 47 期文章「设计系统究竟应该由谁来负责？」。欢迎加入我的知识星球，阅读本期文章全文内容以及过往所有文章。


---

_本文由 [5key](https://www.thefivekey.com/) 创作，原文发布于 [https://www.thefivekey.com/who-should-own-design-system/](https://www.thefivekey.com/who-should-own-design-system/)。欢迎引用，请注明出处。_

_订阅付费专栏「OFF DESIGN」：https://www.thefivekey.com/premium-design-subscription/_