experience-method-selector

name	experience-method-selector
description	当用户不知道该用直觉、惊喜还是故事来解决体验问题时调用，先诊断问题类型再选方法。不适用于已经明确的单点 UI 修复。
source_book	《任天堂的体验设计》 玉树真一郎
source_chapter	实践篇 体验创造法
tags	["experience","diagnosis","design"]
related_skills	[]

体验方法选择器

R — 来源依据 (Reading)

原书依据见本节来源说明。

依据实践篇关于问题疲劳、无价值体验与三类方法选择的章节。

本仓库不收录原书全文；此处只保留章节级依据和方法论重述。

I — 方法论骨架 (Interpretation)

• 体验问题不同，方法也不同。
• 不知道怎么做时先用直觉设计；疲劳厌倦时用惊喜；没有价值时用故事。
• 选择方法前要判断用户卡在哪里。

A1 — 书中的应用 (Past Application)

案例 1: 实践篇方法选择

• 问题: 作者把体验问题转成三类选择。
• 方法论的使用: 根据问题性质匹配直觉、惊喜、故事。
• 结论: 避免乱用体验技巧。
• 结果: 形成通用诊断入口。

A2 — 触发场景 (Future Trigger)

用户会在什么情境下需要这个 skill?

当用户不知道该用直觉、惊喜还是故事来解决体验问题时调用，先诊断问题类型再选方法。不适用于已经明确的单点 UI 修复。

语言信号

• "这个体验问题该怎么改？"
• "是要做引导、惊喜还是故事？"
• "用户无聊但又不是不会用"

与相邻 skill 的区分

• 本 skill 处理 体验方法选择器 这一单点问题；若问题跨越多个环节，请先读本书 INDEX.md 选择组合顺序。

E — 可执行步骤 (Execution)

1. 诊断问题

   • 完成标准: 判断是不会做、做累了、还是觉得没价值。

2. 选择方法

   • 完成标准: 直觉/惊喜/故事三选一或组合。

3. 定义验证指标

   • 完成标准: 用完成率、停留、复述、成长感验证。

B — 边界 (Boundary)

不要在以下情况使用此 skill

• 不要为了技巧而技巧。
• 复杂产品可能同时有多个体验问题。

作者的盲点 / 时代局限

• 大量来自游戏案例，迁移到严肃工具需谨慎。
• 惊喜设计若用于高风险流程可能伤害信任。

相关 skills

• depends-on: {}
• contrasts-with: {}
• composes-with: {}

审计信息

• 验证通过: V1 ✓ / V2 ✓ / V3 ✓
• 测试通过率: 100% 设计通过；结构校验见本书 QUALITY_REVIEW.md
• 蒸馏时间: 2026-06-18