这张卡讲"做之前怎么想清楚"。专业团队不会一上来就画页面，而是先研究人，再排优先级，再防风险，然后才动手。你不用懂代码，也不用照搬团队那一整套。借里面几个工具（比如"该先做哪个功能""这个改动有什么风险"）来指挥你的 Agent，让 Steve's Repair 这种项目少走弯路。每节都配了真实示例，照着对比就会用。
这是一个循环、非线性的过程。任何一步拿到反馈，都可以折回去重来。
| 阶段 | 做什么 | Steve's Repair 怎么落地 |
|---|---|---|
| 第 1 步 共情 Empathize | 做用户调研和访谈；理解用户的需求、痛点、行为；画"用户旅程图"把体验可视化。 | 去问几个修过电脑的人："你上次找修理店，最烦的是什么？" |
| 第 2 步 定义 Define | 用 CSD 矩阵整理调研：确定项（Certainties）=已验证的事实、假设项（Suppositions）=有依据的猜测、疑问项（Doubts）=待验证的问题；写出扎根用户洞察的"问题陈述"。 | 确定="大家最关心多久能修好"；疑问="他们更在意价格还是上门？" |
| 第 3 步 构思 Ideate | 跨部门一起想方案；画草图、做故事板；用情绪板（mood board）探索方向；早早让人画草图来验证假设。 | 列出首页可能的样子：先放报价？先放预约按钮？先放好评？ |
| 第 4 步 原型 Prototype | 做可交互原型测概念；画线框图和设计规格；为开发记录设计决策；越早做原型，后期开发成本就降得越多。 | 让 Agent 先生成一个最简单的预约页，先点点看流程顺不顺。 |
| 第 5 步 测试 Test | 用真实用户做可用性测试；用问卷和专家评审收集反馈；基于"已验证的学习"迭代；为下一轮记录发现。 | 发给朋友试用，看他们卡在哪一步，记下来下一版改。 |
复杂应用（比如企业内部系统）在动手前要先理解整个生态。这套三阶段从研究走到落地，让方案贴合真实工作场景。
核心目标：研究整个工作环境，而不只是单个用户。
研究范围：
针对不同角色的研究方法：
| 角色 | 方法 |
|---|---|
| 一线执行（Individual Contributors） | 跟岗观察（shadowing）、任务分析、深度访谈 |
| 管理者（Managers） | 围绕团队挑战与目标的战略访谈 |
| 高管（Executives） | 组织目标对齐 + 业务约束访谈 |
| 支持 / 运营（Support / Operations） | 深挖边界情况和错误场景 |
| 跨职能团队 | 用工作坊理解相互依赖关系 |
关键产出：按角色与场景记录的研究综述；展示物理与数字生态的"工作环境地图"；行业分析与竞品格局；已验证的假设与待解问题清单。
核心目标：把约束变成有创造力的设计准则，并和领域专家一起测早期想法。
原型方法：先做最简单的（纸面草图、线框图、可点击原型），早期就拉领域专家一起，跟用户和专家快速迭代，对照技术与组织限制做验证，再用原型来"撑起"（rig）并验证关键假设。
关键产出：设计准则与原则、早期原型与故事板、专家反馈记录、已验证的方向。
核心目标：超越标准可用性测试，在真实场景里和专业用户一起做协作式验证。
进阶测试方法：情境调查（在真实工作环境、真实工作流中测）、专业协作会议（测试时和领域专家并肩工作）、灵活的测试协议（按现实约束调整方法）、长期观察（不止一次性会话）、实施伙伴关系（上线和打磨期间持续协作）。
超越"好不好用"的质量保证：用真实数据量和边界情况测试、验证与现有系统的工作流集成、评估真实条件下的性能与可靠性、收集高级用户和复杂用例的反馈、监控采用模式并据实使用情况调整。
关键产出：完整测试结果与落地洞察、精修后的设计规格、培训与推广材料、经验教训文档。
| 方法 | 是什么 |
|---|---|
| 旅程图（Journey Mapping） | 把用户从"知道你"到"问题解决"的整条路画出来 |
| UX 路线图（UX Roadmaps） | 把调研活动和设计阶段按时间排开 |
| 可用性测试（Usability Studies） | 用目标用户测原型和成品 |
| 利益相关者访谈 | 从关键相关人那里收集需求与约束 |
| 问卷（Surveys） | 用来验证假设、收集量化数据 |
| UX 专家评审 | 对照最佳实践做结构化评审 |
| 角色 | 设计 | 策略 | 执行 | 沟通 |
|---|---|---|---|---|
| UX 负责人 | A/R | R/A | C | A |
| 产品经理 | C | R/A | C | C |
| 设计师 | R/A | C | R/A | C |
| 开发 | C | I | R/A | I |
| 高管发起人 | I | A | I | C |
A=批准（Accountable）·R=负责（Responsible）·C=咨询（Consulted）·I=知会（Informed）
功能想法一大堆，时间精力却有限。这五种方法帮你定"先做哪个"。用在 Steve's Repair 上：把候选功能列出来，套一个方法，就有了开发顺序，再丢给 Agent 一个一个做。
一个 2×2 表，横轴=投入多少、纵轴=影响多大。
流程：列出所有候选，估影响（用户价值/业务价值/战略契合），估投入（设计/工程/测试时间），画到 2×2，从 Quick Wins 开始，再做 Big Bets；Money Pit 和 Fill-Ins 等有余力再看。
优点：简单、直观、可执行、利于团队对齐。局限：不考虑依赖关系和战略背景。
从三个维度打分：可行性 Feasibility（能不能做出来）、合意性 Desirability（用户想不想要）、商业可持续 Viability（业务支不支持），各 1 到 5 分。
给某些维度加权重（例如 合意性 40% / 可行性 35% / 商业 25%），算加权分，按分排序。
| 功能 | 可行性 | 合意性 | 商业可持续 | 加权分 |
|---|---|---|---|---|
| 暗色模式 | 4 | 3 | 3 | 3.4 |
| 高级搜索 | 3 | 5 | 4 | 4.0 |
| 移动 App | 2 | 4 | 4 | 3.4 |
| API 集成 | 2 | 2 | 5 | 2.9 |
优点：评估全面，平衡设计/业务/工程，鼓励跨职能对话。局限：打分主观，依赖好的估计。
量化打分，综合 Reach 触达 · Impact 影响 · Confidence 信心 · Effort 投入。
| 功能 | 触达 | 影响 | 信心 | 投入(月) | 分数 |
|---|---|---|---|---|---|
| 搜索筛选 | 2000 | 2 | 100% | 3 | (2000×2×1)/3 = 1,333 |
| 新仪表盘 | 500 | 3 | 75% | 4 | (500×3×0.75)/4 = 281 |
| 暗色模式 | 800 | 1 | 100% | 1 | (800×1×1)/1 = 800 |
排序：按 RICE 分从高到低。优点：量化、考虑不确定性、平衡触达与投入、易于横向比较。局限：依赖好的估计；可能低估"触达小但战略重要"的事。
按"必要性 + 时间线"把功能分四档：
流程：头脑风暴所有功能，各归入 M/S/C/W，取得相关人共识，用来定每个阶段的范围，约束变化时重新平衡。
示例分阶段：MVP（阶段 1）=全部 Must + 关键 Should；阶段 2=剩余 Should + 高价值 Could；阶段 3=剩余 Could + 延后的 Must（如有）。
优点：简单、沟通清晰、控制范围蔓延、适合分阶段交付。局限：分类主观，不考虑技术依赖。
按"对用户满意度的影响"分类，用两个维度分析：功能满足程度 × 情感满意度。
| 类别 | 特点 | 例子 |
|---|---|---|
| 魅力型（Delighters） | 有了惊喜，没有也不会不满；含了满意度高，常是创新机会 | 游戏化、动画、个性化 |
| 性能型（Satisfiers） | 满足程度和满意度成线性关系，越多越好；用户会明确要求；竞争差异点 | 速度、存储容量、搜索准确度 |
| 基本型（Must-Be） | 用户默认就该有；做得再好也不加分，缺了或差了会严重不满；行业入场券 | 登录、基础导航、数据持久化 |
| 无差异型 | 用户不在乎，有没有都不影响满意度，别投资源 | （无典型例子） |
| 反向型（Negatives） | 越多越糟，用户不想要 | 复杂臃肿、不必要的通知 |
映射流程：识别候选功能，做"功能型/不具备型"两问问卷（"有这功能你感觉如何？""没有你感觉如何？"），访谈或问卷，在 Kano 图上画响应，按类别定优先级（基本型：做好但别超配；性能型：靠卓越拉开差距；魅力型：创新取悦）。
| 功能 | "有"的反应 | "没有"的反应 | 类别 |
|---|---|---|---|
| 自动保存 | "挺好" | "很沮丧" | 魅力型转基本型 |
| 搜索 | "本就该有" | "很生气" | 基本型 |
| 暗色模式 | "会用" | "无所谓" | 无差异/可以有 |
| 表情回应 | "惊喜" | "还行" | 魅力型 |
| 加载慢 | "烦" | "会弃用" | 基本型（反向） |
战略洞察：投资基本型降低不满；投资性能型建立竞争优势；投资魅力型赢得偏好与忠诚；逐步淘汰无差异型和反向型。
优点：以用户为中心、识别真正的差异点、高效分配投入。局限：研究耗时；类别会随时间变化（魅力型用久了会变成基本型）。
| 情况 | 最佳方法 |
|---|---|
| 需要快速对齐 | 影响与投入矩阵 |
| 跨职能决策 | FDV 计分卡 |
| 数据驱动评估 | RICE 方法 |
| 分阶段发布规划 | MoSCoW |
| 理解满意度驱动因素 | Kano 模型 |
| 因素混杂 | 组合使用多种 |
复杂设计项目里要管理风险：早识别、早化解，免得后期付出更大代价。
界定背景：业务目标与成功指标；技术约束（性能、架构、系统集成）；组织约束（预算、时间、团队产能）；合规与监管要求；市场与竞争压力。
相关人对齐：让高管就优先级与约束达成一致；记录权衡取舍与决策权；确立风险容忍度与化解预算。
风险来源：
研究技巧：检视项目假设与依赖；和跨职能团队开风险工作坊；分析竞争与市场趋势；识别关键路径与瓶颈；记录"已知的未知"。
概率刻度：
| 等级 | 评分 | 说明 | 频率 |
|---|---|---|---|
| 极少（Unlikely） | 1 | 罕见 | < 10% |
| 偶尔（Seldom） | 2 | 偶发 | 10% 到 30% |
| 有时（Occasional） | 3 | 中等频率 | 30% 到 50% |
| 很可能（Likely） | 4 | 高频 | 50% 到 75% |
| 频繁（Frequent） | 5 | 极可能 | > 75% |
影响刻度：
| 等级 | 评分 | 说明 | 后果 |
|---|---|---|---|
| 轻微（Minimal） | 1 | 无显著影响 | 小延迟或成本 |
| 中等（Moderate） | 2 | 可管理 | 进度滑动、预算上升 |
| 严重（Critical） | 3 | 重大影响 | 大幅延迟、范围缩减 |
| 灾难（Catastrophic） | 4 | 严重影响 | 项目失败、成本严重超支 |
风险分矩阵（颜色越红越要紧）：
| 极少(1) | 偶尔(2) | 有时(3) | 很可能(4) | 频繁(5) | |
|---|---|---|---|---|---|
| 轻微(1) | 1 | 2 | 3 | 4 | 5 |
| 中等(2) | 2 | 4 | 6 | 8 | 10 |
| 严重(3) | 3 | 6 | 9 | 12 | 15 |
| 灾难(4) | 4 | 8 | 12 | 16 | 20 |
风险分级：
| 策略 | 含义 | 例子 |
|---|---|---|
| 规避（Avoid） | 改范围或方案，直接消除风险 | 不用有风险的新技术，改用成熟方案 |
| 降低（Reduce） | 主动行动降低概率或影响 | 早测假设来降低设计风险 |
| 转移（Transfer） | 通过合同/合作把风险转给第三方 | 把有风险的组件外包给专业厂商 |
| 接受（Accept） | 承认风险并准备应急预案 | 接受时间风险，预留缓冲时间 |
识别的风险：用户可能误触一键下单，导致退货和不满。概率=有时(3)、影响=中等(2)、风险分=6（严重优先级）。
| 问题 | 严重度 |
|---|---|
| 误下单 | 高（无确认） |
| 退货率高 | 中（用户沮丧） |
| 退货成本 | 中（损失收入） |
| 问题 | 严重度 |
|---|---|
| 误下单 | 低（确认+撤销窗口） |
| 退货率 | 低（提交前先核对） |
| 摩擦平衡 | 中（速度 vs 安全的取舍） |
化解策略（降低）：最终下单前加确认弹窗；成功页给视觉确认；一键快速通道只给回头客；让下单可撤销（60 秒内可反悔）。
残余风险：概率降到偶尔(2)，影响仍为中等(2)，新分数 = 4（中等，可接受）。
UX 成熟度的四大因素：1 人（角色、技能、招聘）；2 流程（方法论、工作流、文档）；3 工具（设计软件、研究平台、跟踪系统）；4 文化（心态、跨团队协作、以用户为中心）。
UX 新人入职：第 1 周团队介绍、产品概览、设计系统讲解；第 2 到 3 周关键项目、相关人关系、工具培训；第 2 月主导小型设计任务、参加研究会话；第 3 月向相关人汇报、建立工作模式。
远程团队的技能映射：记录每人主/次技能；做知识共享的轮岗计划；安排异步文档时间；用协作工具跨时区做设计评审；设"办公时间"做同步协作。
定义：一个懂设计的程序员 + 一个会写代码的设计师。
核心职责：用早期原型弥合"设计到开发"的鸿沟；用代码做可交互原型；从工程视角参加设计评审；为开发写设计规格；实现组件库和设计系统；用早验证降低实现成本。
职业路径：偏设计走向产品设计或设计领导；偏工程走向前端工程或平台角色。成本收益：原型做得越早，省下的开发成本越多。
| 工具 | 用途 |
|---|---|
| 线框图（Wireframes） | 低保真的布局与结构 |
| 故事板（Storyboards） | 交互的叙事序列 |
| 情绪板（Mood Boards） | 视觉方向与审美指引 |
| 可交互原型 | 高保真可点击流程 |
| 设计规格（Design Specs） | 给开发的就绪规格 |
| 资产映射（Asset Mapping） | 所有设计元素的清单 |
| 交互式 UX 地图 | 部门触点与数据流 |
| 维度 | 看什么指标 |
|---|---|
| 可用性 | 任务成功率、任务耗时、错误率 |
| 体验 | 系统可用性量表（SUS）、满意度评分 |
| 业务 | 转化率、留存、客户终身价值 |
| 参与 | 功能采用率、会话时长、回访率 |
数据驱动设计的好处：44+ 案例研究显示，用 UX 数据的团队拿到了正向结果；把 UX 指标和组织目标对齐以争取高管支持；用 A/B 测试验证设计决策；长期跟踪指标证明 ROI。
建立 UX ROI：1 改动前定基线指标；2 测量改动影响；3 算出改进的业务价值；4 沉淀案例用于对外沟通。
修辞三角（Ethos / Pathos / Logos）：
把 UX 当业务价值来卖：1 从业务问题切入，而非设计问题；2 用用户研究证明客户痛点；3 量化机会（问题的代价 vs 方案的收益）；4 把设计呈现为风险化解；5 用相关人能懂的语言（收入、留存、降本）。
协作与决策：设计思维能凝聚团队（协作过程创造认同感）；警惕群体思维（鼓励评审中的多元视角）；警惕确认偏误（用研究挑战假设）；"墨水思考"，也就是用草图把思路外化，加快迭代。
设计评审最佳实践：1 收集跨职能反馈；2 把设计理由和视觉一起呈现；3 用 7 个探索要点组织反馈会；4 记录决策与理由；5 实现后安排回访评审。
项目复盘与回顾：项目完成 2 周内开；记录"做得好的"和"可改进的"；识别过程中欠下的 UX 债；产出流程改进的行动项；跨团队共享经验。
UX 债管理：记录走过的设计/技术捷径；在未来路线图里优先偿还；算清"还债 vs 不还"的成本；每季度做一次 UX 债复盘与偿还；通过可持续实践防止债务累积。
| 目标 | 怎么做 |
|---|---|
| 平等参与 | 确保所有声音被听见、不被最大嗓门压住；用结构化活动和轮流发言；为内向者创造心理安全；平衡讨论与独立思考时间；用数字工具收集匿名想法 |
| 相互理解 | 跨学科建立共享心智模型；摆明假设、澄清术语；确保对问题与目标有共同理解；明确记录共识 |
| 包容性决策 | 为多元视角留空间；寻求真正共识而非多数票；尊重异议并纳入考量；记录推理与理由 |
| 共担责任 | 让与会者对成果有归属感；建立跟进的问责；明确下一步的归属；通过参与建立承诺 |
| 活动 | 怎么做 | 用于 |
|---|---|---|
| Post-Up（便利贴头脑风暴） | 静默构思(5分,一贴一想法)，同时贴墙(2分)，静读并聚类(5分)，讨论(10分) | 生成选项、把想法摊到台面、平等参与 |
| 亲和图（Affinity Diagramming） | 把想法/反馈写在卡片上，静默分组，给每簇命名，解释分组逻辑并探讨关系 | 综合大量反馈、找规律 |
| 地形图（Landscape Mapping） | 定两个轴（如复杂度 vs 影响），讨论谁放哪，摆放，辩论为什么 | 排优先级、理解关系、视觉比较 |
| 强制排序（Forced Ranking） | 提出 5 到 10 个选项，讨论标准，个人排序，比较差异，用点投票或讨论达成共识 | 做决策、建立对齐、检验优先级 |
| 故事板（Storyboarding） | 定要映射的序列，每帧画一步(5 到 10 帧)，走查讲解，精修 | 展示用户旅程、工作流设计 |
| 角色扮演（Role Playing） | 各人取一个角色（用户/系统/业务），给情境问各角色如何反应，入戏演，复盘 | 理解多元视角、测边界情况、建立同理 |
| 回放（Playback） | 汇总关键主题、决策、产出，引导者向群体综合呈现(15 到 20 分)，确认"是这么定的吗?"，48 小时内分享纪要 | 收尾、确保共识、问责 |
卡住或拿不准，就把你的功能清单或方案发给你的 AI 老师（Agent），问"按 MoSCoW 帮我排个开发顺序"或"这个改动有什么用户体验风险，该怎么加兜底？"
abel-ux）· Abel's Design Note，综合 Refactoring UI、Laws of UX、Apple HIG、Material Design、NNGroup 与 IDEO / Intercom 等业界方法。本卡为中文整理版 + 可视示例，贯穿全程可反复回看。