design-ops

设计运营与交接

让设计团队高效运作的流程——冲刺、交接、例行活动、文档和质量保证。

---

设计冲刺

一个为期 5 天的流程，用于解决重大问题，并在投入工程资源前测试想法。基于 Jake Knapp 在 Google Ventures 开发的 Sprint 方法论。

何时进行冲刺

信号	适合冲刺	不适合冲刺
问题清晰度	问题重大，解决方案不明确	解决方案已知——直接开发即可
风险	高——方向错误会浪费数月时间	低——之后很容易调整方向
团队共识	对方案存在分歧	团队已达成共识
时间压力	需要在本周内找到答案	可以开展更长时间的探索流程
复杂性	跨职能问题	单一职能任务

5 天的安排

日	重点	主要活动	产出
周一	绘制地图	明确挑战，设定 2 年目标，绘制问题空间，选定目标	冲刺问题、问题地图、目标领域
周二	绘制草图	评审现有解决方案，每个人单独绘制解决方案草图	解决方案草图（每人一份）
周三	决策	展示草图，投票（圆点投票，由决策者选定），绘制故事板	原型故事板
周四	制作原型	构建逼真的门面——只需足以进行测试	可测试的原型
周五	测试	进行 5 次用户访谈，共同观察并找出规律	有证据支持的继续／停止决定

冲刺团队

角色	人数	职责
决策者	1	有权做出最终决定。通常是 PM 或创始人
引导者	1	推进流程、把控时间、调动团队状态
设计师	1-2	主导草图绘制，制作原型
工程师	1-2	快速评估可行性，协助制作原型
领域专家	1-2	客户支持、销售、营销——任何了解用户的人
总计	5-7	超过 7 人会适得其反

冲刺规则

1. 工作时不使用设备——全神贯注
2. 各自独立，一起工作——个人绘制草图，而非集体头脑风暴
3. 由决策者做决定——民主决策效率低；由一人打破僵局
4. 制作原型，而非正式构建——注重门面质量，而非生产质量
5. 5 位用户就够了——5 位参与者就能发现 85% 的可用性问题

---

设计到开发的交接

交接是产品团队质量损失的头号来源。目标：工程师绝不需要猜测。

交接成熟度等级

等级	描述	表现
1. 截图	设计师发送静态图片	工程师需要猜测间距、状态和行为
2. 带注释的模型图	标注尺寸、间距说明	有所改善，但仍缺少状态和边缘情况
3. 交互式规范	包含检查模式和组件链接的 Figma／设计工具	工程师可以提取数值，但行为未记录
4. 完整规范	包含所有状态、过渡、错误处理、响应式行为和设计令牌	工程师可以准确实现设计
5. 集成	设计和代码共用一个组件系统；交接是对话，而非文档	所需规范极少——共同语言便能解决问题

目标：至少达到 4 级。成熟团队应达到 5 级。

完整交接应包含的内容

每个屏幕或组件的交接都必须涵盖：

类别	必要项目
布局	间距（使用设计令牌，而非像素）、对齐方式、响应式断点、容器行为
内容	最终文案（不是占位文本）、字符限制、截断规则、本地化说明
状态	每个交互元素的默认、悬停、焦点、激活、禁用、加载、空、错误和成功状态
行为	点击、轻触、键盘交互、拖动、滑动时的行为。过渡细节
响应式	布局在各断点处如何调整。哪些内容会重排、堆叠、隐藏或变化
设计令牌	颜色、字体排版、间距令牌——绝不使用原始十六进制值或 px 值
无障碍性	焦点顺序、ARIA 角色、屏幕阅读器播报、触控目标、颜色对比度
边缘情况	长字符串、空数据、错误恢复、离线行为、权限
素材	图标（SVG）、图片（含替代文本）、动画（规格或文件）

交接中的反模式

反模式	问题	修正方式
“在 Figma 里”	没有上下文，工程师必须反向推断意图	在每个画板上写明行为说明
只有理想路径	只设计了理想流程	交接前设计所有状态
像素规格	“左侧边距 24px”	使用令牌：spacing-md
口头交接	“我会在站会时解释”	没有写下来的内容，就等于不存在
一次性大规模交接	一次性把整个功能交给工程团队	按照与冲刺故事相符的切片进行交接
没有错误状态	“错误情况以后再处理”	错误状态要最先设计，而不是最后

