需要为设计团队建立日常运作节奏时…

当设计团队日常协作节奏缺乏结构，需要系统设计任务管理、协作仪式、沟通规范、工具栈和设计-开发协作时使用。

适用场景

解决思路

1. 设计任务跟踪方式：使用看板（boards）、工单（tickets）、迭代（sprints）等管理工作的流转。
2. 定义状态：明确 backlog、in progress、in review、done 等状态含义。
3. 定义优先级等级，并规定优先级如何分配。
4. 进行容量规划和工作量平衡。
5. 组织 Standup（每日或异步）：同步正在做什么、是否有阻塞。
6. 组织 Design critique（每周）：进行结构化反馈会议。
7. 组织 Design review（每个里程碑）：设置质量门禁检查点。
8. 组织 Retrospective（每个 sprint/month）：推动流程改进。
9. 组织 Show and tell（每两周）：向更广泛的团队分享工作。
10. 规定何时使用同步沟通、何时使用异步沟通。
11. 为每个渠道设定响应时间预期。
12. 规定如何请求反馈。
13. 规定如何分享决策和上下文。
14. 明确文档要求。
15. 选择设计工具（Figma、Sketch 等）。
16. 选择原型制作工具。
17. 选择项目管理工具（Jira、Linear、Asana 等）。
18. 选择沟通工具（Slack、Teams 等）。
19. 选择文档工具（Notion、Confluence 等）。
20. 建立版本控制和资产管理制度。
21. 明确设计师何时加入 sprint ceremonies。
22. 定义 Handoff 流程和时机。
23. 定义 Design QA 流程。
24. 建立设计问题的 Bug 报告流程。
25. 管理共享组件库。
26. Discovery 阶段：进行研究与问题定义。
27. Exploration 阶段：生成并评估概念。
28. Refinement 阶段：详细设计与规格说明。
29. Handoff 阶段：交付给开发者并提供支持。
30. QA 阶段：验证实现效果。
31. Iteration 阶段：上线后持续改进。
32. 记录工作流并使其可见。
33. 定期评审并调整工作流。
34. 按团队实际需求优化，而不是按理论优化。
35. 在结构与灵活性之间取得平衡。
36. 尽可能自动化重复性任务。

适用边界 · 注意事项

• 只适用于为一个时间盒内的 sprint 做计划时，应改用 `design-sprint-plan`。
• 不适用于团队规模极小、无需正式仪式和文档的场景。
• 不适用于缺乏基本协作工具或没有设计-开发协作需求的场景。