结构，为服务而生：重构 CloudTower 设计系统并赢得跨团队采纳
一个被使用者称赞的设计系统，不是通过控制实现一致，而是让每个人以自己的方式协作。
集中式结构限制了使用体验，而服务导向的重构把团队凝聚在一起。
速览
8+
产品或工具采用/延展本设计系统
100%
团队成员肯定系统重构的价值
80%+
页面搭建时间的缩减比例
所有角色
设计师、工程师、产品经理皆从中受益
“Chiawei 构建了设计系统，不仅传达了品牌声音，他还为团队定义了相应的流程规范。这一过程需要深度协作以及扎实的工程技术知识，这在行业内实属罕见。”
— Paula, 设计团队负责人
背景
为多人团队协作而生的第一版设计系统，需要被重新设计。
随着团队从 2 人扩增到 4 人（一度扩增到 10 人），为了解决风格一致性与效率问题，我开始尝试构建设计系统。
协作方式的演变
起初团队仅有两名设计师，仅凭低成本的口头沟通和直觉判断就能维持风格统一，无需复杂流程。
随着团队扩张，设计稿组件的创建方式开始分化。有人复用旧稿，有人自行创建，缺乏统一来源导致使用不便、误用频发，整体风格也受个人品味影响而变得不一致。同时，相似组件被反复绘制，消耗了成倍的时间和精力。而原先高效的协作方式，在多人环境中反而会导致沟通协调成本骤增。
为解决一致性和效率问题，我着手构建设计系统，希望借助统一的组件库与设计规范，将最基础的设计决策从“人与人之间的沟通”转变为“系统化的参考”。
这种协作方式能在多人环境中减少整体沟通链路。因为，设计系统让所有人围绕唯一可信来源（SSOT）协作，减少个人偏好产生的误差，也避免了重复造轮子。
第一版设计系统
恰逢团队从 Sketch 迁移至 Figma，而这一工具允许将设计组件放在文档的任何位置，更加灵活，于是我尝试将组件、说明与设计规范集中在一份文件中，以减少文件数量。
集中式文档，包括 Figma 组件、风格和交互说明，以及前端开发的功能说明。
第一版设计系统实现了组件标准化，但使用体验和效率并不算太好，团队成员普遍觉得用起来“不太对劲”。数月之后，随着产品界面迎来重新设计，我也终于有机会重构设计系统，解决不好用的问题。
问题
从“混乱但流畅”，到“规范但迟缓”。我们为此付出了什么代价？
一切看起来更系统，但路径不再自然。
虽然文档内容集中、架构统一，但在实际使用中，不同角色却面临诸多障碍。我通过观察团队日常操作、回顾 Slack 讨论，并对设计师进行简短访谈，逐渐归纳出几种典型的问题。
初级产品设计师
与其他设计师不同，初级设计师对于组件名称可能不熟悉，偏好打开文档、通过外形识别组件并复制使用，而非直接搜索其名称。但文档结构之复杂、信息密度之高，令查找变得困难，尤其当组件本体隐藏在众多变体中时。
这一“意外用法”是设计系统构建时未曾考虑的行为路径。
其他产品设计师
相较于新手，有一定经验的设计师更习惯通过搜索来定位组件。但由于当时 Figma 尚不支持以变体聚合显示，多个状态的组件重复出现在结果中，外观相似、难以识别；自动布局功能的缺失使按钮等动态宽度的组件不易用；部分组件未经充分验证，效果不佳。这些问题导致挫败感。
设计系统设计师（我）
原子组件可以提升可维护性，但难以自然嵌入文档的叙事结构（因为它们仅对 Figma 组件的构建有意义，在其他场景下暴露可能引发困惑）；组件更新还常常牵动说明与排版调整，任务纠缠，降低了迭代效率甚至意愿。
系统本身逻辑自洽，但使用者的感受却总是有些不那么自然。
洞察
显性的症状之下，是结构的张力网络。
这些问题并非孤立发生，使用者的困境也远不止于此。
问题在不同角色的行为中显现，但背后牵涉到的是工具的能力边界、信息的组织逻辑、维护的操作负担，以及协作节奏的错位。这些张力彼此牵引，构成了一个无法用单一线性因果解释的复杂系统，使得问题持续存在、难以解决。
显性问题只是表象，是更深层复杂结构浮出的冰山一角。
系统的问题看起来是“找不到”“不好用”“更新慢”，但真正影响协作的，是这些困扰背后彼此牵动的机制。
1. 要素识别
系统中出现的问题，源于多个要素。这些要素不仅包含组件本身，也涉及信息密度、工具限制、时间压力、经验差异与角色定位等非显性变量。
2. 相互作用
问题并不孤立。它们形成一种“为了缓解问题而加强问题”的现象——一方的应对策略往往变成另一方的问题来源。因果路径不是线形的，而是网状的。在这样的结构中，任何一点的微调都可能引发连锁反应，复杂性因此不是量的堆积，而是要素之间的相互作用。通常，调整是不可逆的，这意味着没有试错机会。
3. 完整图景
复杂性不是由数量堆积而成，而是由多维关系网络织构而成。Gigamap 帮助看清这些因素之间的关联性，并理解哪些链条正在持续拉紧系统的张力。
不是失败的瞬间，而是循环强化的结果。
从 Gigamap 中可以看出，问题并非各自独立存在，而是在缺乏干预的结构中，被各角色的应对策略逐步积累、持续放大。当使用者以自我消化、减少干扰、绕开系统的方式处理困境时，他们其实也在无意中加强问题本身。
缺乏有效的反馈机制，困境不被看见
初级设计师使用受阻，却难以获得支持。担心显得无能、打扰他人（羞耻文化），他们选择沉默，而系统也没有提供明确的反馈通道。这进一步令他们身处困境之中。
文档的复杂度限制了迭代
系统设计经验不足，因此简单决定文档结构面向“所有人”。但是，其复杂度也让维护者迟疑于调整，最终强化了结构带来的困扰。
错误的累积难以及时缓解
当使用者遇到信息延迟、组件错用等问题时，系统并未提供快速反馈或修正机制。问题在传播中被放大，团队信心受损，加剧的挫败感导致了进一步循环。
低质组件未能被有效改善
组件设计未经充分验证即更新，使用体验不佳，设计师对复杂系统的改进感到压力。一旦形成恶评与疲惫感，就更难获得信心去尝试修复，质量问题被困在原地。
集中结构忽视了角色差异。
从反馈循环中可以发现，系统结构选择“一份文档面向所有角色”放大了诸多问题。这种“全覆盖式”的结构看似统一，却在产生认知错位——每个角色都在其中寻找属于自己的信息路径，却总是重点失焦。
为了深入理解角色需求差异，我将组件拆解为三层：表现层（看起来如何）、实现层（怎么做出来）、使用层（怎么用），并映射到三个关键角色（所有目标用户）中：
- 设计系统设计师关注组件表达的抽象能力和逻辑完整性
- 产品设计师更关注组件状态、排版控制与是否“可直接使用”
- 前端工程师则需要理解尺寸、逻辑、数据依赖等开发细节
| 角色/信息层级 | 👤 设计系统设计师 | 👤 产品设计师（初级 + 高级） | 👤 前端工程师 |
|---|---|---|---|
| 表现层 | 关注组件状态组合的完整性。如按钮 hover、disabled 的样式是否有差异。 | 关注样式是否“看起来对”，是否符合交互需求甚至品牌一致性。如主按钮是否比次按钮更显眼、更能引导用户进行操作。 | 关注是否能直接套用规范，是否还原设计。如按钮文字大小、hover 动效。 |
| 实现层 | 定义原子组件、尺寸规范、边距约束、输入框内边距是否统一。 | 希望变体的配置足够简单以方便自定义。如不希望修改一个颜色要点进两层结构，或者尽量避免 detach。 | 是否能明确组件的组成关系和数据结构。如 Tab 组件是否由独立 tab items 构成、Menu 组件的层级嵌套关系等。 |
| 使用层 | 需了解使用情景以指导合理设定变体维度。如标签组件是用于状态还是分类。 | 希望快速套用且不出错。如直接获得可用的组件套装而不是从零开始拼装，或者变体的选项名看起来易于理解。 | 是否具备必要说明、示例、边界条件说明。如输入框可否为空、是否自动 trim。 |
定义
结构即策略。改变系统行为的关键杠杆点。
系统不是静止的规范集合，而是行为被信息组织方式引导的结构网络。若要改变行为模式，就不能停留在优化内容，而要从结构本身切入。
在系统思维提出的 12 层级杠杆点模型中，有一个契合的干预层级，可以有效切断多个反馈循环。
信息流的结构
谁可以访问什么、以什么方式访问，将深刻改变协作路径与系统感受。
“所有角色共用一套文档”的设计，表面上实现了一致性，实际上掩盖了角色差异，甚至阻碍了反馈通道。这不仅让协作路径变得曲折，更在结构上固化了反馈延迟、难以演进的反馈循环。
因此，以信息路径的重构，作为突破结构性困境的关键干预点。
什么是杠杆点？
系统杠杆点模型由 Donella Meadows 提出，指出系统行为最易改变的关键干预点，共 12 层，从浅到深递进。
12 个层级的杠杆点
- 常数、参数与数值（如补贴、税收、标准）
- 缓冲区或稳定库存的大小（相对于其流动）
- 物质储量与流动的结构（如交通网络、人口结构）
- 系统变化速率与延迟长度之间的关系
- 负反馈回路的强度（相对于目标偏差）
- 正反馈回路的增强因子
- 信息流的结构（谁能访问什么信息，以何种方式）
- 系统的规则（如激励机制、约束条件）
- 增加、变更、演化或自组织系统结构的能力
- 系统的目标
- 系统背后的思维模式或范式
- 超越范式的能力
How might we —
我们如何重构设计系统，以为不同角色建立清晰、匹配的使用路径？
这个问题的本质，不是“让所有人用一个系统”，而是“让系统为每个不同的人所用”。
更深入的见解
结构设计，是观念的映射。
当问出“如何为不同角色建立清晰的使用路径”时，我意识到，这不仅仅是结构设计的问题，更是设计系统本身为何存在、为谁而组织的根本性判断。
在设计研究的经典框架中，这一问题可以被放置于“专家 – 用户”和“系统 – 人”的二维坐标系中。
第一版设计系统落于“专家 & 系统”象限：结构完整，却难以自然使用。而重新设计，不是走向“人人都能编辑”的去中心化，而是在横轴上与使用者携手，在纵轴上让系统适应人——角色被看见，系统成为支持。
这正对应系统杠杆点模型中更深层的转变：#2 改变系统的思维模式，或其所依据的范式（Paradigm）。
这不只是结构的调整，更根本的是定位的重设：从交付一个“产品”，转为提供一项“服务”。
设计系统不是控制所有人的规则空间，而应当成为服务每一个角色的基础设施。
重构
结构性改变，带来系统性改善。
系统性与人性，不必二选一。
在重构设计系统的过程中，我既没有牺牲系统层面的逻辑性和完整性，也没有忽视使用者在实际应用场景中的需求，而是同时满足二者，以达成双赢局面。
文件关系和用途的改变，改变了信息流结构，使系统能够承载协作的复杂性，回应每个角色的真实需求。
结构决定注意力，注意力决定工作质量。
围绕组件制作、快速复用与设计一致性，这三份核心文档从原结构中精准拆分，让每个角色都能聚焦在他们该关注的部分，避免在信息迷宫中消耗判断力。
UI Library（用户界面组件库）
作为样式和组件的可信来源，该文档是设计系统的底层基础设施。设计系统设计师在此：
- 专注于组件的制作与维护
- 使用不被发布的原子组件提升制作和维护效率
- 无需为组件制作之外的内容而分神
- 测试改动，而无需担心影响生产环境
产品设计师可以将其添加为 Figma Library 使用，但通常无需访问此文档。
Design Templates（设计模板）
UI 元素与页面模板的集合，内容来自 UI Library，但仅呈现组件最常用的默认状态（通过变体选项进一步自定义）。产品设计师在此：
- 视觉化锁定组件并复制使用，而不受文字信息的干扰
- 仍可在 Figma 右侧面板点击链接，跳转至 Design Guidelines 的对应页面查看组件说明
- 直接复制页面模版，免于从零搭建结构，从而专注于核心功能设计
- 直观查看表单元素的间距和内边距规范示例
- 复制组件而不受源组件更新的影响，受稳定性保障
Design Guidelines（设计准则）
作为界面风格与交互规范的统一表达，由产品设计师共同讨论撰写，并利用来自 UI Library 的组件作为展示实例。产品设计师在此：
- 理解设计语言的基础逻辑与一致性标准
- 自助检查设计是否符合视觉与交互规范
- 在新页面搭建时做出更有依据的一致性判断
这些划分源于结构的重构，它带来的好处打破了团队面临的多个反馈循环，这是走出系统性困境的最为关键的一步。
其他部分
边界之外，决定设计的最终影响力。
信息的传达不止于设计本身，更在于它如何被理解、判断并执行。为此，我延伸定义了面向研发、产品与市场的文档结构，使设计意图在协作链路中得以延续和保持一致。
UI Development Documentation（用户界面开发文档）
为前端工程师提供结构清晰、功能聚焦的开发说明文档，便于功能实现。Foundation 部分抽象出适用于多个页面的通用交互样式与功能逻辑，提升一致性和开发效率。
UI Maps（用户界面地图）
汇总产品各主要页面的最新视觉状态。产品设计师可以浏览界面设计状态以思考延续性，产品营销设计师可以导出和产品界面一致的图像资产。
测试与反馈
重新设计提振了团队内外的信心。
为了将重构后的设计系统投入试运行，我在 Slack 群组中宣布了这一里程碑。
令我意外的是，在试用过程中，整个设计团队都对重构的设计系统给予了高度赞赏，他们认为 Design Templates（设计模板）符合直觉，仿佛在回应使用意图。而页面模版实际上将构建时间缩短了 80% 以上。因组件设计更加考虑用户场景，组件的使用体验被多位设计师称为“令人惊艳”，也不断有对具体组件的积极反馈。
“世界上最好用的 Figma 表格组件（模版）。”
— Paula，设计团队负责人
在团队的推介下，产品经理团队也尝试使用模板和组件库创建示意图，缩小产品侧的构思和实际组件设计的差距，扩展一致性的边界。多位产品经理认为这套工具“非常好用”。这扩大了设计团队的影响力。
这些真实使用场景的正向反馈，是对问题识别与方向选择的有力验证。
迭代
服务，不是附加功能，而是存在方式。
服务不应止于结构重塑。为了持续回应团队需求，并演进设计系统，我们设立了以下机制：
- 设立 Google Sheet 表单作为反馈渠道，降低表达门槛。
- 设计系统设计师定期维护，集中处理高优先级请求。
- 设定实验空间，在不影响生产环境的前提下，支持更敏捷的改进试验。
- 在 Slack 解答疑问、识别需求、主动宣讲使用方法。
- 设计团队负责人定期组织 design critique，校正使用偏误，共建 Design Guidelines。
这些举措不仅帮助提升使用体验，也在悄然打破多个反馈循环——服务是一种持续行动。
影响
结构改变行为，行为推动组织演进。
新的设计系统自 2020 年末上线后保持稳定运行，并建立了明确的版本演进机制。
随着业务拓展，该设计系统已延展至超过 8 个产品平台，其生态内的资产成为设计团队的日常基础设施，甚至也成为产品经理表达需求、市场设计师统一产品营销素材的标准来源。
它不仅提升了设计效率和一致性，更推动了产品、设计、研发、市场多个角色之间的协作工作流演进。更重要的是，它不再只是“设计师的工具”，而是被跨团队主动使用、共同维护、持续反馈的协作基建。
2 个月
完成设计系统核心模块的重构
超过 8 个
产品或工具采用/延展本设计系统
反思
系统的进化，源于观念的重塑——结构，为服务而生。
设计系统的重构，不只是对组件结构的调整，更重要的是定位的转变——从一个产品，重新定义为一项服务，让系统适应人，而不是反过来——结构的转变，源于信念的更新。
这也是一次对于一致性的重新理解：一致性不是控制的产物，而是让每个角色都能以自然顺畅的方式完成任务的结果。结构因此成形，系统得以演进。
功能决定形式。
在复杂系统中，形式不是起点，而是由使用关系、真实任务与角色路径，自下而上地共同塑造出来的演化结果。
正如建筑师 Louis Sullivan 提出的经典理念“形式追随功能”（form follows function，Sullivan，1896），设计系统的结构亦应如此——不是预设形式，而是因需而生。
方法注记
本项目进行于 2020 年，许多思考和判断出于观察、直觉与思辨。
今天，我在研究生阶段的系统性思维课程中逐步意识到：那些现象的背后，存在着复杂系统中的因果网络与反馈循环，而我当时所做出的调整，实质上是一次结构性干预。
因此，我运用今日的思维，从复杂问题的视角重新撰写本文，以还原问题的完整图景，并为当时实施的干预方法引入理论支持的解释。
感谢研究生期间的教授，你们的工作意义深远。
参考文献
Meadows, D. H. (1999). Leverage points: Places to intervene in a system. The Sustainability Institute.
Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a general theory of planning. Policy Sciences, 4(2), 155–169.
Sullivan, L. (1896). The tall office building artistically considered. Lippincott’s Magazine, 57(3), 406–409.