---

团队惯例与节奏

核心设计惯例

惯例	频率	时长	目的	参与者
设计评审	每周	45-60 分钟	通过结构化反馈改进进行中的工作	所有设计师
设计与工程同步会	每周	30 分钟	对齐即将开展的工作，解决交接问题	设计负责人 + 工程负责人
设计审核	每个里程碑	30-60 分钟	让利益相关者对方向进行签核	PM、设计和工程负责人、利益相关者
交接会议	每个故事/功能	30-45 分钟	向工程团队讲解规格并答疑	设计师 + 负责实现的工程师
设计 QA	每次发布	60-90 分钟	验证实现是否符合规格	设计师 + 工程师
回顾会	每两周一次或每个冲刺一次	45 分钟	改进流程	整个产品团队
设计冲刺	按需	5 天	解决重大问题，验证高风险创意	跨职能团队（5-7 人）

开展有效的设计评审

形式： 演示者介绍背景（2 分钟）→ 小组静默审阅（3 分钟）→ 结构化反馈（每项 15-20 分钟）→ 后续步骤（2 分钟）

评审规则：

1. 演示者说明需要什么反馈——“我需要在空状态上获得帮助”，而不是“你们觉得怎么样？”
2. 反馈要引用原则，而非个人偏好——“这违反了菲茨定律”，而不是“我不喜欢按钮的位置”
3. 描述问题，不要指定解决方案——“用户可能会错过这个操作”，而不是“把按钮做大”
4. 不要辩解——演示者倾听，只提出澄清性问题
5. 记录书面反馈——由专人记录所有反馈事项及负责人

交接会议结构

1. 背景（5 分钟）——要解决什么问题？对应什么用户故事？
2. 演示（10-15 分钟）——设计师逐屏讲解流程
3. 状态与边缘情况（10 分钟）——悬停、错误、空、加载、响应式
4. 令牌与组件（5 分钟）——要使用哪些设计系统组件和令牌
5. 问题（10 分钟）——工程师提出所有不清楚的问题
6. 行动事项——开始构建之前需要澄清哪些内容

---

文档规范

文件组织

project-name/
├── exploration/          # Early concepts, discarded directions
│   └── v1-concepts/
├── current/              # Active, approved designs
│   ├── flows/            # User flows and journey maps
│   ├── screens/          # Screen-level designs
│   └── components/       # Component-level specs
├── assets/               # Production-ready exports
│   ├── icons/
│   └── images/
├── handoff/              # Handoff documentation
│   └── [feature-name]/
└── archive/              # Past versions (never delete, move here)

命名规范

元素	规范	示例
文件	[project]-[feature]-[variant]	taskpilot-onboarding-v2
页面/画框	[flow]-[step]-[state]	checkout-payment-error
组件	与代码中的组件名称完全一致	ButtonPrimary，而不是 Main CTA
版本	语义化：v1.0、v1.1、v2.0	主版本 = 新方向，次版本 = 迭代
图层	描述性命名，不要使用 “Group 1” 或 “Frame 47”	header/nav/menu-trigger

版本控制规则

1. 绝不覆盖——创建新版本，并归档旧版本
2. 说明变更内容——“v2.1 — 添加错误状态”，而不只是“v2.1”
3. 关联决策记录——每个主要版本都要关联推动其产生的决策（Slack 讨论串、会议记录、冲刺回顾）
4. 单一事实来源——每项功能只保留一个权威文件。不要创建 “copy of” 文件
5. 归档，不删除——将过时设计移至归档目录，并添加日期标记

---

设计 QA

设计 QA 是验证实际构建内容是否符合设计的流程。每次发布前都要执行。

设计 QA 检查清单

