今天为了赶版本复制一个按钮，明天另一个团队把圆角改成 10，半年后产品出现五套相似组件。每一次临时妥协都可能合理，但没有偿还机制时，它们会累积成设计债：修改越来越慢、体验越来越不一致、每个新功能都先复制旧问题。
01 Design Debt 和“界面不好看”不是一回事
设计债是过去为了速度、信息不足或技术限制做出的妥协，持续增加未来修改成本。它可能表现为重复组件、旧流程、缺状态、无障碍问题、混乱 Token 和不一致文案。
一个视觉不时髦但结构稳定的页面不一定有高债务；一个看起来漂亮却只能复制维护的系统反而可能债务很高。
02 例外不是罪，失去治理的例外才是债务来源
紧急业务可能确实需要临时组件。问题是上线后没有回到系统、没有记录，也没人负责合并。
Atlassian Design System 的原则强调先建立可信基础，再满足个别需求，并避免为了一致而一致。治理不是禁止例外，而是知道例外何时应回收。
03 把设计债按“影响”而不是按“看着不爽”排序
一个少见后台的 2px 间距偏差，优先级可能低于注册流程的错误提示缺失。
可以从用户影响、业务影响、开发维护成本、出现频率和无障碍风险评分，建立 Debt Backlog。
04 组件分叉是最容易量化的设计债
Figma 里 12 个“几乎一样”的 Modal，代码库里 8 个 Button 实现，说明系统边界已经失效。
可以定期统计 Detached Instance、重复组件和自定义样式，找出最常被绕过的系统部分。
05 不要发起“全产品统一重构”再等半年上线
设计债往往适合渐进偿还：每次业务迭代经过旧页面时顺手升级组件；高频组件先统一；新功能禁止继续使用已废弃模式。
这样能让偿还和真实业务一起发生，而不是开启一个永远排不上优先级的大项目。
06 设计系统本身也会产生债务
废弃 Token 没删除、组件文档过时、Variant 过多、设计与代码版本不同步，都会让系统变成新的负担。
设计系统需要产品式维护：版本、Owner、使用数据、迁移指南和定期清理。
07 债务记录要写“为什么存在”和“如何退出”
只记“旧表格待优化”信息太少。应该写当前问题、影响页面、产生原因、目标组件和迁移条件。
这样半年后团队仍然知道为什么要改，而不是重新争论一次。
08 判断偿还成功，不是看页面全部变新，而是未来修改变容易
统一 Token 后改主题只改一处，统一表单后错误状态不再重复设计，这才是债务减少。
Design Debt 治理的最终价值是降低下一次变化成本，让产品可以更快迭代而不持续破坏一致性。
09 设计债需要记录“为什么暂时不修”，否则例外会变成默认
赶版本时允许一个页面临时使用旧组件没有问题，问题是三个月后没人记得这是例外。可以在任务系统中记录影响范围、原因、替代方案和计划处理版本。
这样团队能够区分“有意识的债务”和“没人发现的混乱”，也更容易在后续迭代中安排偿还。
10 偿还设计债不要追求一次全站重构
大型产品一次替换所有旧组件风险很高。可以从高频组件、核心路径和最影响开发效率的问题开始，通过新功能默认使用新规则，旧页面在触达时逐步迁移。
持续小步收敛通常比每两年发起一次“设计系统大重构”更可持续。
常见问题
Design Debt 和 Technical Debt 有什么区别？
一个主要发生在体验、组件和设计决策层，一个更多发生在代码与技术架构，但两者经常相互影响。
临时设计都算设计债吗？
不一定。明确记录、计划回收的临时方案是可控妥协，长期无人管理才形成债务。
如何给设计债排优先级？
结合用户影响、业务风险、出现频率、维护成本和可访问性，而不是只看视觉不统一。
需要一次性重构整个设计系统吗？
通常不需要，渐进迁移更现实。
设计系统越严格越能减少债务吗？
不一定。过度僵化会导致团队绕过系统，可信、好用并允许合理扩展更重要。
相关服务与进一步咨询
链接复制成功
