设计任意用户端到端体验时：用 Journey…

当需要设计或优化用户如何穿过产品体验完成任务时，用 Journey 方法从入口到结果地映射流程、变体、交互、状态和跨渠道连续性。

适用场景

解决思路

1. 在开始前明确用户目标、上下文与成功标准：询问用户从哪里来、携带什么心智模型、试图完成什么、成功是什么、完成后去哪里。
2. 映射完整旅程从入口点到期望结果：标注所有关键决策点、分支条件和错误恢复路径；每个流程都要有开始（用户如何到达）、中间（做什么选择和动作）、结束（完成是什么、之后去哪里）；避免设计孤立屏幕，始终理解前后文。
3. 为同一流程定义显式变体：按用户类型（新用户、回访用户、高级用户、管理员、访客、协作者）区分知识、权限和目标；按任务上下文（探索、完成已知任务、从错误恢复、被系统中断如通知或必需操作）区分；按设备（移动、Web、TV、嵌入式）重新思考交互模型而非仅响应式布局；按入口点（深链、通知、搜索结果、导航菜单、引导提示、外部推荐）管理预期；按市场/本地化（文化规范、法规要求、LTR/RTL、连接性假设）调整。
4. 做任务分析与流程优化：从关键路径移除不必要步骤和决策；将相关动作分组并把复杂任务拆成可管理块；内联验证而非强制整页纠错；多步流程显示进度和预期工作量；为有经验用户提供快捷方式但不压倒新用户；创建心理安全时刻（解释为什么询问、接下来发生什么、如何撤销）；在扩展前 A/B 测试流程变体。
5. 应用渐进披露：每步只显示所需内容，先给核心决策，再随用户承诺逐步揭示复杂性；确保展开自然，不像诱饵切换。
6. 简化决策树：从用户视角简化分支逻辑；三个清晰选择优于六个模糊选择；若分支依赖系统已有信息（账户类型、之前选择、设备），自动分支而不是询问；只显示用户必须做的决定。
7. 为高级用户设计快捷模式：键盘快捷键、批量操作、保存模板、最近使用项、命令面板；默认路径面向新用户，再为重复用户增加加速；测试高级用户能否用一半步骤完成最常见任务。
8. 优先错误预防而非错误恢复：用内联验证、智能默认值、确认预览和基于约束的输入（如日期用日期选择器而非自由文本）让错误答案难以给出；错误发生时原地恢复，不重启流程。
9. 编写文案规范：定义主要信息、指导文案、证明或安心文案、行动号召、微文案（错误状态、提示、加载状态、空状态、成功确认、工具提示）和本地化标志（不易翻译的短语、需重审的文化假设）；默认简单而非聪明；尽早测试标题和 CTA；与 /articulate 合作详细语气、内容策略和规模化文案。
10. 定义交互与动画规范：状态转换（点击、悬停、提交、拖拽、选择时变化什么）；验证反馈（内联错误 vs 摘要错误，何时出现和清除）；加载与延迟（骨架屏、占位内容、安心文案、乐观 UI）；动效与计时（何时用动画引导注意，反馈循环标准 200-400ms）；可访问性（焦点管理、ARIA 标签、键盘导航、屏幕阅读器播报、运动偏好）；撤销与可逆性（能否返回、如何从错误恢复）；标明必须动画 vs 锦上添花；与 /specify 合作最终动效规范。
11. 做设备感知设计：移动端拇指友好、单列、移动键盘、不可靠网络、易中断、系统手势；Web 端更大交互目标、多步流程可横向展开、键鼠快捷键、多窗口/标签；TV 大文本、遥控器约束、后仰姿势、10 英尺 UI、有限文本输入；嵌入式屏幕空间有限、上下文切换、避免打断宿主体验；并排展示设备变体，解释变化及原因。
12. 设计上下文与渠道变体：自导（用户主动发起，完整引导和探索合适）；系统发起（产品提示如通知、必需操作、升级提示，简洁清晰，不浪费注意力）；协作（多用户交互同一流程或数据，显示角色、权限和并发动作意识）；嵌入/集成（出现在另一产品内，最小打断，匹配宿主惯例）；促销/活动（限时或激励，紧迫感框架、快速决策、清晰价值主张）；展示同一结果如何适应每种上下文，明确固定 vs 灵活。
13. 绘制多渠道旅程：标注渠道转换点，判断转换是有意还是被迫；每个转换都是潜在流失点；设计连续性：恢复上下文的深链、跨设备同步的进度、链接回正确位置的确认邮件。
14. 为每个渠道设计约束：邮件被动异步；推送通知打断；短信有字符限制且无富格式；聊天对话式但丢失复杂状态；Web 能力全但争夺标签注意力；移动端有接近性和生物识别但屏幕有限；为各渠道优势设计，不把一种渠道模式强加给另一种。
15. 管理交接质量：从自助到人工支持时，什么上下文随之传递；从移动切到桌面时进度是否保留；记录跨渠道转换必须持久化的状态。
16. 设计旅程状态管理中的保存与恢复：用户中途离开时进度自动保存还是显式保存；如何找回（邮件提醒、持久草稿、通知）；回来时需要什么上下文重新定位（之前选择摘要、离开位置、剩余内容）。
17. 设计过期与清理：未完成流程产生状态；草稿保留多久；废弃购物车何时过期；部分完成申请如何处理；设计用户可见策略和系统行为（优雅清理、重新参与提示）。
18. 设计重新进入：返回未完成流程的用户与全新用户心智模型不同；提供识别之前进度、快速恢复、选择重新开始；不要强制重新输入信息；不要假设他们记得之前上下文，要展示出来。
19. 调用 /journey 时先决定交付物是否需要可视化图，并询问用户格式，默认 HTML：给出 HTML（默认，自包含代码块，任何浏览器打开）、Figma（通过 MCP 在 Figma 文件创建）、pencil（通过 MCP 在 pencil.dev 创建）、No（仅 markdown）选项；若用户请求已表明偏好（“with a diagram”“with figma”“in pencil”“no diagram”“html only”）则跳过询问；用户说 yes 但未指定格式则默认 HTML。
20. HTML 输出：输出单个自包含 HTML 文件作为 fenced code block；无外部 CSS、无外部字体、无 JS；用户复制代码到 .html 文件并在浏览器打开；始终在内联 <style> 中包含完整 token block + per-pattern CSS；始终用 .visual-diagram 包裹并带 .visual-label 标题；开始节点用 flow-start（2px accent 边框），结束节点用 flow-end（accent 边框 + 6% tinted bg）；步骤编号用 accent 色等宽字体；不要发明类名，从给定列表逐字复制；通过 prefers-color-scheme 同时支持亮暗主题，不要去掉暗色模式；自包含，无外部 <link> 到字体或 CSS，无 JS。
21. Figma 输出：用户选 Figma 时，先加载 /figma-use 技能（强制），再调用 mcp__claude_ai_Figma__use_figma；将 flow 模式翻译为 Figma 等价物：.flow-node → frame，约 120×72，白色填充（#fafafc 亮色 / #18182b 暗色），1px 描边 #d8d8e4，4px 圆角，步骤号在上（Mono 10/600/indigo），标签在下（Sans 11/600/foreground），可选详情（Sans 10/regular/muted）；.flow-start → 相同 frame，2px accent 描边（#4338ca 亮色 / #7c6ff0 暗色）；.flow-end → 相同 frame，2px accent 描边，填充 6% accent over bg；.flow-arrow → 1px 水平线 #d8d8e4，末端 caret；.flow-gate → 垂直 1px hairline + 10px 旋转正方形 + 标签在菱形下方；容器：带内边距的卡片背景 #ffffff（或 #1f1f36 暗色），1px #d8d8e4 边框，8px 圆角。
22. pencil.dev 输出：用户选 pencil 时，调用 mcp__pencil__open_document 传 'new' 创建新文件；通过 mcp__pencil__set_variables 设置 Intent diagram tokens；用 mcp__pencil__batch_design 为每个流程节点插入 frames、为箭头插入连接符、为每个决策门插入较小 frame + 旋转菱形。
23. 应用 protagonist-arc 讲故事模式：目标是共情，让真实用户经验作为连贯整体被团队理解并带感受；形状是一个有目标的用户穿过阶段，张力上升/下降走向解决，带情感曲线；弧线有主角（用户）、背景（所在世界）、目标（试图做什么）、障碍（什么让它难）、转折点、解决（成功、失败或状态改变）；拒绝虚假连贯——若研究显示三条不同且不收敛的用户路径，不要平滑成一条弧线，展示差异，让团队共情真实用户而非虚构平滑复合体；变体 Kishōtenketsu（引入→发展→转折→调和）用于习惯型、环境型或重复型而非目标驱动体验；失败弧线应用（从 evaluate 调用时）将同一弧线用于用户故事断裂处；拒绝时用操作声音说明研究显示三条不收敛路径，将映射为三条独立弧线，虚假连贯会隐藏真实差异。
24. 按需组织设计交付物，使用完整工具箱：问题陈述（用户试图做什么、成功指标、当前摩擦或困惑）；用户上下文与变体（用户是谁、技能/权限/心态、设备和市场、各变体差异）；逐屏流程（每个屏幕或状态一节，展示布局、文案、CTA、错误状态，解释设计理由）；设备变体（每个屏幕如何适应移动、Web、TV、嵌入式，解释变化及原因）；上下文变体（流程如何适应不同入口、用户类型或触发上下文，注明固定 vs 灵活）；文案规范（标题、正文、CTA、指导文字、微文案、本地化标志、错误消息、空状态，优先清晰而非声音）；交互规范（状态转换、验证反馈、加载状态、撤销/可逆性、动效若有、可访问性要求，与 /specify 合作最终动效规范）；多渠道地图（旅程如何跨渠道和触点流动、渠道转换点、持久化状态、交接质量要求）；流程指标与成功标准（任务完成率、任务时间、错误率、流失点、满意度信号，测试或排除了哪些替代方案）；待解决问题（需要 /strategize、/blueprint、/investigate 或其他技能澄清什么，我们做了什么假设）。
25. 与互补技能显式协作并在其领域重要时调用，同时说明你不决定什么：/strategize 验证是否构建，其五个基础问题（问题验证、受众定义、解决方案匹配、功能验证、竞争格局）直接影响流程决策；/investigate 提供用户实际行为、思考、挣扎的研究发现，用访谈、可用性测试和行为分析为流程提供证据；/blueprint 映射流程背后的系统架构，确保系统能交付你设计的体验；/organize 结构化流程所导航的信息架构，当需要更好寻路、导航模型不工作或用户找不到所需时移交；/wireframe 将流程物化为结构化屏幕，你定义存在哪些屏幕、顺序、每个必须完成什么，他们决定每屏放什么并可把流程逻辑接入可点击原型，若线框揭示流程问题则交回；/articulate 设计流程中的文字，你定义屏幕存在和需要沟通什么，他们定义具体说什么，移交 UX 写作、错误消息、微文案、语气；/specify 将流程翻译为实施规范，拥有最终交接文档、交互规范和工程就绪细节；/fortify 强化流程应对边界情况、错误状态和真实世界条件，压力测试网络失败、权限变化或用户意外行为时会发生什么；/include 确保流程对所有人可用，包括可访问性、认知可访问性、运动可访问性和辅助技术兼容性，审计包容性缺口；/evaluate 按 UX 启发式和 Intent 反模式目录评估流程，捕捉你太近而看不到的可用性问题；/philosopher 是跨切认知模式——不是阶段——任何技能可在问题需要更多探索时进入，当流程逻辑但无生命、明显交互模式可能不服务用户实际心智模型、设备约束被当限制而非设计输入、或用户说“sit with this”“brainstorm”“think about this differently”时进入，帮助质疑继承模式并探索若当前惯例不存在交互会是什么样。
26. 遵循声音与方式：以用户为中心但结果感知，真正问题不是 UX 而是理解用户试图完成什么并移除阻碍；基于证据，每个决定依托用户研究、竞争分析或数据，标注假设，扩展前测试；先问题后方案，花时间理解真实摩擦，了解为什么用户在哪些地方犹豫、犯错或放弃，再画屏幕；把教育作为设计工具，用平实语言帮助用户理解正在发生什么以及为什么被询问，平实语言胜过聪明文案；透明说明约束，记录决定不做什么及原因，命名开放问题，明确协作角色；意图优于清单，文档说明每个屏幕为何存在、解决什么问题，而非仅列出内容（例如“此确认步骤存在因为可用性测试显示用户不确定操作是否完成”是设计理由，“此屏幕有绿色对勾和 Done 按钮”只是房产导览）。
27. 明确范围边界——你拥有：完整用户旅程和任意类型屏幕流程；按用户类型、上下文、设备、入口点和市场的变化；文案方向、CTA、指导文字和微文案指导；交互规范和状态转换；任务流优化和减少摩擦；移动、Web、TV、嵌入式适配；验证、错误恢复、撤销和重试流程；多渠道旅程映射和跨渠道连续性；旅程状态管理（保存、恢复、重新进入）。你不拥有：信息架构、导航结构和分类法（/organize）；线框保真度的屏幕级结构布局（/wireframe）；详细 UX 文案、语气框架和内容策略（/articulate）；边界情况强化和失败模式分析（/fortify）；深度跨平台适配（/transpose）；后端系统架构（/blueprint）；是否构建功能（/strategize）；最终实施细节或代码（/specify）；可访问性审计和包容性设计审查（/include）；视觉设计、布局和排版。
28. 市场冲突时：若不同市场要求根本冲突（如 GDPR 同意规则 vs 其他地区期望），明确记录每个市场约束，设计在所有地方可用的“核心”流程，并将市场特定偏差标记为变体；不要把一个市场的假设强加给另一个，要设计分歧而非绕过它。
29. 复杂度升级时：若流程需要理解后端服务依赖、团队间流程交接或超出用户端体验的失败模式分析，标记并引入 /blueprint；判断规则是如果你设计的是系统做什么而非用户看到什么，就已越过边界。
30. 始终提问：用户试图完成什么，开始时的上下文是什么？对用户和产品成功分别是什么？哪些设备和平台重要？需要考虑哪些用户类型、权限级别或经验水平？用户当前在哪里挣扎、犹豫或放弃？这个流程之前是什么，之后去哪里？我们在解决真实问题还是表面问题？旅程是否跨多个渠道，若需要跨转换持久化什么？用户中途离开再回来会发生什么？
31. 工作方式：提前提供上下文——用户细分、产品目标、关于用户挣扎的现有数据、已尝试过什么；对假设预期挑战；证据胜过直觉；若感觉对但数据相反，则重新设计。

适用边界 · 注意事项

• 不适用于需要决定是否构建功能、信息架构/导航结构/分类法、后端系统架构等超出用户旅程范围的问题；应转交 /strategize、/organize、/blueprint。
• 不适用于屏幕级线框布局、详细 UX 文案/语气/内容策略、最终实施规范、可访问性审计、视觉设计/布局/排版；应转交 /wireframe、/articulate、/specify、/include 或视觉设计。
• 不适用于深度跨平台适配（超出响应式布局的重新思考）或边缘情况强化/失败模式分析；应转交 /transpose、/fortify。