NNGroup UX 策略·路线图·地图·风险债务·复盘·利益相关者(21 articles · UX策略/复杂应用三阶段/CASTLE/情绪板 · 路线图角色时间+5种优先级法+Pareto · 互动地图/资产映射/旅程图制作时间73.8h/技能地图 · 设计风险6步+UX债务+断裂追踪RAS · Retrospective四步/Postmortem七要件 · 利益相关者权力兴趣矩阵+访谈+跨团队+RACI+Scrum职责)

这一批不是"怎么画一个按钮"，而是"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 步)：
1. 整合低保真数据：把发现("用户担心新软件成本")逐条链接到证据(访谈视频/原话)。
2. 建视觉设计系统：复用品牌样式或新建(字体/颜色/图标 + Figma 文本样式/颜色样式/变量/组件库)；做交互按钮的多状态(正常/悬停/点击)。
3. 按内容类别分组：用 Figma 的 Section 工具把照片/视频/引语分块。
4. 用自动布局 Auto Layout 搭骨架(标题/泳道/象限)：折叠面板展开时自动把下方内容往下推、不覆盖。
5. 添加真实内容：替换占位文本和图标(用 Swap Instance 快速换图标)。
6. 原型模式连交互：选元素→定交互类型(如点击显示叠加层)→设目标。
7. 测试调整：至少拉一位同事测，发现叠加层没正确命名就回组件库查命名修复；用 Figma 注释记需改处。
8. 存成模板：移除内容只留框架 + 加原型说明(讲清交互和限制)，组件发布到团队库，下次复用。

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 结束后；无迭代则每两周/月/季度。全员参与——即使某角色只参与部分工作也要邀请(拿全面反馈)。
四步：
1. 设定期望：会前发议程，会上立规矩——避免指责(说"我们这次没达成"而非"你导致了…")、专注团队改进、保持开放心态；用便签匿名写想法或轮流发言。
2. 讨论做得好的：什么做得好？你喜欢什么？学到了什么？哪些工具/技术有帮助？(可认可个人但重点在团队成功。)
3. 讨论待改进的：有什么不足？想减少什么？下次怎么做？哪些问题阻碍了进展？(帆船比喻：什么推动团队前进/什么拖慢/什么威胁成功。)
4. 制定行动计划：每条改进分配负责人 + 完成日期；任务太大就拆小；记在团队可访问处。
会后跟进：下次复盘先检查上次行动计划、标记已完成、继续未完成的。
小贴士：轮换主持人、跟踪长期反复出现的问题、鼓励所有人参与(便签让内向者匿名贡献)、固定频率。还可做元回顾(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。