类别	检查项	工具
视觉准确性	颜色与令牌一致。间距符合规范。排版正确	并排对比、浏览器开发者工具
状态	所有状态均正确呈现：默认、悬停、焦点、激活、禁用、错误、加载、空状态	手动测试、Storybook
响应式	布局在所有断点下均正常。没有内容溢出、错误截断或消失	调整浏览器大小，在真实设备上测试
内容	实际内容能够适配。长字符串得到妥善处理。空状态已设计。截断效果正常	使用边界情况内容进行测试
交互	动画符合规范。过渡流畅。时长恰当	手动测试、慢动作录制
无障碍性	焦点顺序正确。屏幕阅读器播报正确。对比度符合要求。触控目标不小于 44px	axe、键盘测试、VoiceOver/NVDA
跨浏览器	在 Chrome、Firefox、Safari、Edge 中均正确呈现	BrowserStack 或手动测试
性能	图片已优化。没有布局偏移。动画不会丢帧	Lighthouse、Core Web Vitals

提交设计 QA 问题

每个问题都需要：

**What:** [Element name] on [screen/page]
**Expected:** [What the design spec shows — link to frame]
**Actual:** [What the build shows — screenshot]
**Severity:** [Critical / Major / Minor / Cosmetic]
**Environment:** [Browser, viewport, OS]

严重程度：

• 严重——功能异常。用户无法完成任务
• 主要——行为错误。用户可以完成任务，但会感到困惑或遇到错误
• 轻微——视觉差异。用户在功能上不受影响，但质量观感不佳
• 外观问题——细枝末节。只有设计师才会注意到的像素级差异

设计验收标准

将以下内容添加到每个用户故事中：

Design acceptance criteria:
- [ ] All states match design spec (link to Figma frame)
- [ ] Responsive behavior verified at 320px, 768px, 1024px, 1440px
- [ ] Keyboard navigation works (Tab, Enter, Escape, Arrow keys)
- [ ] Screen reader announces all interactive elements correctly
- [ ] Design tokens used (no hardcoded colors, spacing, or typography)
- [ ] Loading and error states implemented
- [ ] Edge-case content tested (empty, long strings, special characters)

---

流程指标

跟踪以下指标，以衡量设计运营的健康状况：

指标	衡量内容	目标	衡量方法
交接完整度	包含所有状态、令牌和响应式规范的交接占比	>90%	每季度审查交接文档
设计 QA 通过率	首次评审即通过设计 QA 的用户故事占比	>80%	跟踪每个用户故事的 QA 问题
返工率	交接后需要重新制作的设计工作占比	<15%	统计交接后的设计变更
对冲刺速度的影响	缺失的规范阻碍工程工作的频率	0 blocks/sprint	在每日站会中跟踪阻塞项标签
设计债务	生产环境中已知的视觉/交互不一致问题	逐步减少	维护设计债务待办列表
设计评审参与度	定期带设计成果参加评审的设计师占比	每月 100%	跟踪设计评审分享者

---

面向精简团队的缩减版运营流程

以上流程以有专职设计团队为前提。但许多组织只有一名设计师，或者由某人在更广泛的岗位职责中兼顾设计工作。这些原则仍然适用；执行方式可以相应缩减。本节借鉴 Leah Buley 的单人 UX 团队框架，为资源有限的团队提供调整后的方法。

核心思维方式

1. 专注于小胜利。 你无法一夜之间改变整个组织。挑选一项显而易见的改进，把它做好，再让成果为下一步积蓄动力
2. 建立以用户为中心的文化，而不是 UX 部门。 你的目标不是包揽所有设计工作，而是让团队里的每个人都考虑用户
3. 培养成长型思维。 寻找逐步拓展技能的机会。开始练习用户研究或测试，不需要先获得许可

游击式方法

如果没有预算、时间或正式的研究基础设施：

