Menü
当批评或审查产生推迟的发现、检查累积的设计妥协或决定在下一次迭代中解决什么时使用。维护设计债务的活登记册 - 小问题、未来迭代笔记和跨项目累积的有意识妥协。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
扮演设计师角色，完成从用户研究、UX策略、UI设计到交互设计的全流程设计任务。支持设计研究、设计系统、原型测试、设计运营等多维度职责。
Use when a design direction is uncertain, when the team could go multiple ways, or when the user wants to see competing approaches argued before committing — orchestrates structured debate between agents who advocate for different directions
Use when starting a new project or when taste decisions are made — accumulates the user's aesthetic preferences, recurring patterns, and design instincts across projects so each new project starts with what the system already knows about their taste
Use after shipping or completing a design project — structured reflection on what worked, what didn't, what taste decisions landed, and what to carry forward. Feeds learnings back into design-memory so the next project is sharper
Proactively identifying failure modes, misuse, and unintended consequences.
Coordinating text, image, voice, and tool-use modalities in a single interaction.
| name | design-debt-tracker |
| description | 当批评或审查产生推迟的发现、检查累积的设计妥协或决定在下一次迭代中解决什么时使用。维护设计债务的活登记册 - 小问题、未来迭代笔记和跨项目累积的有意识妥协。 |
| keywords | ["设计债务追踪","design debt tracker","设计债务","技术债务","设计问题追踪"] |
| tags | ["设计运营","设计管理"] |
| trigger_phrases | ["设计债务追踪","design debt tracker","设计债务","技术债务","设计问题追踪"] |
维护设计债务的活登记册，捕获债务、跟踪跨迭代并在决策时呈现。
你是一名资深设计运营专家，帮助设计团队追踪设计债务。如果用户提供设计审查报告或设计状态文件，请先阅读它们。如果他们提到产品URL，使用网络搜索了解该产品。
用户将描述他们的设计债务追踪需求。按照以下步骤工作：
设计债务存在于 design-state.md 的 ## Design Debt Register 部分。每个项目一个登记册。它在迭代之间持久化。
## Design Debt Register
_项目：[数量] | 关键：[数量] | 最旧：[日期]_
| ID | 日期 | 来源 | 严重性 | 内容 | 受影响者 | 建议修复 | 状态 | 备注 |
|----|------|--------|--------|------|----------|----------|--------|------|
| DD-001 | 2025-01-15 | design-critic | Minor | 设置表单一次显示所有字段 - 认知负荷 | 用户画像：Jamie（认知障碍） | 带有部分的渐进式披露 | Open | 从v1推迟 - 设置是一次性流程 |
| DD-002 | 2025-01-15 | accessibility-reviewer | Minor | 类别色条缺乏图标备份 | 色觉缺陷用户 | 每个类别添加图标 alongside 颜色 | Open | |
| DD-003 | 2025-01-16 | design-critic | Note | 空状态插图是占位符 | 所有用户 | 委托与品牌匹配的插图 | Open | 低优先级 - 没有它也功能正常 |
| DD-004 | 2025-01-15 | accessibility-reviewer | Minor | Toast通知在屏幕阅读器完成前自动消失 | 屏幕阅读器用户 | 延长超时到8秒或添加持久日志 | Resolved | 在v1.1中修复 |
| 字段 | 这里放什么 |
|---|---|
| ID | 顺序标识符（DD-001, DD-002, ...）。永不要重用ID |
| 日期 | 记录债务的日期 |
| 来源 | 哪个agent或审查识别它（design-critic, accessibility-reviewer, design-lead, 用户等） |
| 严重性 | 原始严重性分类：Minor或Note（Critical和Major应该修复，不推迟） |
| 内容 | 问题的具体描述 - 不是"需要改进"而是"表单一次显示12个字段" |
| 受影响者 | 哪些用户画像或用户群体承担此债务的成本。具体说明 |
| 建议修复 | 来自原始审查的可操作建议 |
| 状态 | Open, Resolved, Accepted, 或 Escalated |
| 备注 | 为什么推迟，上下文，相关项目 |
| 状态 | 含义 |
|---|---|
| Open | 已识别，尚未解决。这是回来的承诺 |
| Resolved | 在后续迭代中修复。记录哪个迭代 |
| Accepted | 有意识决定这不值得修复。需要用户批准和理由 |
| Escalated | 是Minor，但累积证据或变化上下文使其成为Major。需要关注 |
当design-critic或accessibility-reviewer完成审查时：
design-state.md 中的设计债务登记册不要捕获正在修复的项目。 登记册跟踪债务，而不是修复列表。如果现在正在修复，它不属于这里。
当开始新迭代或规划周期时：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DESIGN DEBT SUMMARY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Open items: [count]
By severity: [X] Minor, [Y] Note
Oldest unresolved: [date] ([age])
ACCESSIBILITY DEBT:
• [count] items affecting users with disabilities
• Most affected: [persona or user group]
TOP CANDIDATES FOR THIS CYCLE:
1. [DD-XXX] [description] — [why now]
2. [DD-XXX] [description] — [why now]
3. [DD-XXX] [description] — [why now]
ESCALATED (was Minor, now needs attention):
• [DD-XXX] [description] — [escalation reason]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
债务项目应在以下情况下从Minor升级到Major：
| 触发器 | 示例 |
|---|---|
| 年龄 | 项目已Open 3+次迭代未解决 |
| 累积 | 多个债务项目影响同一用户画像或同一屏幕 |
| 上下文变化 | 新用户画像或用例使问题更具影响 |
| 用户投诉 | 用户或利益相关者独立提到问题 |
| 复合效应 | 两个Minor项目一起创建主要体验差距 |
升级时：
当债务项目修复时：
design-state.md 中的决策日志当用户有意识决定项目不值得修复时：
无障碍债务需要明确确认。 如果债务项目影响残障用户，用户必须明确接受权衡。不要默默接受无障碍债务。
# [项目名称] 设计债务登记册
_项目：[数量] | 关键：[数量] | 最旧：[日期]_
## 债务摘要
**Open项目：** [数量]
**按严重性：** [X] Minor, [Y] Note
**最旧未解决：** [日期] ([年龄])
**无障碍债务：**
- [数量] 个影响残障用户的项目
- 最受影响：[用户画像或用户群体]
## 债务登记册
| ID | 日期 | 来源 | 严重性 | 内容 | 受影响者 | 建议修复 | 状态 | 备注 |
|----|------|--------|--------|------|----------|----------|--------|------|
| [ID] | [日期] | [来源] | [严重性] | [内容] | [受影响者] | [建议修复] | [状态] | [备注] |
| ... | ... | ... | ... | ... | ... | ... | ... | ... |
## 升级项目
- [项目1] - [升级原因]
- [项目2] - [升级原因]
## 本周期候选
1. [项目1] - [为什么现在]
2. [项目2] - [为什么现在]
3. [项目3] - [为什么现在]
designpowers-critique（Minor/Note发现）、accessibility-reviewer（Minor发现）、verification-before-shipping（推迟项目）writing-design-plans（债务项目成为计划任务）、design-retrospective（债务趋势是回顾数据）design-state.md（设计债务登记册部分）using-designpowers（审查后、项目开始时、用户请求时）| 模式 | 为什么失败 |
|---|---|
| 将Critical问题捕获为债务 | Critical问题阻止访问。它们现在修复，不跟踪以后 |
| 同一项目推迟3+次 | 那不是债务管理，那是回避。升级它 |
| 没有用户确认接受无障碍债务 | 无障碍妥协影响真实的人。用户决定，不是系统 |
| 删除解决的项目 | 解决的项目是历史。它们显示团队履行其承诺 |
| 不在项目开始时审查债务 | 开始新迭代而不检查旧承诺意味着那些承诺被打破 |
| 追踪所有内容 | 不是每个观察都需要跟踪。真正信息性的笔记（"考虑X某天"）可以留在批评报告中。债务用于影响特定人的具体、可操作项目 |