这一整批笔记都围绕一句话:怎么把"一个真实的人为了达成某个目标，跨越好几天/好几个渠道，和你的产品或服务打交道的整个过程"画出来、看明白、改进它。 关键词是"跨时间、跨渠道、看全程"——它和"用户在某个界面里点了哪几步(用户流程 User Flow)"不是一回事，也和"我们内部哪个部门做了什么(服务蓝图 Service Blueprint)"不是一回事。
全文按一条"由表及里"的链条分八块:
① 旅程地图本体(什么是 Journey Map、五要素、怎么读出问题) → ② 一桌子映射方法(旅程图只是其中一种，和体验地图/同理心图/服务蓝图/生态图/流程图怎么分工) → ③ 旅程 vs 流程 vs 故事地图(最常被问混的三组) → ④ 服务设计与服务蓝图(把镜头转到企业内部) → ⑤ 怎么真的做一个旅程项目(当前/未来、假设/研究、保真度、交互式地图、调研实证) → ⑥ 升到组织层(CX 转型、旅程中心设计) → ⑦ 研究地基(CUEs 观察框架、用户面板) → ⑧ 三个实战旅程(奢侈品、医疗、AI 绘图)+ 叙事技巧。
一句话心法:旅程地图回答"问题发生在人生/体验的哪一段"，流程图回答"问题发生在哪个界面哪一步"，服务蓝图回答"我们内部哪里没接上"。三者叠加才完整。
一、旅程地图本体:五要素 + 三段结构 + 七种分析法
旅程地图(Journey Map)定义:一种可视化工具，沿"用户行动的时间轴"展开，叠加用户的思想与情感，形成一个完整叙述。术语提示:"用户旅程地图"和"客户旅程地图"可互换，都指"用户使用产品/服务的可视化过程"。
三段结构(从上到下):
| 位置 | 放什么 |
|---|---|
| 顶部 | 特定用户(谁) + 场景 + 期望/目标(为什么来) |
| 中间 | 由用户行为、思想、情感组成的高层"阶段"(过程主体，情感画成曲线) |
| 底部 | 关键洞察、机会、内部责任分配(所以我们要做什么、谁来做) |
五个核心要素(无论形式如何都得有):
| # | 要素 | 是什么 | 心法 |
|---|---|---|---|
| 1 | 主体 Actor | 旅程从谁的视角看 | 一张图只画一个视角。和用户画像 Persona 一致、以数据为依据。大学要给学生和教职工各画一张，不能混 |
| 2 | 场景 + 期望 Scenario + Expectations | 这张图处理什么情境、用户带着什么期望来 | 适合"一连串事件"(购物/旅行)或多渠道互动 |
| 3 | 旅程阶段 Phases | 高层级的几大段，给其他信息搭骨架 | 电商买音箱=发现→尝试→购买→使用→寻求支持;买豪车=接触→教育→研究→评估→决策 |
| 4 | 行为/思想/情感 Actions / Mindsets / Emotions | 行为=实际做了啥;思想=想法疑问动机(理想情况用研究里的用户原话);情感=情绪高低曲线 | 情感曲线是后面"找痛点"的主战场 |
| 5 | 机会 Opportunities | 从图里提炼的优化洞察 | 三问:怎么用这知识?改进归谁负责?怎么衡量效果? |
心法:旅程地图的价值不在"画得漂亮"，在"它逼团队从用户视角把全程串起来，然后在底部把发现翻译成谁该做什么"。
七种分析一张旅程图的方法(NNGroup 用买车用户 Eric 在 yournextcar.com 的旅程做范例，全篇贯穿):
| # | 分析角度 | 在找什么 | Eric 范例 | 怎么改 |
|---|---|---|---|---|
| 1 | 未满足期望 | 实际体验低于用户带来的预期之处(即使没明说不满) | 看了电视广告期待网站有详细车况，实际没有 → 旅程一开头就摩擦 | 宣传与实际功能一致，别误导 |
| 2 | 多余触点/步骤 | 增加负担的冗余环节 | 为看新车每天反复刷网站 → 焦虑+耗时 | 上新车自动通知，别让人手动盯 |
| 3 | 情绪低谷 | 情感曲线的"谷"= 优先优化的痛点 | 比较与试驾阶段是最低点(要手动整理车况、规划路线) | 给更好的比较工具和试驾行程规划 |
| 4 | 高摩擦的渠道切换点 | 换设备/渠道时信息丢失或流程断裂 | 转到 App 发现功能不全 → 失望放弃 | 各渠道功能一致、跨渠道无缝 |
| 5 | 耗时 | 哪一步耗时长到有放弃风险 | 比较阶段拖了1 个月(手动 Excel 比对) | 智能推荐+筛选简化比较 |
| 6 | 关键时刻 Moment of Truth | 一个点显著左右整体成败 | 早早弃用 App → 错过"新车通知"这个能消除最大痛点的功能 | 突出关键功能价值、引导正确使用 |
| 7 | 高点/超预期 | 别只盯问题，也找已成功的亮点 | 旅程中两处发现好用功能、情绪上扬 | 强化展示、在别的阶段复制 |
Why 要同时找高点:只修低谷会让产品"不难用但也没记忆点"。低点定位要改哪、高点定位能放大哪、耗时揭示效率空间、关键时刻找转折点——四个维度合起来才是完整诊断。
二、一桌子映射方法:旅程图只是其中之一(UX Mapping 全景)
同理心地图、用户旅程地图、体验地图、服务蓝图是四种最常见的 UX 映射工具，目标和场景不同但都为"建立团队共同理解"。
| 方法 | 视角 | 是否绑定具体产品 | 结构/分栏 | 用在何时 | 主要目的 |
|---|---|---|---|---|---|
| 同理心地图 Empathy Map | 单一用户类型的心理 | 否(不按时间) | 四象限:说 Says / 想 Thinks / 感 Feels / 做 Does | 设计早期、整理访谈笔记时 | 建立同理心、对"用户是谁"达成共识 |
| 用户旅程地图 Journey Map | 用户视角(按时间) | 是，针对特定产品/服务 | 阶段/行为/想法/情绪 | 任意阶段，当团队参考点 | 找关键触点的痛点/亮点、跨部门共识 |
| 体验地图 Experience Map | "普通人"通用视角(按时间) | 否，与产品无关 | 阶段/行为/想法/情绪 | 画旅程图之前先理解通用行为 | 建立"产品无关"的体验基线 |
| 服务蓝图 Service Blueprint | 组织/员工视角(按时间+层级) | 是，针对特定服务 | 客户行为/前台/后台/支持流程 | 旅程图之后、组织变更前 | 优化跨部门协作、找服务薄弱环节 |
体验地图 vs 旅程地图的经典分界:共享出行出现前，可以先画一张"通勤"体验地图(步行/骑行/坐车都算)，识别痛点(时间不可预测、支付单一)，再据此为某个具体产品(如 Lyft)画旅程地图。体验地图 = 行业基线，旅程地图 = 落到你家产品。
发现阶段(Discovery)为什么要映射 + 三种发现期方法:映射在项目最前期帮你 ①管理复杂性(大问题拆小、突出关键参与者和因果) ②增强记忆(图比字好记，"图像优越性效应") ③创建对齐 ④揭示信息空白(画的过程会冒出"这块我们不知道"的问题)。三种发现期常用图:
| 方法 | 是什么 | 何时用 |
|---|---|---|
| 生态系统地图 Ecosystem Map | 把用户放中心，画出他可能互动的所有人/组织/产品/服务 | 面对陌生领域、初始发现期(如"家庭购房"周围的中介/银行/律师) |
| 时间顺序地图 Chronological Map | 按时间展开的体验(体验地图/服务蓝图/旅程地图都属此类) | 想理解"用户随时间变化的体验" |
| 流程图 Process Map | 拆解某一过程怎么运转(可用户流程也可业务流程) | 要深挖某个具体流程的细节 |
心法:这些方法不是单选题，是不同抽象层，灵活组合。开始任何映射前先定三个决策(见第五节)。映射的"过程价值"(团队讨论中对齐)往往比"成果价值"(那张图)更大。
三、最易混的三组:旅程 vs 流程 vs 故事地图
这是产品经理最常踩的术语坑。三者都在讲"用户为达成目标和产品的互动"，差别只在看多大范围、看多久、看多细、从谁的视角。
用户旅程 User Journey vs 用户流程 User Flow:
| 维度 | 用户旅程 User Journey | 用户流程 User Flow |
|---|---|---|
| 范围与渠道 | 跨多个渠道 | 单一产品内部 |
| 时间跨度 | 长周期(几周到几个月) | 短期、即时目标 |
| 捕捉内容 | 行为 + 想法 + 情绪 | 操作步骤顺序(关键操作+系统响应)，不含情感 |
| 视角/层级 | 宏观:广而高层(如"成为某诊所新患者"的全过程) | 微观:具体而细(如"在网站注册接收提醒") |
| 产出工件 | 旅程地图 | 线流图 Wireflow / 流程图 / 任务图 |
| 最佳研究法 | 情境法 Context Methods(实地研究、日记研究)+ 用户访谈 | 可用性测试(直接观察操作);热图等当次要补充 |
经典例子:家长"给孩子找幼儿园"=一个用户旅程(看官网→电话预约→反复邮件→实地参观→线上填表，跨平台、持续数周数月);其中"在家长门户提交表单"这一步，本身就适合用用户流程拆解。旅程告诉你问题在哪一段人生，流程告诉你问题在哪个界面哪一步。两者结合，既不迷失细节也不空谈体验。 现实里多数团队没有系统流程把这两个视角连起来(团队结构有缝、缺整体衡量计划、缺能力)。
选哪个:想问"整体顺不顺、多系统是否断裂"→ 用户旅程;想问"这功能为啥用不下去、哪步最容易出错"→ 用户流程。
用户故事地图 User Story Map(第三个工件，由 Jeff Patton 推广，属精益 Lean UX):用便利贴/草图，从产品视角画出用户在数字产品里完成目标的交互，替代冗长的瀑布式需求文档。三层结构:
| 层 | 是什么 | 银行 App"存支票"范例 | 可视化 |
|---|---|---|---|
| 活动 Activities | 用户在产品中的核心任务(顶层、不超过几个) | 查看余额、存入支票 | 顶部水平排，同色便利贴 |
| 步骤 Steps | 完成活动的子任务(按顺序) | 输入存款信息→拍照支票→提交→确认 | 活动下方，异色便利贴 |
| 细节 Details | 执行每步的最细交互 | 登录时输入用户名、输入密码 | 再换一种颜色 |
怎么用来规划:在地图上画一条发布线(Release Line)——线以上进本次版本(如做成原型验证"用户能否看懂流程并成功存支票")，线以下进未来迭代。步骤→敏捷待办里的史诗 Epic;细节→拆成带验收标准的用户故事和任务。优点:易调整(改便利贴比改文档/代码灵活)、促协作、保持用户中心、可见性+优先级讨论。还能暴露高风险区域(令用户反感或开发耗时过长的便利贴)，先用更精简的替代品做实验再投入。
故事地图 vs 旅程地图的关系(三者可互相演化):
| 对比 | 客户旅程地图 | 用户故事地图 |
|---|---|---|
| 视角 | 用户视角(情感/渠道/设备) | 产品视角(功能/步骤/优先级) |
| 用途 | 探索性研究产出、理解痛点 | 开发规划、替代需求文档、功能优先级 |
| 阶段 | 早期探索 | 产品开发/敏捷迭代 |
双向演化:旅程图里的"用户登录账户"可拆成具体产品操作(输用户名→密码→点登录)→变成故事地图;反过来，故事地图里某步发现用户常困惑，加上情感/设备/渠道信息 → 变成旅程图。旅程图给市场/客服看全局体验，故事地图给工程/产品看开发路线，组合让跨职能更有效沟通。
四、服务设计与服务蓝图:把镜头转向企业内部
服务设计(Service Design)定义:规划和组织企业资源(人员、工具、流程)的活动，目的是①直接改善员工体验 ②间接改善客户体验。1982 年 Lynn Shostack 首次提出。三组成部分=人员(员工/客户/被间接影响的人)+工具(物理场所/数字环境/实物或数字产品)+流程(工作流/程序，如取款、联系客服)。
容易绕的一对术语:
| 概念 | 关注 | 核心问题 | 餐厅例子 |
|---|---|---|---|
| 用户体验 UX | 外部接触点 | "用户遇到了什么?" | 客户从找到客服聊天入口到与客服互动的全过程 |
| 服务设计 Service Design | 内部如何创造这些体验 | "如何创造这些体验?" | 客服后台查数据库、记录、改配置等;后厨怎么把"过敏信息"传给厨师 |
为什么光有 UX 不够:企业按产品/渠道分团队 → 部门孤岛(市场/销售/产品/客服各管各的) → ①客户期望与实际有落差 ②重复劳动浪费资源。服务设计打破孤岛、确保设计出的体验在内部流程上"可持续兑现"。两者应并行优化，连接点就是服务蓝图。
服务蓝图(Service Blueprint)定义:一种图表，展示与"特定客户旅程触点"直接相关的服务组件(人员、物理/数字工具、流程)之间的关系。它是旅程地图的延续——尤其适合多触点、需跨部门协调的复杂服务(全渠道)。范例:餐厅堂食和外卖触点不同，要各画一张。
蓝图的关键元素(四泳道 + 三分界线 + 证据):
| 元素 | 是什么 | 例子 |
|---|---|---|
| 客户行为 Customer Actions | 客户与服务交互的步骤和决策 | 浏览网站、到店、找销售、购买 |
| 前台行为 Frontstage | 客户看得见的行动(人对人或人对技术) | 服务员接待、自助设备 |
| 后台行为 Backstage | 支持前台的幕后步骤 | 仓库更新库存、维护人员更新产品信息 |
| 支持流程 Support Processes | 支撑员工交付服务的内部步骤 | 信用卡验证、质检 |
| 证据 Evidence | 客户/员工交互的工具与场所 | 商品、网站、实体店、视频教程 |
三条分界线(Service Blueprint 的灵魂):
- 交互线 Line of Interaction:客户与组织的直接交互发生在这条线上下。
- 可见性线 Line of Visibility:线上=客户看得见(前台)，线下=看不见(后台)。
- 内部交互线 Line of Internal Interaction:区分"直接支持客户的员工"与"不直接支持的"。
可选辅助元素:箭头(单向流程/双向依赖)、时间(每步预计时长)、政策与规定、情感(员工/用户情绪状态定位痛点)、指标(耗时/成本)。
蓝图绘制的 5 个步骤:
| 步 | 做什么 | 要点 |
|---|---|---|
| 1 寻求支持 | 建跨职能团队 + 争取利益相关者(管理层/领导/客户)支持 | 没人撑腰白做 |
| 2 确定目标 | 选范围与重点(一个场景+对应客户目标)、定业务目标、定类型 | 现状 As-is(展现现状找痛点) vs 未来 To-be(探索创新) |
| 3 收集研究 | 客户研究(可从旅程图取) + 内部研究(至少选两种:员工访谈/直接观察/情境调查/日志研究) | 蓝图是定性框架，要定性研究，定量当补充 |
| 4 绘制蓝图 | 2-4 小时研讨会画低保真 → 先客户行为 → 再前台 → 再后台 → 加支持流程和证据 | 实地用便利贴+大纸，远程用 Mural 等数字白板 |
| 5 精炼分发 | 加时间/箭头/指标/法规 → 第二轮研讨会做高保真 → 广泛分发 | 限定范围(每个核心服务单独画)、基于一手数据、迭代优化 |
蓝图实践调研(97 位多行业从业者):对"服务蓝图是什么"有三种认知——产出物/图示 56%(只看最终图，最易错失"过程价值")、框架/方法 20%(看分析改进的过程)、协作工具 15%(看跨部门对齐)。设计团队最常主导，其次产品/项目管理、研究团队;但高管、客服、营销、销售的参与率不到一半——这是隐患(缺关键信息、影响落地与认同)。
做蓝图要多久/多高保真(来自"Top Questions"答疑):
| 问题 | 答案 |
|---|---|
| 谁该参与 | 与范围正相关:范围越广越要跨部门;优先邀请有组织影响力/广泛资源访问权的人 |
| 用什么研究 | 定性为主(定量补充);认知映射 Cognitive Mapping 访谈尤其能揭示员工心智模型 |
| 多高保真 | 初期低保真(便签墙)重理解;后期高保真(数字化)便于传递信任与共享 |
| 多久完成 | 聚焦型(≤3 个触点):研究<2 周+创建 1 周;全景型(跨部门大范围):<1 个月。建议从小做起积累信任 |
| 怎么向组织推销 | ①早且频繁地拉利益相关者 ②追踪成功当证据 ③把用户需求翻译成业务影响(省时/提满意度) |
心法:服务蓝图和旅程图共享"客户行为"这条泳道，但蓝图更关心"企业如何支持这些行为"。它最大的产出常常不是那张图，而是画图过程中跨部门建立的共同语言和"原来我这块影响了客户那一步"的全局意识。
五、怎么真的做一个旅程项目:三个决策 + 交互式地图 + 实证
开始前必做的三个决策(适用于所有映射):
| 决策 | 选项 A | 选项 B | 怎么选 |
|---|---|---|---|
| 当前 vs 未来 | 当前状态 As-is:画真实现状，找痛点/断点/情绪起伏，建共识、说服干系人 | 未来状态 To-be:画理想体验或尚不存在的新体验，当团队"北极星" | 想修现有问题→当前;想彻底重塑/定新愿景→未来 |
| 假设 vs 研究 | 假设优先 Assumption-First:先开 1-3 天工作坊用现有知识画初稿，再用研究验证 | 研究优先 Research-First:先做访谈/观察收新数据再画 | 团队新手/时间紧/省成本→假设优先;需要严谨说服力/范围小→研究优先 |
| 保真度 | 低保真:便利贴，早期、易协作易改 | 高保真:精制，便于共享传播但不灵活 | 早期探索用低，对外分享用高 |
推荐混合三步法:①用现有知识快速画"当前状态假设地图"对齐团队、找初步机会 → ②用访谈/日记研究验证更新 → ③基于验证后的现状画"未来状态地图"当北极星。既快又准，适合资源有限又想出成果的团队。
交互式地图(Interactive UX Maps，用 Figma/Sketch 做):用叠加层逐步揭示研究证据(照片/视频/用户原话)。优点=能嵌入照片视频、能加过滤器按画像/主题排序、让大而复杂的图更好懂;缺点=耗时、有技术门槛(不熟练会做出难用的交互反而扣分)。
| 步 | 做什么 |
|---|---|
| 1 | 创建低保真地图，每个发现关联其支撑证据(如"用户担心价格"链到相关视频) |
| 2 | 建视觉设计系统(排版/颜色/图标/组件，Figma 用样式/变量/组件库) |
| 3 | 按主题或类型分组关键元素(照片/视频/引用)，全部清晰标签 |
| 4 | 用自动布局 Auto Layout 搭灵活结构(标题/泳道/象限)，先骨架后内容 |
| 5 | 用真实内容替换占位符(Figma"替换实例"换图标) |
| 6 | 在原型模式连接交互 |
| 7 | 至少找一人测试排错(Figma 里图层命名要正确)。第一张图可留作模板 |
心法:基于研究的、展示"现状"的交互式地图(如旅程图)比静态图更有效，因为能直观呈现特定用户的原话和行为。但先掂量范围/预算——已有完善静态图且马上要展示，时间不如花别处;简单地图同样有效。
旅程映射影响:行业调研实证(NNGroup 调查 300+ UX 专业人士，下列基于 259 个有效回复，数据收集于 2020 年 11 月疫情期间):
| 实证发现 | 数字 |
|---|---|
| 协作创建 vs 独立创建 | 64% 团队协作，36% 独立(协作在"建立内部一致性"上略胜，p=.1) |
| 数字工具 vs 实体工具 | 56% 数字(Miro/Google Sheets)，44% 实体(便利贴);两者成功率无显著差异——先实体后转数字也行 |
| 七个结果的成功率 | 用 1-5 分自评，3.5 是"成功障碍线":在"介绍痛点""建立团队一致性"上表现最好，"说服管理层做内部优化"最弱 |
8 个成功因素重要性排名(234 人评分，1-8 分越高越重要):
| 因素 | 排名分 |
|---|---|
| 客户参与到流程中 | 6.08 |
| 让跨职能团队参与 | 5.81 |
| 选对要画的旅程 | 5.21 |
| 选对角色/细分市场 | 4.85 |
| 选对研究方法 | 4.46 |
| 行政赞助 | 3.84 |
| 用于绘图的研究的严谨性 | 3.75 |
| 图形设计精美、视觉吸引 | 2.18 |
Why 这张表对 PM 很重要:"画得漂亮"排名垫底(2.18)，"客户和跨职能团队参与"排前两名。 别把预算砸在视觉精修上——重点是拉对人、选对旅程、界定好范围。第一版不完美没关系，它的作用是帮你确定重点。
六、升到组织层:CX 转型 + 旅程中心设计
当"画一张旅程图"升级成"整个公司围着客户旅程重新组织"，就进入了 CX 转型和旅程中心设计的领域。
CX 转型框架(A Framework for CX Transformation):让企业从"以产品为中心"转向"以客户为中心"，在大规模上提供一致体验。问题根源是老组织为面对面/电话设计，后来把数字部门当孤岛塞进去 → 渠道切换时体验断裂。框架=4 个变革领域 × 4 个构建块 = 16 项改进任务:
| 4 个领域(变什么) | 4 个构建块(怎么变) |
|---|---|
| 愿景与战略 Vision and Strategy(领导层承诺长期客户导向) | 设计运营 Experience-Design Operations(标准化体验设计流程) |
| 员工 Employees(打破孤岛、建协作网络) | 客户数据与反馈 Customer Insights and Metrics(用数据/反馈/指标持续监测) |
| 运营 Operations(新流程推动跨职能、朝旅程中心努力) | 文化管理 Culture Management(培养客户中心文化) |
| 技术 Technology(支持跨职能运营和旅程管理的基础设施) | 领导与治理 Leadership and Governance(明确决策机制) |
转型初期应先做基础性变革(建立领导力、研究运营、技术基础设施)。
旅程中心设计 Journey-Centric Design vs 旅程管理 Journey Management(两个常混用的词):
| 术语 | 是什么 |
|---|---|
| 旅程中心设计 Journey-Centric Design | 一种哲学/框架:把业务和设计运营围绕客户旅程展开，强调"把旅程放运营中心" |
| 旅程管理 Journey Management | 一种持续实践:研究、测量、优化、编排客户旅程的日常运营 |
为什么从产品中心转向旅程中心:产品中心只能在小范围(单个界面)优化，复杂生态里创造不出大价值;旅程中心同时在微观(产品界面)和宏观(整体服务交付)做用户中心设计，带来四大好处=①更多设计创新机会 ②更具战略性/业务驱动的服务交付 ③更先进的行为数据与设计 ROI 衡量(旅程级分析比单步分析更能展示业务影响) ④为 AI 个性化创造机会(但 AI 是用户中心设计的补充而非替代)。
派对帽模型(Party-Hat Model):旅程中心设计在产品设计策略之上引入一层"旅程设计策略层"，让产品团队的跨职能贡献者和其他孤岛(业务/营销/技术/运营)连接协作，共同优化旅程性能。对 PM 的含义:产品优先级将受旅程需求影响，产品经理要兼顾"产品"和"旅程"双重优先事项;组织通常从小规模试点起步迭代。NNGroup 为此做了两项研究:6 个月日记研究 + 4 个组织的深入案例研究。
七、研究地基:观察框架 CUEs + 用户面板
这两篇是支撑前面所有映射的"原料采集"层——旅程图画得准不准，取决于现场观察和能不能持续找到对的用户。
情境 CUEs 框架(Context CUEs，用于现场研究 Field Studies):理论根基是分布式认知 DCog(Distributed Cognition)——1998 年 Clark 和 Chalmers 提"延伸心智"，认为"思考"发生在人与人、人与物的互动里，不只在脑子里(经典案例:飞行员靠速度指示器上的物理"标记 bug"减轻记忆负担)。CUEs 把杂乱的现场定性数据分三类，当观察清单:
| 字母 | 类别 | 定义 | 观察提示 |
|---|---|---|---|
| C | 文化 Culture | 群体共享的隐性/显性行为、信念、规则、价值观 | 用户怎么完成 X?何时求助?怎么理解 X?为什么这么做? |
| U | 未言明 Unspoken | 隐性知识、根深蒂固的实践、潜在假设(不会被明说) | 最近的内部冲突怎么解决的?有特定语言/词汇限制吗?新人遇到啥没人帮?获取关键信息有障碍吗? |
| E | 环境 Environment | 物理/社会/在线环境 | 在哪发生?视觉嗅觉氛围如何?是唯一空间吗?可进入性如何? |
心法:CUEs 是"灵活提醒该往哪看"，不是固定打钩清单;某些元素会跨类别(笔记本电脑既是工具也是环境)。它帮你发现"用户怎么用外部记忆/变通方法/环境支架减轻认知负担"，这些正是产品改进机会(看到用户频繁翻实体地址簿 → 做在线目录)。优秀设计=减少认知负担、支持"外部思考"。
用户面板 User Panel 101:一群愿意长期参与研究的用户，加上一套管理系统(记录信息、追踪参与、方便反复邀请)——不是一份联系名单，价值在可持续复用。
| 维度 | 要点 |
|---|---|
| 何时有价值 | 频繁招募相似人群、招募占大量时间、依赖其他团队协调用户。适合高频、小规模、快速验证类研究 |
| 核心收益 | 省时(预筛选+集中管理)、省钱(减外部平台/中介费+隐性协调成本)、强化与真实用户的持续连接 |
| 关键局限 | 面板用户熟悉产品，代表性有限——做"熟人研究"，新市场/陌生人群仍要外部招募，两者并行非互斥 |
两种类型 + 业务模型驱动:
| 类型 | 组成 | 适合 |
|---|---|---|
| 客户型面板 Customer Panel | 现有产品用户 | 评估体验/流程/长期使用问题;背景清晰但视角易固化 |
| 目标用户面板 Target-user Panel | 符合条件但还没用过产品的人 | 了解需求、发现机会;但找人和维护更费力 |
面板形态由"你卖什么、服务谁"决定:B2C(如 Duolingo) 强调规模和多样性、关注可用性/满意度;B2B(如 Atlassian) 强调角色清晰和领域深度、关注效率/流程;平台/双边市场(如 Airbnb) 必须覆盖生态两侧(一方变化直接影响另一方)。面板成熟度本质是 UX 成熟度的外显:低成熟=表格/临时名单只求"少点招募摩擦";高成熟=有系统/分层/权限/自动化，成为跨团队共享资产——角色从"方便研究的工具"演变为"连接组织与用户的长期机制"。
6 步搭建:招募 Recruit → 整理与分层 Organize & Segment → 联系与排期 Contact & Schedule → 激励与维护 Incentivize & Engage → 复用与管理 Reengage & Manage → 治理与优化 Govern & Improve。工具选择:成熟团队用专业研究平台(全流程但贵)、CRM 系统(只能基础信息管理分层)、通用工具如表格(早期可用，规模大了风险陡增)。
八、三个实战旅程 + 叙事技巧
把前面的方法落到三个真实研究里——看 NNGroup 怎么用旅程视角拆解一个行业。
实战一:奢侈品购物(Luxury Shopping)。定性研究 9 名参与者(新顾客/忠实顾客/造型师/顾问)，购物涵盖 Jimmy Choo、Hermès、Chanel、LV、Burberry、卡地亚、蒂芙尼、宝马、劳力士、Golden Goose 等。四类购物者(会随时间和品类变化，如律师可能在西装上是大消费者、在汽车上是偶尔挥霍者):
| 类型 | 特征 |
|---|---|
| 只逛不买者 | 买不起但追随品牌的年轻粉丝(渴望有天能买) |
| 偶尔挥霍者 | 特殊场合买耐用品(包/鞋)，当享受和投资、传家宝 |
| 大消费者 | 频繁买多品牌的主力客户，占销售大部分;深谙品牌历史(研究品牌领导团队)、与品牌建专属关系(私人销售代表)、享会员特权(免费维修/活动邀请) |
| 专业造型师 | 为客户买的专家，多用 Farfetch/Net-a-Porter 平台而非单品牌官网，买一批再退回不要的 |
四阶段旅程(发现→考虑→购买→使用)，关键结论:"考虑"是最长、最关键的阶段(对所有用户群都是)，痛点集中在此——找不到产品名和购买渠道、缺细节照片和真实展示、退货政策不清(高价物风险)、信息架构差、推荐系统没用。奢侈品牌的网站/App 在"考虑"阶段最重要，应集中资源在此提升体验。 有意思的反直觉点:很多奢侈网站故意信息有限/不显价格(如 Maison Goyard)，把"高价+少信息"当门槛，筛出真懂真爱的客户;使用阶段还分"要显眼 logo 显身份"vs"低调奢侈"(怕撞假货/怕成为目标/觉得显眼没品味)两种心理。
实战二:医疗数字交互(Digital Interactions in Healthcare)。纵向日记研究 9 名参与者，记录一个月内每次就医互动，共 93 次互动。关键数字:
| 发现 | 数字 |
|---|---|
| 设备:智能手机为主 | 93 次里 78 次用手机(便利，尤其外出);电脑 14 次(复杂任务如填表、登录虚拟预约，界面更稳) |
| 渠道:患者门户最常用 | 门户(如 MyChart)32 次;数字渠道远超传统(72 数字 vs 21 传统) |
| 痛点:数字反而更复杂 | 近半数旅程含至少一个痛点，数字互动中更常见(传统渠道 1/3 遇障碍，数字渠道 2/3 遇问题) |
主要痛点:信息难找、功能缺失、技术故障、信息难理解(缺结果解释)，且多发生在旅程早期。核心教训:数字渠道在效率和便利上有优势(异步通信、预填表格)，但虚拟预约满意度低(缺非语言交流、难建立关系);零散整合反而增加复杂性。指南:提供异步通信选项、选移动友好且跨设备一致的工具、创造数字与面对面之间的无缝过渡、在切换接触点时设定期望并让后续体验兑现期望。
实战三:AI 图像生成的四阶段(The 4 Stages of AI Image Generation)——一张"专家用户的体验地图"。情境调查 9 名用户，全都自选用了 Midjourney。四阶段:
| 阶段 | 在干什么 | 关键细节 |
|---|---|---|
| 1 定义 Define | 定目标 + 想怎么实现 | 目标分灵感导向(搜灵感找概念)vs交付物导向(要高质量成品);起点用过去的图/genAI 聊天机器人(让 ChatGPT 出 prompt)/外部资源(Midlibrary) |
| 2 探索 Explore | 大量生成大致符合愿景的图 | 通常生 20-80 张;两策略=提示重复(同 prompt 探多方向，用 --r 10 一次出 10 批)+ 提示变化(改 prompt 措辞);常有"意外惊喜"带出新方向 |
| 3 优化 Refine | 调整图逼近目标 | 即使专家也觉难——"它是生成器，不是编辑器";AI 随机性导致每次微调都连带变样(改沙发布料结果整个沙发都变)，耗时挫败、成品常不完美 |
| 4 导出 Export | 导出满意的图 | 可能用 Photoshop 修饰、AI 放大提分辨率、加文字 |
非线性变体:不是每个人都走完四阶段。灵感导向者多花时间在探索阶段(只要创意，常跳过优化/导出，去 Figma 收尾);交付物导向者多花时间在优化阶段(追求完美细节，受限的控制让过程充满挫败)，整体耗时长得多。对设计师的含义:痛点集中在优化阶段，改进方向=给用户更多控制。
叙事技巧:两条让 UX 故事更打动人的建议(Two Tips for Better UX Storytelling)——旅程做完要讲给人听，这里是怎么讲:
| 工具 | 是什么 | 怎么用 |
|---|---|---|
| 故事三角形 Story Triangle | 故事/叙述者/观众三要素，强调讲故事是双向交流不是单向灌输 | 观众会用自身经验填补细节，叙述者要留空间让其分享假设和反馈。细节多少要按目标调:想突出具体问题(可用性障碍)→多给细节;想激发新想法→只给基本情节 |
| 故事山 Story-Mountain | 源自 19 世纪德国剧作家 Gustav Freytag 的"金字塔"，五段:开端 Exposition→上升 Rising Action→高潮 Climax→下降 Falling Action→结局 Resolution | 把用户体验组织成完整叙事(用 Mary 赶末班火车选公交还是出租的例子)，让用户成为叙述核心、逻辑清晰情感饱满，给观众具体行动建议 |
心法:旅程图/调研数据本身不会说服人，把它包进一个有主角、有冲突、有转折的故事才会。但细节是双刃剑——太多限制想象，太少导致误解，按"我要解决具体问题还是激发新方案"来定。
源自 NNGroup Topics / Customer Journeys - 用户旅程(29 篇)。用户画像与旅程主体见 NNGroup 用户画像 Personas(本质/三类型/范围层级/创建/对比 JTBD-原型-分群/应用/维护/5 大失败);旅程映射的情境法/日记研究/实地研究等定性方法见 NNGroup 定性研究与研究方法工具箱(方法全景/访谈/共情图/样本量/任务设计/主持/专家评估/工作坊/伦理);映射在整个 UX 研究方法谱系中的定位见 NNGroup UX 研究方法选型(23 法速查/四象限定位/按问题-阶段-预算选/定性探索·定量验证·专家评估·IA·行为分析五大族)。图片/原档保留在 sources。