用途
Design Debt Audit 用于系统性地识别和分级产品中累积的设计债务，在债务演变为结构性问题之前将其暴露出来。它适用于设计漂移随时间积累、需要清理和优先级排序的场景。
设计债务的定义
设计债务指产品当前状态与其应达到标准之间的任何差距，分为以下类别：
- 视觉不一致债务：组件偏离设计系统（颜色、间距、字体错误）；同一交互存在多种视觉处理；早于当前设计系统且未更新的遗留 UI。
- 结构债务：为早期版本设计、无法适应当前复杂度的模式；被不断打补丁、不再反映底层信息架构的导航；缺乏整体设计、形成孤立岛屿的功能。
- 无障碍债务：已知未修复的 WCAG 违规；视觉正常但辅助技术无法使用的组件；缺失键盘导航、焦点管理或屏幕阅读器支持。
- 文档债务：使用中但未纳入设计系统的组件；与实现不符的规格；仅存在于个人头脑中的设计决策。
- 技术/实现债务（设计相关）：使用硬编码值而非令牌实现的设 计；跨平台（iOS、Android、Web）构建方式不同且无文档说明的组件。
审计流程
- 范围与盘点：定义审计范围（全产品、某功能区域或某平台）；截图范围内每个屏幕/状态；按屏幕类型、组件类型或用户流程编目。
- 分类债务：为每个屏幕或组件标记严重度（Critical/Moderate/Minor）、类别（视觉/结构/无障碍/文档/实现）、出现频率、修复工作量（低/中/高）。
- 量化：统计每种问题类型的总实例数；估算用户触达范围；评估业务风险（合规、法律或信任风险）。
- 优先级排序：使用 严重度 × 频率 / 工作量 评分；列出高优先级短名单。
- 修复计划：快速修复（低工作量、高频不一致）；结构性项目（需设计与工程投入，排入路线图）；无障碍修复（优先 Critical，Moderate 建立滚动修复待办）；核销项（低流量区域且计划改版会解决的债务，记录并推迟）。
债务登记册
维护一份动态文档（而非一次性审计），跟踪：问题描述、类别与严重度、受影响屏幕/组件、状态（开放/进行中/已解决/已推迟）、负责人、目标解决时间（冲刺或里程碑）。每季度审查登记册，随产品变化更新严重度。
常见发现
- 未经 IA 审查添加的导航项 → 结构导航债务
- 赶工期发布、未使用设计系统组件的功能 → 视觉不一致债务
- 自带 UI 的第三方集成 → 视觉不一致 + 无障碍债务
- 内容类型快速增长超出原始布局预期 → 结构债务
最佳实践
- 在启动重大改版前运行设计债务审计，以界定实际工作范围
- 将审计与修复分离；审计是研究，不是修复冲刺
- 让工程参与严重度和工作量估算，设计师常低估实现复杂度
- 将债务减少作为指标跟踪，用于争取专门的清理资源
- 预防积累：在设计评审清单中加入“这是否会产生设计债务？”
限制
资料未提供具体收费、价格、平台支持或效果数据。