完整流程	游击式替代方案	适用场景
正式可用性研究（实验室、招募参与者、5 名以上参与者）	找 3 个人进行 15 分钟的走廊测试	早期概念、内部工具、低风险功能
为期数周的探索性研究	一周内访谈 3 位客户，并审查支持工单	你需要的是方向性洞察，而非统计置信度
设计冲刺（完整 5 天）	迷你冲刺：2 天版本（第 1 天绘制地图并构思，第 2 天制作原型并测试）	较小的问题、团队意见一致、已有良好的前期研究
完整的用户旅程地图工作坊	在白板上绘制假设地图（与团队用 30 分钟标出已知和猜测的内容）	你更需要达成共识，而非开展研究时
正式设计评审（每周一次，全体设计师参加）	在 Figma 评论中进行异步评审，邀请一位工程师和一位 PM 参与	单人设计师，没有可参与评审的设计同行
带治理机制的设计系统	组件清单 + 使用命名约定的共享 Figma 库	小型产品、1-3 名工程师

建立关系并争取支持

作为单人设计师或精简团队的设计师，你的成效更多取决于关系，而非流程。

争取一席之地：

• 先满足团队的眼前需求——即使是杂活也能建立好感
• 用行动而不是说辞来证明。能暴露问题的快速原型，比一场关于 UX 成熟度的演示更有价值
• 将 UX 工作与领导层已经关注的指标挂钩（转化率、支持工单、留存率）

在没有职权的情况下施加影响：

• 将建议作为实验而非指令来提出：“我们能否先找 3 位用户测试，再决定是否推进？”
• 根据受众习惯的形式分享研究结果——给工程师发 Slack 摘要，给领导层看仪表板，给 PM 发带注释的截图
• 有信心地呈现研究发现，同时邀请大家共同探讨：“这是我们的发现——对你负责的领域意味着什么？”

为单人或精简团队调整仪式

完整仪式	精简版替代方案	频率
每周设计评审	每两周一次“设计午餐”——向所有感兴趣的人展示进行中的作品，包括非设计师	每 2 周
设计与工程同步会议	在站会上增加 15 分钟：“本次冲刺的设计工作即将开始”	每次冲刺
正式设计评审	里程碑前与 PM 分享一页决策文档，异步审批	每个里程碑
设计 QA 冲刺	在 PR 模板中加入 QA 检查清单——合并前由设计师审核	每个用户故事
回顾会议	在团队回顾中增加一个与设计有关的问题：“设计和实现在哪些地方出现了偏差？”	每次冲刺

精简交接

无法使用完整规格说明时：

1. 在上下文中添加注释。 直接在 Figma 画板上补充行为说明，不要另建规格文档
2. 优先说明模糊之处。 不必描述显而易见的内容。重点说明工程师可能需要猜测的状态、转换和边界情况
3. 过一遍流程，并记录问题。 一次 15 分钟的讲解电话，加上一份通过 Figma 评论回答工程师问题的清单，通常就够了
4. 尽早建立共同词汇。 如果你和工程师对组件名称和令牌用法达成一致，每次交接所需的说明就会更少

小胜利的力量

跟踪并传达你的影响，即使只是非正式地：

• “我们用 3 位用户测试了新流程——其中 2 位找不到保存按钮。我们调整了按钮位置后，该流程的支持工单减少了 40%”
• “假设地图显示，我们没有关于用户如何看待账单的信息。两次访谈后，我们在工程团队开始工作前重新设计了账单页面”
• “在 PR 中增加设计 QA 步骤，本季度发现了 12 个原本会随版本发布的视觉问题”

小胜利会累积起来。每一次都会让下一次关于设计投入的对话更容易展开。

---

常见错误

错误	为什么会失败	更好的做法
跳过冲刺地图日	团队会针对错误的问题构建解决方案	周一的地图绘制和目标选择是最有价值的一天
闭门设计	交付的工作与工程实际情况不符	每日或每周与工程团队同步设计
没有设计 QA 流程	视觉质量会随着时间推移而下降	每个故事都进行 QA，而不只是每次发布时
文档过多	30 页的规格文档没人看	只说明有歧义的部分，其余交给共享组件系统处理
文档不足	“你可以在 Figma 里看”	如果工程师必须开口询问，说明规格文档不完整
把交接当作一次性事件	把工作往墙的另一边一扔了事	交接是一场持续到实施阶段的对话
不做回顾	同样的错误会反复出现	每两周进行一次回顾，并明确具体行动项和负责人
将设计评审作为审批关卡	评审会变成政治博弈	评审旨在改进工作，而不是审批工作