一句话:敏捷(Agile)本是为"开发者更快交付"设计的,UX 是后来才挤进去的客人。这 13 篇讲的全是同一件事——怎么让"理解用户"这件慢工,跟上"两三周一个冲刺(Sprint)、持续交付"的快节奏,而不被挤掉。
先理清几个反复出现的词,后面不再重复解释:
- 敏捷 Agile:一种开发哲学,核心是"小步快跑、持续交付、拥抱变化",对立面是"瀑布模型 Waterfall"(把需求→设计→开发→测试排成一条直线,一次走完)。
- 冲刺 Sprint / 迭代 Iteration:敏捷把工作切成 2-3 周一段的小周期,每段交付一点可用的东西。
- Scrum:最流行的敏捷落地框架,带一套固定仪式(每日站会 daily scrum、计划会、回顾会、待办梳理会)。
- 产品待办列表 Backlog:一份排好优先级的"待做清单",条目通常写成"用户故事(User Story)"——格式"作为<某类用户>,我需要<做某事>,以便<达成某目的>"。
- MVP 最小可行产品 Minimum Viable Product:全篇最大争议点,单开一节讲。
六块:现状 + 十大 Tips → 探索 Discovery → MVP 三派之争 → 研究纳入 backlog → Lean UX 文档 → 协作活动/内容/设计思维/Mozilla ROI 实证。
一、现状盘点:UX 在敏捷里到底混得怎样
NNGroup 调查项目经理、设计师、研究员、工程师后的画像。心法:敏捷对 UX 不是天敌也不是天堂——它早发现问题、快交付,但因为"为开发者而生",UX 的话语权天然偏弱,得靠成熟度和主动性挣回来。
| 数据点 | 数字 | 说明 |
|---|---|---|
| 敏捷普及率 | 69% 项目用敏捷(2008 年仅 40%) | 已是主流,但远未一统 |
| 混合模式 | 22% 团队"瀑布做需求设计 + 敏捷做开发" | 说明纯敏捷仍难落地,很多团队在妥协 |
| 团队 UX 占比 | 17% 成员是 UX 专业人员 | 比过去高,但"加人 ≠ 必然成功" |
| 成熟门槛 | 成功团队多有 >3 年敏捷经验 | 敏捷需要数年打磨,新团队别因初期混乱气馁 |
| UX 影响力评分 | 平均 4.0 / 7 分 | UX 在敏捷里仍偏弱,有提升空间 |
成熟敏捷 UX 团队的 6 个特征:① 敏捷经验 >3 年;② 协作文化、角色明确、共担质量;③ UX 工作领先于开发冲刺(交接点有清晰共识);④ UX 从业者主动(不等需求上门,主动做研究、找市场机会);⑤ 设立正式流程审批用户故事,挡掉外部突发需求,保护用户中心设计;⑥ UX 角色从"画图者"扩张成"领导者/推动者"(把用户需求翻译成商业需求,讲给利益相关者听)。
反例:只往团队里塞 UX 人头、却不给话语权和领先时间,UX 仍是开发的附庸,影响力评分上不去。
十大实战 Tips(125 位敏捷从业者总结)
来自 125 位一线从业者(设计师/开发/产品负责人/PM)的经验汇总。怎么用:这 10 条不是按重要性排序的清单,是一个"工具箱"——团队成熟度不同,先抓最痛的那几条。
| # | Tip | 心法 / 为什么 | 落地要点 |
|---|---|---|---|
| 1 | 留出发布规划 + 故事映射(Story Mapping)时间 | 前期规划省后期返工 | 项目初期梳理用户旅程、识别机会、给故事分类排序 |
| 2 | 冲刺开始前完成 UX 活动 | 设计和开发很难在同一冲刺同步完成 | 设计师提前 1-2 个冲刺出线框图/用户流/原型,开发再据此编码 |
| 3 | 培养协作文化 | 敏捷宣言:"个人与交互重于流程与工具" | 设计思维、头脑风暴、体验旅程图打破信息孤岛 |
| 4 | 强调迭代而非完美 | 低保真快反馈,早发现问题省大返工 | 从草图/线框起步,别过早纠结美学细节 |
| 5 | 参与每日站会(daily scrum) | 占用一点时间换全员同步、误解减少 | 限制发言时长,保持高效简洁 |
| 6 | 把用户研究变成团队活动 | 全员看真实用户 = 设计决策有共识 | 拉开发和 PM 一起观察可用性测试 |
| 7 | 确保利益相关者强力参与 | 早参与 = 明确方向 + 关键决策有支持 | 建领导团队、邀客户参与测试、定期高层汇报 |
| 8 | 明确角色与职责 | 传统敏捷没定义 UX 角色,易混乱 | 设计师主动讲清 UX 在流程里的位置;配强 scrum master |
| 9 | 办培训 + 入职指导 | 团队常流动重组,认知要拉齐 | "午餐学习会"等轻量形式,跨职能培训 |
| 10 | 不断调整直到找到合适的 | 敏捷是框架不是教条,允许自我反思 | 通过回顾会去掉不必要的复杂性,让团队自主选用敏捷元素 |
二、探索 Discovery:缩小范围,而不是跳过它
探索(Discovery) = 开发动手前,先搞清"问题是什么、机会在哪、关键假设成不成立"。敏捷团队最常见的错误:时间紧就把探索整个砍掉,直接开发。心法:敏捷不是"赶快做完",是"用持续的小增量交付高价值"——探索是这个价值的地基。正确做法是缩小探索范围(只验最关键的假设),不是跳过。
SCALE 五步法(探索怎么在敏捷里执行):
| 字母 | 步骤 | 做什么 |
|---|---|---|
| S | Speak and Spike | 跟团队和利益相关者沟通,提前规划探索,在迭代计划里加入 spike 时间(spike = 专门留给"先研究一下不确定的东西"的时间块) |
| C | Capture Alignment and Gaps | 记录团队的共识与认知盲区,有分歧就做研究去填 |
| A | Assign Activities | 把探索任务分给合适的人——不只是 UX 或 PM 的活 |
| L | Learn and Share | 边做边分享,别等探索全做完才一次性分析 |
| E | Evaluate and Decide | 定期评估"信息够不够了",团队共同决定下一步 |
支持探索落地的 4 个关键因素:① 高层支持(管理层不懂探索价值,团队就拿不到时间和资源——UX/产品负责人要去争取);② 跟踪探索的价值(用数据证明探索如何加快决策、提升质量,打消"只看开发速度"者的顾虑);③ 别提前开发(探索没完就动手,信息不足易返工浪费);④ 复用模板(任务分配表、调研问题、记录模板现成化,提效)。
反例:为赶进度跳过探索 → 开发中途才发现问题或信息不足 → 大量返工,反而更慢。
三、MVP 三派之争:这是全篇最大的争议点
4 篇笔记围着 MVP 打架,值得单开一节。核心矛盾:MVP 的本意 vs 现实中的误读。MVP 的真本意(源自《精益创业 Lean Startup》,更早是丰田精益制造):一个产品/功能的最简版本,但要简到刚好够团队判断"用户是否真的能从中获得价值"——本质是一次实验,失败了就该愿意放弃或调整想法。最大误读:把 MVP 当成"发布第一版(Release 1)"或"每两周凑出来的半成品"。
三派观点对照:
| 立场 | 来自哪篇 | 主张 | 适用前提 |
|---|---|---|---|
| 正本清源派 | 《MVP 不一定是 Release 1》《Minimum Viable Product》 | MVP = 验证假设的实验,常可用原型/模拟代替真发布 | 想低成本快速试错时 |
| 误读批判派 | 《Why MVP Is the Antithesis of Good UX》 | 多数公司被"快速验证"绑架,产出割裂、平庸、不迭代的烂体验 | 团队目标是做高质量成品、不是每两周证明给投资人看 |
| 重新定义派 | 同上 | 把"可行(Viable)"做实:MVP 要够打磨、可用、能吸引用户 | 现代成熟团队,有现成客户 |
误读派点名的 4 宗罪(《Why MVP Is the Antithesis of Good UX》):① 根本不做可用性测试,或只在上线后让付费用户当小白鼠,负面口碑发酵;② MVP 与最终愿景差太远——"拿用户对帐篷的反馈,去验证一座豪宅",反馈无意义;③ 只盯局部功能,拼起来缺整体连贯性,体验割裂;④ 推出后即使反馈很差也不迭代,违背 MVP 的迭代内核。
重新定义派的解法:如果 MVP 模式在你团队不提效,就重新定义"最小可行"——MVP 不该是仓促半成品,而应经过充分研究、有实际意义、可用、上市前能吸引用户。关键认知:精益创业里 MVP 适合"资金有限、没现成客户、投资人紧盯"的初创;而很多今天用 MVP 的公司根本不需要"每两周证明一次",他们要的是高质量成品,别照搬初创打法。
MVP 风险-回报矩阵:什么时候才值得做 MVP
怎么用:潜在回报越大、越值得先用 MVP 测;但具体用哪种 MVP,看风险高低。
| 高回报 | 低回报 | |
|---|---|---|
| 高风险 | 先用原型 MVP 测(值得做,但不确定性高,先便宜地试) | 降优先级或重做问题定义(又危险又不赚,不值得推进) |
| 低风险 | 可上代码 MVP(方向大概率靠谱,值得到真实市场看真实行为) | 先不专门做 MVP(收益不大,没必要花精力) |
两类假设:价值主张假设 vs 方案假设
MVP 要先后回答两个问题,对应两类假设。别搞反顺序:先证"用户觉得有价值吗",再证"我这个具体做法能不能交付出这份价值"。
| 假设 | 英文 | 回答的问题 | 谁先验 |
|---|---|---|---|
| 价值主张假设 | Value-Proposition Hypothesis | 用户是否觉得这东西有价值 | 第一步,适合用原型 MVP 快速低风险测 |
| 方案假设 | Solution Hypothesis | 这个具体做法能不能真把价值交付出来 | 第二步 |
价值主张假设的标准写法:"我们相信 [某个价值] 对 [某类人] 有价值。如果测试中看到 [某种行为信号],就说明这个假设成立。" —— 本质是给"拉新、留存、增长"设明确的、可观测的成功门槛。
示例(AI 投资助手):给想存钱投资的年轻职场人做轻量 AI 投资助手,连银行账户给个性化建议。首月试点门槛:≥30% 首次会话完成设置、≥30% 首周按建议行动、≥30% 首次行动后 7 天内回来。全达成 = 假设成立;只达成"设置+行动"但回访不足 30% = 能打动人但持续价值不够(部分支持);一个都没达成 = 假设不成立。
6 类 MVP 指标(原型 MVP 测价值主张假设时看什么)
前提:已做过一点前期探索,知道问题是什么、影响谁。
| 维度 | 测什么 | 示例指标 |
|---|---|---|
| 参与度 Engagement | 用得多积极 | 完成新手引导比例;每会话平均用功能数 |
| 留存 Retention | 会不会回来 | 7 天回访比例;在哪一步流失最多 |
| 宏转化 Macro-conversions | 是否完成直接影响收入的关键行为 | 免费试用转付费比例;完成注册比例 |
| 微转化 Micro-conversions | 是否完成接近转化的小动作 | 点"了解更多"比例;加入愿望单比例 |
| 系统性能 System-performance | 规模下是否稳定可靠 | 高峰页面加载时间;失败/超时交易比例 |
| AI 表现 AI-performance | AI 输出准不准、可靠不可靠 | AI 推荐被认为相关/准确的比例 |
怎么向利益相关者描述 MVP,争取支持
① 明确 MVP 目标——说清在验哪个假设、它和哪个具体业务决策绑定(查转化问题?还是查市场可行性?);② 把 MVP 说成实验——除非真是正式发布,别用 "launch / release",改用 "pilot / experiment / learning test",强调它是验证不是定版;③ 把计划讲清楚——测什么假设、用什么 MVP、看哪些指标、什么结果算"支持 / 部分支持 / 不支持"。
心法贯穿全节:MVP 失败也是宝贵知识("这个想法不值得继续"本身就值钱)。把它框定成实验,既设对预期,也保护团队不被"必须上线"的压力裹挟。
四、把"理解用户"塞进 backlog:研究 / 假设 / 事实都要可追踪
核心痛点:敏捷以"具体功能"为单位切任务,而用户研究产出的是学习成果(outcome)而非可立即上线的代码/设计(output),所以研究天然不适配两三周的冲刺,容易被忽略。心法:关注 outcome(功能带来的实际价值)而非 output(功能本身的交付)——研究就是敏捷"应对变化"所需的"持续学习"驱动力。
4.1 把研究当用户故事写进 backlog
研究在敏捷里的三大挑战:① 一次完整研究常跨多个迭代,待办事项长期开放;② 研究结果没进 backlog,听到了却不行动;③ 产出是"学习"不是代码,团队不知如何处理。
解法——把研究当成和设计/开发平级的待办:① 把研究作为单个待办事项/用户故事加进 backlog;② 拆成小任务(招募、安排、做测试、分析数据、汇报);③ 迭代中逐项标记完成。
示例(可用性测试 6 名参与者,测快捷键):每位参与者 = 一组"招募+安排+测试"任务,外加"分析数据"和"汇报结果"任务。可跨冲刺分阶段完成——第一个冲刺末:已招安排 3 人、正招第 4 人、完成 1 场测试;下个冲刺末:6 人招满、半数访谈完成、前半数据已分析,冲刺评审时给初步模式或进度报告。研究完成后产出的(问题修复/UX 债务/新功能机会/未来研究机会)全部回流进 backlog,不许搁置。
4.2 问题 → 假设 → 事实:用知识板降风险
背景:敏捷团队受时间预算所限,常对用户需求先假设后验证(理想是数据驱动,现实是边猜边证)。风险:假设被误当成事实,带偏整个项目。解法:用一块知识板(Kanban 看板最推荐)把四个阶段分列追踪,卡片随验证进度从左列移到右列。
| 阶段 | 含义 | 一句话 |
|---|---|---|
| 1 问题 Questions | 我们不知道的部分 | 围绕将开发的功能,头脑风暴用户行为/态度/动机的认知空白 |
| 2 假设 Assumptions | 我们以为知道的部分 | 基于画像/早期调研/利益相关者反馈;必须记录来源 + 验证计划 |
| 3 研究 Research | 验证假设的过程 | 用户测试/实地调研/数据分析/访谈;证伪就改假设继续,证实就进下一阶段 |
| 4 事实 Facts | 已用数据确认的知识 | 记录在案 + 定期回顾,确保团队认知一致 |
示例链条(离线功能):问题"用户想离线用 App 吗?" → 假设"用户常在没网的地下室用(来源:利益相关者 10/31 反馈)" → 研究"实地观察发现匹配主要画像的参与者半数工作日在地下室、无稳定网络" → 事实"用户确实需要离线功能"。记录工具可选 Kanban(Trello / 物理板,最推荐,直观看到卡片处于哪个阶段)、项目管理软件(Jira,与 backlog 同管)、或结构清晰的文本文件(Google Drive/Dropbox/SharePoint)。
五、Lean UX 文档:少即是多,但别不写
常见误区:敏捷追求"最小文档化",有人就理解成"不写或少写文档 = 高效"。真相:文档是公司的"记忆"——没记录,团队反复回忆、重新讨论早已定好的事,效率反而下降。心法:不是"不写",是"只写对的"——写之前先问两件事。
| 写文档前先问 | 怎么用 |
|---|---|
| 给谁看? | 给领导看还是给团队看?受众不同,细节深度和优先级就不同;只记受众真正关心的 |
| 目的是什么? | 提供背景?让未来记得决策?汇报进展?目的定了再决定写哪些细节 |
两条总原则:少即是多(只写设计意图、决策依据、功能怎么工作等关键点,太详细没人看);持续迭代、及时更新(别等项目末期才写,随研究推进随时更新)。
两个"必须有简洁文档"的时刻:① 项目开始前——记计划概要(做什么/为什么)、影响与责任人、时间框定(关键日期);② 项目中发生变化时(敏捷核心是应对变化)——逐步记录变化(别等结束)、尽量在现有工具里更新(JIRA / Slack 讨论组 / 设计系统,别每次新建文档)、明确后续责任人和未决事项。
每周 UX 周报怎么写(给团队同步学习成果和进展,避免信息过载):团队/产品名 · 时间范围 · 量化指标进展(转化率/增长等) · 正面反馈(用户研究的积极信号) · 负面反馈(待改进问题) · 团队动态(趣事/新趋势/新工具,增凝聚力)。注意事项:别用冗长 PPT/复杂图表,简短邮件或总结更有效(可起个有趣名字如"UX 反馈周五",让人期待);数据简洁突出重点;按主题分组反馈,别一股脑堆。
六、协作设计 / 内容规划 / 设计思维 / ROI 实证
6.1 三个协作设计活动:让设计成为团队的事
心法:在敏捷里设计是团队共同责任,不是 UX 一个人的活。引入协作活动能减轻设计师负担、打破信息孤岛、加快决策。怎么选:看团队大小 + 是当前迭代还是未来迭代的需求。引入技巧:从小规模起步,塞进现有 Scrum 会议(计划会/待办梳理会)抽一小段时间,别新增会议负担。
| 活动 | 适合 | 怎么做 | 用在何时 |
|---|---|---|---|
| 6-Up 1-Up | 大团队 / 设计未来功能 | ① 6-up:每人 5 分钟画最多 6 个同一功能的草图(重构思不重画工)→ ② 讨论找共性和潜力创意 → ③ 1-up:每人选一个用 5 分钟细化 → ④ 最终讨论选最佳或融合 | 为未来迭代提前准备,让成员熟悉彼此思路 |
| 白板会议 Whiteboarding | 小团队 / 需快速实现的功能 | 设明确目标(具体需求/用户角色/验收标准)→ 成员自由在白板上画并共同完善;开发/PM/设计师同空间就技术可行性、一致性达成共识 | 当前迭代的设计需求(快出方案,减少后期沟通修改) |
| 电话游戏 Telephone Game | 大团队 / 后续迭代功能 | 成员依次在草图/线框上添加自己的想法,每人 1-2 分钟改进上一位的设计再传下去,直到无法再扩展 | 激发创造力 + 熟悉他人设计,增量演化出新方案 |
6.2 内容创作的五种用户故事:别让内容被仓促带过
痛点:敏捷用用户故事追踪 UX 和开发,但内容创作的工作量常被低估,导致内容被仓促完成甚至忽略。解法:在 backlog 里为内容的全生命周期各建专门的用户故事。
| # | 内容用户故事 | 作用 | 示例(银行/首套房贷场景) |
|---|---|---|---|
| 1 | 内容调研 Content Spikes | 创作前先调研,理解用户需求打基础 | "作为内容创作者,我需要了解首次购房者对房贷的疑问,以便提供正确答案" |
| 2 | 内容创作 Content Creation | 为"按用户需求创作"预留足够时间 | "作为首次购房者,我需要了解房贷申请流程,这样看房时不那么困惑" |
| 3 | 内容审查 Content Review | 留时间与市场/法律/设计审查准确性、品牌一致性、合规;并留修改时间 | "作为内容创作者,我需要与运营/市场/合规一起审查内容" |
| 4 | 内容发布与管理 Content Publication & Management | 规划发布、调度、审查乃至下线的全生命周期 | "作为内容管理员,我需要撰写高质量元数据,确保内容在搜索结果页显示" |
| 5 | 内容测试与优化 Content Testing & Optimization | 上线后持续测试、分析反馈、优化 | "作为内容创作者,我需要了解首次购房者与银行的沟通方式,以便添加支持文案" |
6.3 设计思维 + 敏捷:手电筒模型
关系:设计思维(Design Thinking)负责"深入理解问题",敏捷负责"快速交付方案"——两者不是二选一,而是互补。设计思维(Design Thinking)、精益(Lean)、敏捷(Agile)这些流行词常被当成对立选项,其实能很好结合。
手电筒模型(比喻):把设计师在敏捷里的工作比作手电筒光束——照得最近最亮 = 当前冲刺里明确、聚焦的任务;照得越远越暗 = 未来冲刺里越模糊、越需进一步定义的任务。越靠近未来,越需要更多时间精力去厘清。
设计思维五(六)阶段对应敏捷的冲刺远近:
| 阶段 | 目标 | 落在哪个冲刺类别 |
|---|---|---|
| 共情 Empathize | 通过研究理解用户、建画像 | 未来冲刺(项目初期研究,打基础) |
| 定义 Define | 整合研究、找痛点、识别业务机会与问题 | 未来冲刺(理解问题,不急着出方案) |
| 构思 Ideate | 头脑风暴多种创意 | 即将开始的冲刺(需时间细化评估) |
| 原型 Prototype | 为部分想法建原型 | 即将开始 / 下一冲刺(看待办明确度) |
| 测试 Test | 用用户反馈验证原型 | 即将开始的冲刺 |
| 实施 Implement | 设计落地,支持开发 | 当前冲刺(全力支持开发,确保任务按计划推进) |
心法:敏捷里设计师的工作节奏常显得难以预测——用"任务离当前冲刺多远"来判断该投多少精力,就能在快节奏里找到平衡,与开发保持一致。
6.4 Mozilla 案例:迭代测试让客服请求降 70% 的 ROI 实证
这是全篇唯一一个带硬核数字的真实案例,用来向高层证明 UX 投入的回报(ROI)。Mozilla(Firefox 母公司,非营利开源组织)的支持网站年访数百万,是全球访问量最大的支持站之一。
痛点:① 帮助文档约 400 页,用户难找到所需信息;② 客服(员工+志愿者)跟不上 Firefox 快速更新带来的海量提问;③ 写更多文章反而让查找更复杂(内容越多越难找的悖论)。
团队(3 人):Susan Farrell(NNGroup 高级 UX 专家,负责研究/数据发现/分析/改进建议)、Crystal Beasley(Mozilla 产品设计师/项目负责人,纸原型测试时扮"电脑"模拟交互)、Bram Pitoyo(Web UX 设计师,设计任务流和原型)。
方法:① 数据发现与分析(UX 数据 + 行为数据如常见问题/流量/搜索 + 内容结构分析);② 员工访谈(视频通话挖痛点);③ 信息架构(IA)测试(卡片分类法 + 树状测试);④ 任务流程测试(纸质原型,测桌面和移动)。亮点工作流:利用雅加达与波特兰 14 小时时差实现 24 小时连轴——白天波特兰测,晚上 Bram 在雅加达改设计发 PDF,次日打印新原型,2 周内完成 7 轮关键页面迭代,证明"可用性测试也能很敏捷"。
成果(ROI 硬数据):
| 指标 | 改版前 | 改版后 |
|---|---|---|
| 论坛新问题数 | 约 7000 个/月 | 约 2000 个/月(降约 70%,每月少 5000 个) |
| 24h 内问题应答率 | 40%–60% | 80%–90% |
过渡技巧:正式上线前,先在主页加快速链接导航当临时方案,验证"直达最常见内容能否减少进论坛的新问题"——快链通常是烂导航的权宜之计,但这里用来低成本验证最常见信息的可用性,为新 IA 提供依据。
三条经验:① 支持站的核心是解决不断变化的常见问题,要定期分析数据更新文档,让客服专注更复杂的新问题;② 数据挖掘发现问题、数据分析验证方案,基于数据的成功推动了资源获取和持续改进;③ 跨地域团队靠紧密协作、统一愿景达成成功。心法:这就是给高层看的"UX 投资几乎立刻产生可衡量回报"的强证据 + 纸质原型有效性的样本。
源自 NNGroup Topics / Agile - 敏捷开发(13 篇)。可用性测试与 5 人法则、定性数据分析见 NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估) / NNGroup 定性研究与研究方法工具箱(方法全景/访谈/共情图/样本量/任务设计/主持/专家评估/工作坊/伦理);团队管理与设计流程组织见 NNGroup UX 团队组织与运营(DesignOps 5 结构 · 集中/嵌入/矩阵汇报 · MUXI · RACI · 角色职责 · 入职 30/60/90 · UX 研究计划 PET(S) · 设计思维强团队 · 团队决策质量:确认偏误/群体思维/书写思考 · UX 6 阶成熟度与最大挑战 · Refine/Remodel/Rebuild) / NNGroup 设计流程与交付物(17 篇 · 探索心态/CSD矩阵/启动项目·线框与协作草图/Promptframes·低保真vs高保真原型·设计规格spec/交付物术语50+/最常用交付物·专家评审/工作坊引导·故事板·过程中的问卷)。图片/原档(含 Mozilla 问题曲线图、MVP 风险-回报矩阵、知识板看板、手电筒模型等截图)保留在 sources。
来源与关联资料
- NNGroup UX 团队组织与运营(DesignOps 5 结构 · 集中/嵌入/矩阵汇报 · MUXI · RACI · 角色职责 · 入职 30/60/90 · UX 研究计划 PET(S) · 设计思维强团队 · 团队决策质量:确认偏误/群体思维/书写思考 · UX 6 阶成熟度与最大挑战 · Refine/Remodel/Rebuild)
- NNGroup 设计流程与交付物(17 篇 · 探索心态/CSD矩阵/启动项目·线框与协作草图/Promptframes·低保真vs高保真原型·设计规格spec/交付物术语50+/最常用交付物·专家评审/工作坊引导·故事板·过程中的问卷)
- NNGroup 定性研究与研究方法工具箱(方法全景/访谈/共情图/样本量/任务设计/主持/专家评估/工作坊/伦理)