当设计文档过重、团队各自为政或需要快速验证 UX 假设时…

适用于希望减少重型设计交付物、用快速实验和共享理解替代规格文档、并让跨职能团队共同设计的产品/UX 场景。

适用场景

解决思路

1. 以结果而非产出衡量设计价值：设计的价值由用户行为改变决定，而不是交付物的保真度；把问题从“我们该设计什么？”改成“我们需要学到什么？”
2. 按 Quick Diagnostic 八行评分：每回答一个 yes 约得 1.25 分，8 个 yes 得 10 分；每次审计都说明当前分数、失败的行以及每行对应的具体修复。
3. 用评分带解释状态：9-10 分对应假设已声明、假设带预承诺成功标准、最低保真实验、全团队设计、每周研究、结果指标、双轨敏捷、近期有被推翻的假设；5-6 分对应假设存在但标准模糊或保真度过高投资、设计与研究仍部分孤立；<=3 分对应重型交付物、未测试假设、数产出、无实验日志。
4. 在新功能 kick-off 时，团队协作写明假设，不要孤立地写；区分业务假设（收入模式、市场规模、付费意愿等必须为真之事）和用户假设（用户是谁、如何行为）。
5. 用两个轴给假设排序：风险（错了有多严重）和不确定性（我们知道得有多少）；先测试高风险、高不确定性的假设。
6. 在路线图规划中，按假设风险排列功能优先级：优先做那些成功依赖未测试信念的功能。
7. 在利益相关者对齐时，暴露各角色的隐藏假设，例如 PM 假设定价可行、工程师假设可扩展、设计师假设流程成立。
8. 伦理边界：假设必须是诚实评估，不是事后合理化；如果领导层已经承诺某个方向，承认该约束，而不是假装它开放可证伪。
9. 运行假设工作坊或编写假设时，参考 references/hypothesis-canvas.md，使用其中的风险/不确定性优先级矩阵、业务假设与用户假设拆分、可填写的假设与子假设模板。
10. 写假设时使用标准格式：'We believe [outcome] will happen if [persona] achieves [action] with [feature]'；每个假设都指定 persona、action、outcome 和 measurable signal。
11. 把大赌注拆成多个可独立测试的子假设。
12. 在运行实验前，先约定什么算 validated、什么算 invalidated。
13. 在功能设计中，先写假设再画 wireframe；例如：'We believe trial-to-paid conversion will rise 10% if new users complete a guided setup wizard'。
14. 在 A/B 测试中，用假设形式化测试理由；例如：'We believe click-through will rise 15% if we move the CTA above the fold'。
15. 在 sprint planning 中，为每个 story 附上假设；例如 Story：'filter by date'，Hypothesis：'task completion time drops 30%'。
16. 伦理边界：绝不在事后挑选指标来宣称假设已验证；必须预承诺成功标准。
17. 为假设选择可测量信号或定义团队成功时，参考 references/outcome-metrics.md，使用 outcomes-vs-outputs、leading-vs-lagging indicator pairs、UX OKRs，并避开 vanity metrics。
18. 把 MVP 当作最小可测试假设的设计物，是学习工具，不是产品发布。
19. 实验保真度从低到高排列：paper prototypes、concierge tests 到 coded A/B tests、Wizard of Oz；选择能回答问题的 lowest-fidelity 实验。
20. 设计好实验时，确保它有清晰假设、定义受众、可测量信号和 time box。
21. 当速度重要时，可用 proto-personas 暂代完整研究，但之后必须验证。
22. 早期概念验证：画 3 个概念并当天用 paper prototype 或 clickable mockup 测试 5 个用户。
23. 需求验证：用 landing page smoke test，例如 'Sign up for early access' 测量真实兴趣。
24. 可用性验证：用 Figma 原型测试 5-8 个用户。
25. 定价验证：用 painted door test，展示定价页并测量点击，再决定是否构建 billing。
26. 伦理边界：smoke tests 和 fake doors 不得误导用户相信产品已存在；披露测试状态并提供 opt-out。
27. 选择或设计实验时，参考 references/experiment-patterns.md，使用完整实验类型目录及 when/when-NOT-to-run 说明、实验选择矩阵、fidelity ladder 和设计模板。
28. 采用跨职能协作设计，取代设计师独自设计再交接的模式；让 developers、PMs、designers 一起 sketch 解决方案。
29. 用 Design Studio method：diverge（个人 sketch）、present、critique、converge（精炼 sketch）、iterate。
30. 目标定为 informed commitment，而不是 consensus：团队同意要测试什么，而不是什么是“正确”。
31. 跨职能意味着 engineers、QA、data analysts 和 stakeholders 也要 sketch。
32. 把 style guides 和 pattern libraries 当作 living documents；把交付物降到共享理解所需最低限度，常常一张白板照片就够。
33. 在 sprint kick-off 运行 90 分钟 Design Studio session，让全团队给 sprint 的假设画方案。
34. 在功能探索时，运行 collaborative sketching workshop，例如 6-up sketches：每人 5 分钟画 6 个 ideas。
35. 远程团队用虚拟白板（如 FigJam 或 Miro）并设置计时 sketch rounds。
36. 伦理边界：协作不能变成 design by committee；指定一名设计师综合输入，团队不对 pixels 投票。
37. 促进 Design Studio 时，参考 references/collaborative-design.md，使用逐步工作坊协议（timings、materials、remote variants），并保持 style guides 为 living documents。
38. 用持续、轻量研究取代大爆炸可用性研究；把小型研究活动嵌入每个 sprint，而不是季度报告。
39. 研究类型包括 usability tests、customer interviews、A/B tests、analytics review、surveys、diary studies。
40. 记住 5 users 可发现约 85% 的可用性问题（Nielsen）。
41. 建立持续节奏：每周招募、每周测试、每周综合。
42. 让全团队至少观察部分 sessions，以建立同理心。
43. 精炼 proto-personas，并最终用 evidence-based personas 替代。
44. 每周可用性测试：每周四用 3-5 个用户测试原型，并轮换 facilitators。
45. 发布后学习：监控 analytics，并做 3 次 follow-up interviews；找 drop-off points，采访 churned users。
46. 验证 persona：把 proto-persona 假设与 interview data 对比，例如数据可能显示 power users 是 ops managers 而不是 marketers。
47. 伦理边界：研究必须有 informed consent；参与者应理解其数据如何被使用，并可自由退出。
48. 在 Agile 中通过 dual-track development 实施 Lean UX：discovery（学习要构建什么）和 delivery（构建它）并行。
49. 让 discovery track（研究+设计）比 delivery track（工程+QA）提前一个 sprint，staggered，这样 delivery sprint 开始时已有验证过的设计。
50. 让 user stories 除 acceptance criteria 外，还携带 hypothesis 和 success metric。
51. 把 UX 的 'Definition of Done' 定义为包含 validated learning，而不只是 shipped pixels。
52. 来自 invalidated hypotheses 的 backlog items 要移除，而不是 defer。
53. 在 sprint planning 中把 hypothesis validation 放进 sprint goals，例如 'Sprint goal: validate that inline editing cuts task time 20%'。
54. 在 backlog refinement 中把 experiment results 附到 stories；只有假设验证后，story 才进入 delivery。
55. 在 retrospectives 中同时 review learning velocity 和 delivery velocity，例如 'We validated 4 hypotheses and invalidated 2 this sprint'。
56. 伦理边界：绝不用 Lean UX 作为借口跳过 accessibility、security 或 compliance；这些是不可协商质量标准，不是待测假设。
57. 把 discovery 融入 delivery cadence 时，参考 references/agile-integration.md，使用 staggered dual-track sprint mechanics、stories 如何携带 hypothesis、以及 UX Definition of Done。
58. 想要端到端示例时，参考 references/case-studies.md，使用四个复合场景（enterprise、startup、agency、internal tools）来建模 engagement，其中展示 assumptions、experiments 和 before/after outcome metrics。
59. 避免把 MVP 当发布：不要因混淆 MVP 与 first release 而过度构建；重构为 MVP = learning tool，不是 product launch。
60. 避免跳过假设声明：隐藏假设会变成昂贵意外；在 kick-off 运行 30 分钟 assumption mapping session。
61. 避免没有成功标准的假设：否则无法判断实验是否通过；预承诺 metric、threshold 和 sample size。
62. 避免 designer-only design：会造成 handoff waste、misalignment、慢迭代；与完整团队运行 Design Studio sessions。
63. 避免把研究当阶段：反馈会来得太晚；把 lightweight research 嵌入每个 sprint。
64. 避免忽略 invalidated hypotheses：否则会构建测试失败的功能；从 backlog 移除 invalidated items；pivot 或 drop。
65. 避免只做文档不协作：40-page specs nobody reads；用 co-design 产生的共享理解替代 specs。
66. 避免衡量 outputs 而不是 outcomes：会发布不改变行为的功能；把成功定义为 behavior change，而不是 delivery。
67. 诊断 'Are assumptions explicitly declared?' 如果否，隐藏假设驱动决策；行动：运行 assumption mapping workshop。
68. 诊断 'Is there a testable hypothesis?' 如果否，是在凭观点构建；行动：在设计前用标准格式写 hypothesis。
69. 诊断 'Is the experiment the lowest fidelity that answers the question?' 如果否，在学习前过度投资；行动：降级为 paper prototype 或 smoke test。
70. 诊断 'Does the whole team participate in design?' 如果否，handoff waste 和 misalignment；行动：安排 Design Studio session。
71. 诊断 'Is research happening every sprint?' 如果否，反馈循环太慢；行动：建立 weekly testing cadence。
72. 诊断 'Are you tracking outcomes, not just outputs?' 如果否，是在无学习地发布；行动：为每个 feature 定义 behavior-change metrics。
73. 诊断 'Does UX work feed into Agile smoothly?' 如果否，设计瓶颈或 sprint-zero trap；行动：用 staggered sprints 实施 dual-track agile。
74. 诊断 'Can you point to a recently invalidated hypothesis?' 如果否，没有学习，存在 confirmation bias；行动：review experiment log 并庆祝一次 pivot。

适用边界 · 注意事项

• 当 accessibility、security、compliance 等质量要求不可协商时，不应把这些当作待测假设用 Lean UX 跳过。
• 当领导层已不可逆地承诺方向、假设不允许被证伪时，不适合假装进行开放式 Lean UX 假设测试。
• 当无法接触真实用户或无法测量行为结果时，轻量实验的反馈价值有限，应先解决研究/测量条件或改用其他方法。