这一批不是"怎么画一个按钮"，而是"UX 团队怎么把一团模糊的意图，变成排好优先级、有人负责、能交付、还能回头复盘的工作"。它跨越一个完整闭环：
定方向(策略/情绪板) → 排顺序(路线图+5 种优先级法+Pareto) → 把研究画成能沟通的图(互动地图/资产映射/旅程图/技能地图) → 管住下行风险(设计风险/UX 债务/断裂追踪) → 事后学习(复盘/事后分析) → 搞定人(利益相关者分析/访谈/跨团队/RACI/Scrum 职责)。
关键术语先打个底：利益相关者(Stakeholder)=对项目有兴趣、或你完成项目需要跟 ta 合作的任何人(CEO、PM、技术架构师、你的直属上级都算)；路线图(Roadmap)=战略层"未来要解决哪些问题"，不写"怎么做"(那是项目计划)；UX 债务(UX Debt)=已知但因优先级/时间被搁置的体验问题，像信用卡欠款会越滚越大；复盘(Retrospective)=迭代结束后定期照镜子，事后分析(Postmortem)=单个项目结束后的深度尸检。每节给心法 + Why + 反例。
一、UX 策略：定方向(复杂应用三阶段 · CASTLE · 情绪板)
策略层回答"我们要往哪走、用什么衡量、靠什么对齐视觉感觉"。三篇分别管：复杂场景下的研究打法、工作软件的衡量框架、视觉方向的快速对齐工具。
1.1 复杂应用设计的三阶段(UX Strategies for Complex-Application Design)
复杂应用(医疗、仓储、物流、金融风控、科研工具)的用户是领域专家，决策受公司规定、专业工具、行业法规多重约束——所以只研究"用户个人"不够，必须研究"用户所在的整个工作环境"。沿用设计思维三阶段，但每阶段都要升级手法：
| 阶段 | 普通做法 | 复杂应用升级 | 案例 |
|---|---|---|---|
| 理解 Understand | 访谈几个用户 | 研究整个行业(目标/术语/角色/限制)+ 去真实工作现场观察(设备共享、协作、噪音)+ 多角色多方法 | 给医院做软件前，跟着护士工作、旁听医疗会议，搞懂临床流程和规范 |
| 探索 Explore | 自由头脑风暴 | 把限制变成创意指南(先列法规/安全/数据要求再发散)+ 简单原型(草图/故事板)+ 与专家共同设计 | 医疗决策工具先整理隐私要求，再设计"提醒但不打扰"的警报 |
| 实现 Materialize | 实验室可用性测试 | 加真实场景对话/情境访谈/长时观察(测"有没有价值"不只"好不好用")+ 与专业人士合作评审 + 找不到专家先用内部同事(标注局限) | 测金融风控工具时，让用户处理"评估高风险贷款"的真实场景 |
心法：复杂应用里"用得对不对"比"好不好看"重要得多——错误代价高、领域知识深。Why：实验室测试看不到真实环境的判断力和专业知识，专家在真实工作中的隐性决策一测就丢。反例：在干净实验室里测仓储系统，完全错过了"工人戴手套、强光下看屏、边走边操作手持设备"这些真正决定成败的因素。
1.2 CASTLE 框架：给"非自愿使用"的工作软件做评估
Google 的 HEART 框架(Happiness 快乐/Engagement 参与/Adoption 使用/Retention 留存/Task success 任务成功)是为消费产品设计的——用户能自由选择用不用。但企业内部软件、政府工具是强制使用的，留存率这种指标毫无意义(员工没得选)。NNGroup 提出 CASTLE 专门补这个缺口：
| 字母 | 维度 | 衡量什么 | 示例衡量标准 |
|---|---|---|---|
| C | 认知负荷 Cognitive load | 完成任务要动多少脑筋(频繁跳页、心算、信息过载都加重) | NASA-TLX 问卷测心理负担 |
| A | 高级功能使用率 Advanced feature usage | 用户是否用了那些非必需但能提效的功能(个性化、加速工具) | 自定义面板的用户比例 |
| S | 满意度 Satisfaction | 工作软件不求"惊喜"，求"少挫败" | SEQ 问卷、分析"愤怒点击" |
| T | 任务效率 Task efficiency | 完成流程要多少时间和步骤 | 定量可用性测试测完成时间 |
| L | 学习性 Learnability | 新员工上手快慢、对帮助文档的依赖度 | 长期可用性测试看完成时间随时间下降 |
| E | 错误率 Errors | 用户操作失误 + 系统报错频率 | 分析系统验证错误日志 |
心法：和 HEART 一样，每个维度都要用 目标 Goals → 信号 Signals → 衡量 Measures 三段法落地(维度太宽不能直接量化)。Why：消费品在乎"让你想再来"，工作软件在乎"让你少痛快走"，衡量轴必须换。怎么选：不用追踪全部 6 个，挑当前最痛的几个；量化只告诉你"哪有问题"，根因还得靠定性研究(访谈、可用性测试)。CASTLE 是 HEART 的补充而非替代。
1.3 情绪板(Mood Board)：快速对齐视觉与情感方向
情绪板=由图像、视频帧、图案、文字组成的拼贴画，一眼传达某种"感觉"。在 UX 里用来让不懂设计的人也能理解"产品该长什么气质"，定主 UI 色彩与视觉身份。
- 何时用：新产品设计初期或重大改版的"定义 Define / 构思 Ideate"阶段，在做原型之前先对齐风格。
- 谁主导：UI/视觉/交互设计师发起，拉上产品负责人和内容管理者。建议做多个情绪板对比选方向。
- 6 步：① 审现有风格指南 → ② 选工具(物理板适合面对面但难共享；数字板 Miro/Mural/FigJam 适合远程) → ③ 选 4-5 个情绪关键词(用便签把同义词分组) → ④ 收集视觉素材(Pinterest/Google 图片，注意主题统一别混搭) → ⑤ 排版(关键素材放大居中、留白区分) → ⑥ 分享并讲清"为什么选这些"。
反例：堆一大堆产品截图当情绪板——那会把板子带偏向"功能参考"而非"情绪"，应改叫"竞品分析板/参考板"。情绪板的本职是传感觉(激励/活力/明亮)，不是抄界面。
二、路线图：排顺序(scope · 谁建何时建 · 5 种优先级法 · Pareto)
2.1 路线图 vs 项目计划 + 三层 scope(UX Roadmaps: Who, When, How Much Time)
| 对比 | 路线图 Roadmap | 项目计划 Project Plan |
|---|---|---|
| 性质 | 战略性、面向愿景、动态 | 执行性、追踪输出 |
| 内容 | 未来要解决哪些问题、目标 | 具体任务和步骤、怎么做 |
三层 scope(范围由大到小)：
| 类型 | 覆盖 | 谁负责 | 建多久 |
|---|---|---|---|
| 产品路线图 Product | UX + 市场 + 开发所有未来问题 | PM(高成熟度团队由产品/设计/开发领导共建) | 几天～数周/数月(含高层发现研究、愿景、对齐) |
| 领域路线图 Domain | 仅 UX 领域、对齐各 UX 部门 | UX 总监/负责人 | 多数 1 天内 |
| 专项路线图 Initiative | 单一 UX 领域(如用户研究)的子集 | 团队负责人/个人 | 多数 1 天内 |
- 何时建：新项目启动(定共同愿景)、目标偏离(重新对齐)、领导层变动(给新领导看方向)、年度规划(最常见)。
- 多频繁更新：月度例行更新——把已完成主题挪到"完成"列、更新优先级、加新主题；记录所有版本供新人参考。仅 34% 的人报告建路线图花超过 1 周；多数人每周到每月更新一次。
- 怎么展示(讲故事三栏法)：① 设背景(从哪来) → ② 展示近期已完成的进展 → ③ 展示"现在"和"近期"两栏的当前/即将任务 → ④ 最后才展示远期愿景。逐步展开避免信息过载，把讨论焦点钉在当前优先级上。
心法：路线图是"战略执行与任务管理之间的桥"。反例：把路线图写成详细甘特图列满任务和日期——那是项目计划，会把利益相关者拖进执行细节、丢掉"我们到底要解决什么问题"的战略对话。
2.2 五种优先级方法(5 Prioritization Methods in UX Roadmapping)
路线图上一堆候选问题，靠什么排序？这 5 种方法把"拍脑袋"换成"客观评估"，选哪种取决于项目特点和团队文化：
| 方法 | 怎么打分 | 产出 | 最适合 |
|---|---|---|---|
| 影响-努力矩阵 Impact-Effort Matrix | 二维投票(用户价值 × 实施难度) | 四象限：快速获益 Quick Wins(低投入高影响·优先)/重大投资 Big Bets(高投入高价值·慎重)/资源浪费 Money Pit(高投入低影响)/填充项 Fill-Ins(低投入低影响) | 想要直观可视化、跨职能投票(开发投努力、设计投影响) |
| 可行性-需求性-可持续性评分卡(IDEO) | 三标准打分：可行性 Feasibility(技术/资源)、需求性 Desirability(用户多想要)、可持续性 Viability(对业务长期是否有益) | 总分排序 | 想兼顾"能不能做/想不想要/赚不赚钱" |
| RICE 法(Intercom) | Reach×Impact×Confidence/Effort(覆盖人数×影响×信心/努力) | 数值分排序 | 项目量大、偏技术、想要纯数字裁决的团队 |
| MoSCoW 分析 | 四类：必须有 Must / 应该有 Should / 可以有 Could / 不需要 Won't | 加权投票分组 | 有明确时间/资源限制、要保底交付"必须有"的团队 |
| Kano 模型(狩野纪昭 1984) | 按功能性 × 满意度分四类：吸引类 Attractive(超预期)/绩效类 Performance(越多越满意)/无差别类 Indifferent/必备类 Must-Be(缺了就不满) | 需用户研究数据评满意度 | 重视用户期望、想区分"惊喜功能"和"基础底线"的团队 |
心法：没有"最好"的方法，找到合适的就按团队需求调整，并让利益相关者参与打分(参与=认同)。怎么选：要可视化拉对齐→影响-努力矩阵；项目多要可排序数字→RICE；时间硬约束要保底→MoSCoW；想分清基础 vs 加分功能→Kano。
2.3 Pareto 帕累托原则(80/20 法则)聚焦关键少数(Focus Your Design Tactics)
80% 的结果来自 20% 的原因(帕累托观察"花园里 80% 豌豆来自 20% 豆荚"，朱兰用于管理学)。广泛适用：20% 客户带来 80% 收入 / 20% 产品占 80% 销售 / 20% 问题导致 80% 投诉 / 20% 网站获 80% 流量。
- UX 用法：面对分析平台、调查、流量等海量数据容易"分析瘫痪"。先找出影响最大的 20%。实例：某 App 的 CSAT(客户满意度)下降，分析 Bug 追踪和工单发现 80% 的 Bug 集中在 4 个核心功能——优先修这 4 个，以较少投入换最大体验提升。
- 优势：减少无效数据处理、优化有限资源分配、快速提升用户满意度。
谨慎：别过度依赖。反例：只盯着"立刻影响 80% 结果"的问题，会忽略那些当下影响小、未来价值大的新兴需求——要留一部分资源做探索，平衡"优化已知"和"探索未知"。
三、UX 地图：把研究画成能沟通的东西(互动地图 · 资产映射 · 旅程图 · 技能地图)
地图类工具的共同目的：把研究发现可视化，让团队对齐、让利益相关者听懂。
3.1 互动式 UX 地图(Building Interactive UX Maps，两篇合并)
用 Figma/Sketch 把用户研究做成高保真、可点击的地图——点一下主题就弹出对应的用户原话、视频、照片证据。
- 优点：能叠加多媒体、按用户类型筛选不同旅程、帮观众理解复杂内容、提升利益相关者参与度。
- 缺点：耗时耗预算、要求熟练掌握设计软件高级功能(不熟反而做出难用的地图)。何时别做：已有非互动地图且临近展示——保持原样更划算。
- 制作步骤(两篇互补，合并为完整 8 步)：
- 整合低保真数据：把发现("用户担心新软件成本")逐条链接到证据(访谈视频/原话)。
- 建视觉设计系统：复用品牌样式或新建(字体/颜色/图标 + Figma 文本样式/颜色样式/变量/组件库)；做交互按钮的多状态(正常/悬停/点击)。
- 按内容类别分组：用 Figma 的 Section 工具把照片/视频/引语分块。
- 用自动布局 Auto Layout 搭骨架(标题/泳道/象限)：折叠面板展开时自动把下方内容往下推、不覆盖。
- 添加真实内容：替换占位文本和图标(用 Swap Instance 快速换图标)。
- 原型模式连交互：选元素→定交互类型(如点击显示叠加层)→设目标。
- 测试调整：至少拉一位同事测，发现叠加层没正确命名就回组件库查命名修复；用 Figma 注释记需改处。
- 存成模板：移除内容只留框架 + 加原型说明(讲清交互和限制)，组件发布到团队库，下次复用。
3.2 资产映射(Asset Mapping for Experience Consistency)
按时间顺序记录用户完成一个任务时遇到的所有界面和元素(网页截图、邮件、短信、推送、自助机照片)，用来检查全渠道一致性。
| 对比 | 资产映射 Asset Map | 客户旅程图 Customer Journey Map |
|---|---|---|
| 看什么 | 具体的界面/元素(截图、邮件) | 用户整体体验(想法、情感、动机) |
| 范围 | 小流程、公司自有渠道 | 大到小的旅程、可能超出公司控制 |
| 目的 | 查跨渠道一致性 | 理解用户整体体验、提供上下文 |
| 工作量 | 低(已有旅程图只需补素材) | 高(需深入用户研究) |
| 局限 | 不含情感动机(除非结合旅程图) | 不含用户实际看到的界面(除非结合资产图) |
- 5 步：① 选流程(从已有旅程图或重要任务如注册) → ② 在所有渠道走一遍并截图、按操作顺序排列标注渠道 → ③ 查 5 类不一致(核心功能/流程步骤/数据内容/语气风格/外观设计) → ④ 圈线标注问题、与相关部门讨论来源 → ⑤ 优先解决(先做低成本高影响的：改文案、统一视觉)。
- 好处：快速发现问题、打破部门壁垒、为设计系统找重复/缺失组件提供参考。实例：用户订宠物食品后短时间收到 6 封内容一致的邮件——资产映射一眼看出冗余，建议合并为 1-2 封。
心法：旅程图里加进真实界面截图，它就变成了资产映射——两者互补。资产映射是低成本快赢工具，即使组织级大问题没解决，也能展示小步快跑的成效。
3.3 旅程图的制作时间、角色与方法(How Much Time + How Practitioners，两篇 343 人调查)
两篇基于同一份 343 位从业者的调查，回答"做旅程图到底要花多久、谁参与、怎么做"。
(A) 时间投入——五步骤平均工时(几何平均，95% 置信区间)：
| 步骤 | 工时 |
|---|---|
| 进行外部用户研究 | 20.6 h |
| 综合研究见解 | 16.4 h |
| 收集内部利益相关者数据 | 10.2 h |
| 制作旅程图成果 | 9.9 h |
| 建立支持/获取资源 | 8.9 h |
| 总计 | 73.8 h ≈ 两周工作时间 |
- 机构 vs 内部团队：内部 79.8h 略多于机构 71.7h；机构在"制作成果"上花更多，内部在"获取支持/收集数据/综合见解"上花更多；从用户收集数据约 20h(基准≈至少半周)。
- 小公司 vs 大公司：大公司(≥500 人)平均 87h，小公司 64.9h，大公司每阶段都更久。洞察：无论规模，"获取支持和资源"投入都高——说明公司大 ≠ UX 成熟度高，都得花时间向利益相关者传达价值。
- 研究优先 vs 假设优先：假设优先并不省时，反而总流程花更多时间——跳过初步用户研究不是缩短项目的合理办法。
(B) 怎么做——典型方法趋势：
| 维度 | 发现 |
|---|---|
| 映射什么体验 | 89% 评估现有产品当前状态 / 73% 设想优化后未来状态 / 61% 构想全新产品 |
| 启动方式 | 62% 假设优先(跨职能研讨会用现有知识生成假设图) / 35% 研究优先(建议假设优先后跟进研究验证) |
| 研究方法 | 访谈最常用(86% 外部 / 76% 内部)；日记研究最少(12% 外部 / 6% 内部) |
| 谁参与 | UX/设计主导；跨学科：产品 70% / 市场 46% / 客服支持 42%；64% 协作创作、36% 独立；34% 用物理工具(便签纸)、30% 用数字工具(Miro/Mural/Sheets) |
| 组件来源 | 角色：49% 用现有角色、27% 项目研究中开发、14% 研讨会创建；旅程阶段：多在用户研究(31%)或研讨会(31%)中确定，少在初期识别 |
心法：研究表明各种差异(机构/内部、大/小公司、研究/假设优先)在统计上都不显著——所以没有放之四海的"标准时长"。怎么用：拿这组基准(总约两周、收集数据约半周)帮自己团队判断"该不该做旅程图、投入多深、用哪种方式"。
3.4 技能地图(Skill Mapping: A Digital Template for Remote Teams)
用雷达图可视化团队成员及整个团队的技能强弱(轴=技能、值=熟练度)，把个人图叠加成团队图。
- 3 大用途：① 了解团队构成(找技能空白) ② 招聘(让候选人自评、看与团队契合度) ③ 跟踪个人发展(季度/年度自评、定学习目标)。
- 两类分析：技能空白(团队完全缺某技能、评估是否必要) + 单点依赖(某技能只有一人会、要不要培养他人或招人)。
- 怎么用模板：Google Sheets 模板复制副本(Excel 版雷达图可能转换出错)→ 自定义技能(预设 8 项，可广义如"用户研究"或具体如"ANOVA 数据分析")→ 最多 10 名成员 → 1-5 分自评(1=只懂术语不能独立做、3=能偶尔独立应用、5=多项目表现卓越可指导他人)→ 填当前状态 + 未来目标(定时间框如 1 年内)→ 看自动生成的团队图 → 下载存档。
心法：当前状态 vs 未来目标的对比，正是团队讨论"该培训谁、该招什么人"的抓手。随团队规模和项目需求动态更新。
四、风险与债务：管住下行(设计风险 · UX 债务 · 断裂追踪)
4.1 设计风险(Design Risks: Assess, Mitigate, Manage)
设计风险=新/现有设计的某方面对业务或用户产生负面影响的可能性。风险 = 发生概率 × 影响程度。
6 步流程：① 确立组织目标(风险为何值得承担，对齐关键成功标准) → ② 识别风险因素(行为/态度研究、流程图、工单数据；新品看竞品研究) → ③ 评估风险(用风险评估矩阵按严重性×频率"标绘"风险等级) → ④ 制定减缓措施(降低概率或降低影响) → ⑤ 实施控制或做风险决策 → ⑥ 评估与监控(定期重评，措施会过时)。
风险评估矩阵(改编自美国陆军 ATP 5-19，单元格值=严重性×可能性的乘积)：
| 影响 \ 概率 | 不太可能 | 偶尔 Seldom | 偶尔出现 Occasional | 可能 Likely | 经常 Frequent |
|---|---|---|---|---|---|
| 轻微 Minimal | 低 | 低 | 中 | 中 | 高 |
| 中等 Moderate | 低 | 中 | 中 | 高 | 高 |
| 严重 Critical | 中 | 中 | 高 | 高 | 很高 |
| 灾难性 Catastrophic | 中 | 高 | 高 | 很高 | 很高 |
"单击购买"示例(电商目标=提升每访客收入)：
| 风险因素 | 缓解措施 | 缓解前 → 后 |
|---|---|---|
| 意外交易增加→支持成本上升 | 立即提供确认/取消选项、延迟 12 小时发货 | 中 → 低(概率和影响都降) |
| 欺诈交易增加→数据风险 | 要求 12-24 小时内验证确认 | 高 → 中 |
| 小批量订单增多→物流成本/碳排放 | 提供"立即发货/下批发货"两选项 | 高 → 中 |
心法：制定了缓解措施不代表一定要实施——第 5 步要权衡成本收益(如果措施拖慢流程又无显著收益就别做)。反例：试图"假设一切可能的风险"反而适得其反；对难控的外部风险，优先监控(风险初现时快速适应)而非穷举消灭。
4.2 UX 债务(UX Debt)
UX 债务=已知但因优先级/时间/资源被搁置的体验问题——像欠款，积累久了变成更大的体验障碍。
4 个关键步骤：① 承认问题存在(不忽视、不遗忘) → ② 跟踪(记进 backlog、电子表格或数据库；大公司任务多、债务易被新功能淹没，先用电子表格排优先级再进 backlog) → ③ 沟通汇报(用一致语言、共享状态/严重性图表，让利益相关者和领导看到优先级和修复进度) → ④ 制定修复计划(持续改进策略：每个 sprint 拨一些 story points，至少处理 1-2 个债务项)。
- 优先级与可视化：用优先级矩阵，按"用户价值 × 修复难度"画散点图——优先解决"对用户影响大 + 修复成本低"的(快速提升体验)。
心法：UX 债务无法完全避免，但通过承认/跟踪/沟通/规划修复可以有效管理，确保产品体验持续改进。
4.3 断裂追踪与采纳率 RAS(Why We Need to Track Breakage)
研究的传统问题是"我们学到了什么"，更重要的是"我们做了什么"。追踪断裂(Track Breakage)=找出研究建议在哪个环节失效了。
研究价值链(Value Chain of Research)：数据 Data → 发现 Finding → 洞察 Insight → 建议 Recommendation——越往右价值越高，最有价值的是能直接执行的建议。任一环断了，建议就失效，研究就白费。
示例链：HelpZone 首页点击数据 → "只有 0.03% 用户点了'精选文章'区" → 洞察"用户不看这区、白占空间" → 建议"删掉换成自助服务功能"。
断裂的早期信号：团队说"再研究一次"却说不清能改变什么决定 / 最重要的建议被轻描淡写带过 / 设计师绕开建议用现成组件凑合 / 写一堆文档但无任务、负责人、上线计划 / 管理层只会说"我们在做研究"说不出"因研究做了什么改变" / 研究员不再被邀请开会。
怎么修：把洞察变成具体可执行的建议(说清 what/who/when/how，避免"我们可以考虑…")→ 把建议加进产品计划当具体任务 → 上线后继续跟踪效果(设目标如"流失率从 X% 降到 Y%")→ 找出组织阻碍(找高层支持、组跨部门团队、规划会持续追踪)→ 在每个环节(研究→洞察→建议→上线)设追踪点(记负责人/状态/优先级/交付时间)。
RAS(Recommendation Adoption Score 建议采纳得分)——衡量建议是否被采纳、是否完整落地、价值是否传到用户，类似 OKR：
RAS = (Adoption × 0.5) + (Fidelity × 0.3) + (Impact × 0.2)
| 维度(权重) | 含义 | 0 → 1 量表 |
|---|---|---|
| Adoption 采纳(50%·最关键) | 有没有被做 | 0 未采纳 / 0.25 被弱化 / 0.5 部分采纳 / 0.75 大部分采纳(打折) / 1.0 完全采纳 |
| Fidelity 完整度(30%) | 实现质量 | 0 偏离用户问题 / 0.5 UI 交互不符方案效果打折 / 1.0 按原意完整实现 |
| Impact 影响度(20%·最难即时测) | 有没有改变用户行为 | 0 未上线或无影响 / 0.5 有趋势未验证 / 1.0 数据明确改善 |
结果解读：0.6-0.75 正常(健康有提升空间) / 0.75-0.9 高(优秀团队) / 0.9-1.0 极高(顶级成熟度)。
心法：重点不是追责，而是把"建议落地"当成可管理的目标。研究的价值不只是发现问题，更在于推动改变——把采纳率推成团队考核指标，每季度回顾哪些建议做了/没做/为什么。
五、复盘与事后分析：从成功失败中学习(Retrospectives · Postmortems)
两者都是"回头看"，但层级不同：复盘 Retrospective 是迭代结束后的定期反思(节奏型)，事后分析 Postmortem 是单个项目结束后的深度尸检(事件型)。
5.1 复盘会议四步法(Retrospectives 101)
复盘=团队定期反思最近工作、找改进方法的会(常与敏捷/Scrum 关联，但任何流程都适用)。
- 何时开 + 邀请谁：Scrum 团队每个 Sprint 结束后；无迭代则每两周/月/季度。全员参与——即使某角色只参与部分工作也要邀请(拿全面反馈)。
- 四步：
- 设定期望：会前发议程，会上立规矩——避免指责(说"我们这次没达成"而非"你导致了…")、专注团队改进、保持开放心态；用便签匿名写想法或轮流发言。
- 讨论做得好的：什么做得好？你喜欢什么？学到了什么？哪些工具/技术有帮助？(可认可个人但重点在团队成功。)
- 讨论待改进的：有什么不足？想减少什么？下次怎么做？哪些问题阻碍了进展？(帆船比喻：什么推动团队前进/什么拖慢/什么威胁成功。)
- 制定行动计划：每条改进分配负责人 + 完成日期；任务太大就拆小；记在团队可访问处。
- 会后跟进：下次复盘先检查上次行动计划、标记已完成、继续未完成的。
- 小贴士：轮换主持人、跟踪长期反复出现的问题、鼓励所有人参与(便签让内向者匿名贡献)、固定频率。还可做元回顾(Meta-retrospective)——反思你的复盘本身有没有用。
反例：如果长期没人提问题，不是没问题，可能是大家不敢说——需重新审视会议环境，确保是"无报复风险的安全空间"。
不同团队：产品团队最常用(日常协作密)；UX 团队聚焦设计流程/评估方法；领导团队反思新战略效果。
5.2 项目事后分析七要件(Project Postmortems for UX Teams)
Postmortem=项目结束后系统回顾"发生了什么、哪些决策有效/失败、为什么"。很多团队写成功 case study，却少记失败——但失败更能暴露真实限制(组织协作、时间压力、技术约束、对用户行为的误判)。目标是学习系统性原因，不是追责。
六大分析维度(不归因到某个稿子或某个人)：Research(研究是否够早够准、结论是否真影响决策) / Problem & Goals(需求指标是否清晰、有无目标漂移) / Design(方案依据、取舍记录) / Development(技术约束、交接是否顺畅) / Process(节点是否合理、是否常返工) / Communication(信息是否在对的时间给对的人)。
一场高质量复盘的 7 个必要条件：
| 要件 | 标准 |
|---|---|
| 1 对的人在场 | 核心成员 + PM/负责人 + 参与决策的利益相关者 + (可选)外部视角代表；控制在 6-10 人 |
| 2 清晰的成功标准 | 最好项目前就定指标；没有就在复盘开头先对齐"当初想达成什么" |
| 3 心理安全 | 明确"理解+改进系统、不责备个人"；必要时找无利害关系者做引导者 |
| 4 根因分析 | 用 5 Whys / 时间线复盘 / 资源分析 / 外部因素 追到"流程为什么没兜住"而非"谁犯错" |
| 5 可执行产出 | 改变系统的东西：新检查表、加评审门槛、更新文档、修工具；避免"加强沟通""更小心"这种空话 |
| 6 负责人 + deadline | 现场就定 owner 和 deadline；建议月度回看落地情况 |
| 7 记录归档 | 控制在 2-3 页：概览目标、成功指标与结果、关键根因、行动项(含负责人)、(可选)时间线 |
典型流程 7 步：会前准备对齐 → 收集证据(研究/设计/原型/测试/上线指标/反馈) → 还原时间线(需求→研究→设计→开发→上线，标关键决策点) → 识别结果与现象 → 分析根因 → 定义行动项(3-5 条最关键、具体可验证) → 分享归档(让后续项目能搜到复用)。
心法：持续复盘形成"组织级经验库"——减少重复错误、提升流程成熟度。前提是心理安全：否则团队会倾向隐藏问题，复盘就失去意义。
六、利益相关者：搞定人(分析 · 访谈 · 跨团队 · RACI · Scrum 职责)
6.1 利益相关者分析：权力-兴趣矩阵(Stakeholder Analysis for UX Projects)
何时做：新项目要和新利益相关者合作时、低 UX 成熟度团队想提高组织对用户中心设计的接受度时。先问自己：谁对项目感兴趣？谁有影响力/控制力/决策权？
权力-兴趣矩阵(Mendelow's Matrix)：
| 象限 | 位置 | 策略 | 例子 |
|---|---|---|---|
| 紧密管理 Manage Closely | 高权力 + 高兴趣 | 定期沟通、积极争取支持 | 要做资源分配的部门负责人、对设计有个人意见的 CEO |
| 保持满意 Keep Satisfied | 高权力 + 低兴趣 | 定期更新进展、确保潜在需求被满足 | 与项目间接相关但权力大的主管 |
| 保持告知 Keep Informed | 低权力 + 高兴趣 | 邀请参与设计评审或观察研究 | 项目相关的支持团队 |
| 监控 Monitor | 低权力 + 低兴趣 | 不花太多精力、定期关注防状态变化 | —— |
加"态度"维度(光有权力/兴趣不够)：积极(支持者)/中立(未表态)/消极(批评者)。用"+/−"标注或建表记录当前态度 vs 期望态度：
| 利益相关者 | 权力 | 兴趣 | 当前态度 | 期望态度 |
|---|---|---|---|---|
| Jane Smith(账户经理) | 高 | 低 | 中立 | 积极 |
| Joe Bloggs(产品经理) | 高 | 高 | 积极 | 积极 |
| Javinder Singh(技术架构师) | 低 | 低 | 消极 | 中立 |
心法：高权力但消极的人最值得花精力转化；低权力低兴趣的消极者可暂时忽略。利益相关者地图是动态的(领导变动、项目重点调整都会改变权力/兴趣)，要定期更新并调整策略。完成分析后制定管理计划(每周一对一、定期邮件更新、可跟踪的策略评估)。
6.2 利益相关者访谈(Stakeholder Interviews 101)
与对项目有既得利益的人对话，收集信息推动项目成功(类似用户访谈，但对象是利益相关者)。
- 为什么做：① 收集背景/历史(项目起源、已知限制、之前尝试，大组织里识别政治/历史因素避免后续摩擦) ② 明确商业目标 ③ 对齐共同愿景 ④ 增强支持(让对方感到被倾听)。
- 何时做：越早越好——项目启动、引入新利益相关者、项目遇到问题时。
- 怎么做 5 步：① 确定目标(识别担忧/障碍、技术限制、竞品市场、沟通偏好) → ② 准备问题(半结构化，大致框架引导深入；问角色职责、工作重点、成功标准、主要挑战、之前类似项目、希望如何参与) → ③ 建立融洽关系(自我介绍、表明保密无需迎合、明确时长) → ④ 实施(一对一、保持中立、开放式追问"能详细说说吗""为什么这对您重要""能举个具体例子吗") → ⑤ 总结跟进(问"还有谁我该聊？"拓展网络、发致谢邮件)。
- 备用：对方没时间→邮件发核心问题；大规模→问卷(但回馈率低)。
- 怎么用见解：≤5 人整理主题做成简单文件；>5 人用系统方法(主题分析 Thematic Analysis)标记发现、梳理核心主题。无论规模都能帮优化研究、优先级、时间表、资源规划。
6.3 跨研究团队协作(Partner with Other Research Teams)
UX 团队单扛所有用户研究既耗时又费力，跨部门合作能提效并增加洞察。
- 识别合作伙伴：数据分析团队(行为数据：访问量、点击率、跳出率)、SEO 团队(关键词/搜索意图)、客服团队(痛点、常见问题、满意度)。
- 深层优势：多维数据视角(UX 偏定性 + 他们偏定量)、完善用户画像、补充验证假设、快速决策支持(不必从头收集)。
- 互惠机制：参与对方研究(访谈里加客服关心的问题)、共同开发研究计划、公开认可对方贡献(增强信任)。
- 战略野心：让 UX 团队当全公司用户研究的中心节点——建统一研究数据库、制定研究标准、定期办数据分享会，最终推动组织转向"以用户为中心"的文化。
心法：这是比"做一个研究项目"高一层的战略动作——通过整合跨部门数据，UX 团队从"执行者"升级为"组织里的用户数据调度者"，提升长期影响力。
6.4 RACI 职责分配矩阵(Setting UX Roles and Responsibilities)
RACI=明确产品开发各阶段"谁干什么"的工具，预见协作点、避免混乱重复：
| 字母 | 角色 | 含义 |
|---|---|---|
| R | Responsible 负责 | 具体执行任务(可多人)，如研究员执行定量可用性测试 |
| A | Accountable 最终责任 | 审查并决定是否完成，每任务仅一人 |
| C | Consulted 咨询 | 提供建议/专业知识(可跨学科)，如 UX 经理给研究协议反馈 |
| I | Informed 知会 | 被通知进展，通常含利益相关者和领导层(客服、法律、营销) |
- 何时用：复盘后(发现有角色缺失/加入过晚) + 项目启动阶段(全团队共填、对齐)。在战略设定和发现阶段尤其有效(谁定愿景目标、谁做访谈、谁做竞争分析)。
- 怎么用：分配职责要超越职位描述，看技能/时间/经验(PM 有访谈技巧也能担 R/A，UX 主管在问题上做 C)；即使没空参与，UX 成员至少标 I(确保发现能影响 UX 工作)；同为 R 的人要协作并明确分工；R/A 要确保 C 和 I 在合适时间参与。
心法：RACI 帮团队形成"设计即过程"的文化，避免"逐一交接"的流水线模式。随时间推移团队会自然理解合作方式、可能不再依赖 RACI——但它是建立开放沟通的好基础。
6.5 Scrum 活动中的 UX 职责(Responsibilities in Scrum Events)
Scrum=敏捷方法，通过 2-4 周短期冲刺(Sprint)分阶段交付。UX 应参与所有 Scrum 会议——否则会失去对产品大局的把握、降低协作效率、导致设计与开发脱节。
| Scrum 活动 | 时机 | UX 职责 |
|---|---|---|
| 每日站会 Daily Scrum | 每天 ~15 分钟 | 同步三件事(昨天做了什么/今天做什么/遇到什么阻碍)；借机邀开发参与设计评审/头脑风暴；阻碍由 Scrum Master 帮解决 |
| 待办梳理 Backlog Refinement | 每冲刺中期 | 用研究反馈帮 PM 调优先级；展示草图/原型/初步研究结果；确保 UI/UX 相关任务有足够背景信息、设计文档、测试结果(避免开发因信息不足拖延) |
| 冲刺规划 Sprint Planning | 每冲刺开始 | 估算设计工作量(用"T 恤尺寸"S/M/L)；确保设计任务被记进 backlog(别被忽略);计划用户测试(大研究可建议降低冲刺工作量让开发参与) |
| 冲刺评审 Sprint Review/Demo | 冲刺最后一两天 | 支持产品负责人展示成果、解释设计逻辑；收集反馈并分类("待完成/需澄清/需说服") |
| 冲刺回顾 Retrospective | 每冲刺结束 | 讨论设计开发配合问题、提流程优化建议(加设计评审/用户测试时间)、提醒为赶进度牺牲的体验细节 |
心法：UX 在敏捷里的工作不只是提前为下一轮画原型，更要在当前冲刺里全程参与会议、保持与开发的紧密协作——参与会议是"保持全局掌握 + 确保设计被正确实现"的关键。
源自 NNGroup Topics / Organization & Design Process - UX设计工作(策略与路线图子集，21 篇)。可用性测试与十大启发式见 NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估)；设计流程、UX 团队管理、UX 成熟度见 NNGroup 设计流程与交付物(17 篇 · 探索心态/CSD矩阵/启动项目·线框与协作草图/Promptframes·低保真vs高保真原型·设计规格spec/交付物术语50+/最常用交付物·专家评审/工作坊引导·故事板·过程中的问卷) / NNGroup UX 团队组织与运营(DesignOps 5 结构 · 集中/嵌入/矩阵汇报 · MUXI · RACI · 角色职责 · 入职 30/60/90 · UX 研究计划 PET(S) · 设计思维强团队 · 团队决策质量:确认偏误/群体思维/书写思考 · UX 6 阶成熟度与最大挑战 · Refine/Remodel/Rebuild) / NNGroup UX 成熟度模型(6 阶段 · 4 因素 · 活系统视角)。"Building Interactive UX Maps" 原为两篇(指南 + 案例步骤)，已合并为 §3.1 的完整 8 步。图片、视频(interactive-maps-recording.mp4 等)、PDF 与原档保留在 sources。
来源与关联资料
- NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估)
- NNGroup 设计流程与交付物(17 篇 · 探索心态/CSD矩阵/启动项目·线框与协作草图/Promptframes·低保真vs高保真原型·设计规格spec/交付物术语50+/最常用交付物·专家评审/工作坊引导·故事板·过程中的问卷)
- NNGroup UX 团队组织与运营(DesignOps 5 结构 · 集中/嵌入/矩阵汇报 · MUXI · RACI · 角色职责 · 入职 30/60/90 · UX 研究计划 PET(S) · 设计思维强团队 · 团队决策质量:确认偏误/群体思维/书写思考 · UX 6 阶成熟度与最大挑战 · Refine/Remodel/Rebuild)
- NNGroup UX 成熟度模型(6 阶段 · 4 因素 · 活系统视角)