lean-ux

精益 UX 框架

一种以实践为驱动的 UX 方法，用快速实验、跨职能协作和持续学习取代繁重的交付物。精益 UX 将问题从“我们应该设计什么？”转变为“我们需要了解什么？”

核心原则

成果优先于产出。 衡量设计价值的标准，不是交付物的保真度，而是它带来的用户行为变化。

基础： 传统 UX 会将需求逐级传递到线框图、模型、规格说明和代码，在每次交接中丢失上下文，并隐藏未经验证的假设。精益 UX 缩短创意与证据之间的距离：明确假设、形成假设陈述、开展尽可能小的实验，并让真实用户行为来定论。共同理解取代文档，学习速度取代像素级完美。

评分

目标：10/10。 使用下方的八项快速诊断，为 UX 流程、设计计划或团队工作流评分：每项回答“是”得约 1.25 分（8 项全是 = 10）。分数区间：

• 9-10 — 已明确声明假设，设定带有预先承诺的成功标准的假设陈述，采用最低保真度实验，开展全员参与的设计，每周进行研究，使用成果（而非产出）指标，实行双轨敏捷，并且近期记录过一项被证伪的假设。
• 5-6 — 存在假设陈述，但标准含糊或过度投入保真度；设计与研究仍有部分隔离。
• <=3 — 交付物繁重、假设未经验证、按产出计数、没有实验日志。

务必说明当前分数、未通过的诊断项，以及每项对应的具体改进措施。

框架

1. 明确声明假设

核心概念： 每个设计都始于假设。精益 UX 将假设明确列出，以便对其排序并进行测试，而不是让它们悄然固化在规格说明中。

为何有效： 未说出口的假设意味着团队会在不稳固的基础上开展工作，只有发布后才发现问题；尽早揭示假设，能让团队集中精力处理风险最高的部分，并降低判断错误的代价。

关键见解：

• 业务假设定义了业务必须满足的条件（收入模式、市场规模、付费意愿）；用户假设定义了用户是谁以及他们如何行动
• 从两个维度确定优先级：风险（出错时的影响有多大）和不确定性（我们了解得有多少）
• 优先测试高风险、高不确定性的假设
• 以团队协作的方式编写假设，而非单独完成

产品应用：

场景	应用	示例
新功能启动	假设映射工作坊	“我们假设用户希望与队友分享报告”
路线图规划	按假设风险对功能排序	优先考虑成功与未经验证的信念相关的功能
利益相关者对齐	揭示不同角色间隐藏的假设	PM 假设定价可行；工程师假设可扩展性；设计师假设流程可行

伦理边界： 假设必须是诚实的评估，而非事后辩解——如果领导层已经确定了方向，就应承认这一限制，而不是假装它仍可被证伪。

在开展假设工作坊或编写假设陈述时，请参阅 references/hypothesis-canvas.md——其中包含风险/不确定性优先级矩阵、业务与用户假设的分类，以及可填写的假设陈述和子假设模板。

2. 假设陈述

核心概念： 假设将一项假定转化为可测试的预测，把拟议的变更与特定用户群体可衡量的结果联系起来。

为什么有效： 假设要求团队明确表述——团队不再笼统地说“改善新手引导”，而是承诺提出一个可证实或证伪的预测，从而防止范围蔓延，并让“学习”步骤的含义清晰明确。

关键见解：

• 标准格式：“我们相信，如果[用户画像]借助[功能]完成[操作]，[结果]就会发生”
• 每个假设都要明确用户画像、操作、结果和可衡量的信号
• 子假设可以将大型押注拆分为可独立测试的部分
• 开始实验前，先就“已验证”和“未验证”分别意味着什么达成一致

产品应用：

情境	应用	示例
功能设计	在绘制线框图前写下假设	“我们相信，如果新用户完成引导式设置向导，试用转付费转化率就会提高 10%”
A/B 测试	明确测试的依据	“我们相信，如果将 CTA 移至首屏可见区域上方，点击率就会提高 15%”
冲刺规划	为每个故事附上假设	故事：“按日期筛选。”假设：“任务完成时间缩短 30%”

伦理边界： 切勿事后挑选指标来宣称假设已得到验证——应预先承诺成功标准。

选择假设的可衡量信号或定义团队成功标准时，请参阅 references/outcome-metrics.md — 结果与产出、先行与滞后指标组合、UX OKR，以及应避免的虚荣指标。

3. MVP 与实验

核心概念： 在精益 UX 中，MVP 是能够用真实用户测试假设的最小设计产物——它是学习工具，而非产品发布。

为什么有效： 在走廊里用 5 位用户测试纸面原型，就能证伪一项原本可能耗费整个工程冲刺的假设；让实验的保真度与假设风险相匹配，可以最大限度地提高单位投入所获得的学习成果。

关键见解：

• 实验的保真度从低到高不等，低保真实验包括纸面原型和礼宾式测试，高保真实验包括代码实现的 A/B 测试和绿野仙踪测试
• 选择能够回答问题的最低保真度实验
• 好的实验具有清晰的假设、明确的受众、可衡量的信号和限定的时间
• 当速度至关重要时，可以用初步用户画像代替完整研究，但之后必须进行验证

产品应用：

情境	应用	示例
早期概念验证	纸面原型或可点击模型	绘制 3 个概念，当天找 5 位用户进行测试
需求验证	落地页冒烟测试	“注册抢先体验”可衡量真实兴趣
可用性验证	可点击原型测试	使用 5-8 位用户测试 Figma 原型
定价验证	假门测试	展示定价页，在开发计费功能前衡量点击率

伦理边界： 冒烟测试和假门不得误导用户，让他们以为产品已经存在——应披露测试状态并提供退出选项。

选择或设计实验时，请参阅 references/experiment-patterns.md — 完整的实验类型目录及适用与不适用场景说明、实验选择矩阵和保真度阶梯，以及设计模板。

4. 协作式设计

核心概念： 设计是团队协作的成果。精益 UX 用跨职能协作取代设计师独自设计、然后移交的模式，让开发人员、PM 和设计师共同绘制解决方案草图。

为何有效： 帮助绘制解决方案草图的开发人员不需要 40 页的规格说明就能着手实现——共同理解取代了文档，多元视角带来更有创意的解决方案，移交造成的浪费也会大幅减少。

关键见解：

• Design Studio 方法：发散（个人绘制草图）、展示、评议、收敛（完善草图）、迭代
• 目标是充分了解后的承诺，而非达成共识：团队就要测试什么达成一致，而不是认定什么才是“正确”的
• 跨职能协作意味着工程师、QA、数据分析师和利益相关者也要参与绘制草图
• 风格指南和模式库是持续更新的文档；将交付物减至满足共同理解所需的最低限度（通常只需一张白板照片）

产品应用：

情境	应用	示例
冲刺启动会	Design Studio 环节（90 分钟）	整个团队围绕冲刺假设绘制解决方案草图
功能探索	协作式草图工作坊	6 格草图：每人用 5 分钟画出 6 个想法
远程团队	虚拟白板会议	使用 FigJam 或 Miro 白板进行限时草图轮次

伦理边界： 协作不能变成委员会式设计——指定的设计师负责综合各方意见；团队不应通过投票决定像素细节。

主持 Design Studio 时，请参阅 references/collaborative-design.md，了解分步骤的工作坊流程（时间安排、材料、远程方案），以及如何让风格指南持续更新。

5. 反馈与研究

核心概念： 持续、轻量的研究取代大型集中式可用性研究——在每个冲刺中融入小型研究活动，而不是每季度才出一份报告。

为何有效： 只有在决策仍能以较低成本逆转时，研究发现才能改变决策。因此，从获得洞见到影响决策之间每多一个冲刺，研究的价值就会衰减；每周开展小型研究能让这段间隔接近于零，而季度报告永远做不到这一点。

关键见解：

• 研究类型：可用性测试、客户访谈、A/B 测试、分析数据审查、问卷调查、日记研究
• 五名用户就能发现约 85% 的可用性问题（Nielsen）
• 持续开展：每周招募、每周测试、每周综合分析
• 整个团队都应旁听至少部分研究环节，以培养共情能力
• 原型用户画像会不断完善，并最终由基于证据的用户画像取代

产品应用：

情境	应用	示例
每周可用性测试	每周四用原型测试 3-5 名用户	轮流主持的“测试星期四”惯例
上线后学习	监控分析数据，并开展 3 次后续访谈	找出用户流失节点，访谈已流失用户
用户画像验证	将原型用户画像的假设与访谈数据对比	“我们原以为重度用户是营销人员；数据显示他们是运营经理。”

伦理边界： 开展研究时必须取得知情同意——参与者应了解其数据的使用方式，并有权随时退出。

6. 与 Agile 集成

核心概念： Lean UX 通过双轨开发融入 Agile：探索（了解要构建什么）和交付（构建产品）并行推进。

为何有效： 设计工作难以与交付冲刺严丝合缝地配合；让探索提前一个冲刺进行，就能在交付冲刺开始时备好经过验证的设计，而不是让设计工作永远追赶进度。

关键要点：

• 探索轨道（研究 + 设计）为交付轨道（工程 + QA）提供支持，并提前一个冲刺错开进行
• 用户故事除了验收标准，还会加入假设和成功指标
• UX 的“完成定义”包括经验证的学习成果，而不仅仅是已交付的界面
• 无效假设对应的待办项应予以移除，而不是延期

产品应用：

场景	应用方式	示例
冲刺规划	将假设验证纳入冲刺目标	“冲刺目标：验证内联编辑能否将任务耗时缩短 20%”
待办事项梳理	将实验结果附加到故事中	只有假设得到验证后，故事才会进入交付阶段
回顾会议	除交付速度外，也回顾学习速度	“本冲刺我们验证了 4 个假设，否定了 2 个”

伦理边界： 切勿以 Lean UX 为借口跳过无障碍、安全或合规要求——这些是不可妥协的质量标准，而不是需要验证的假设。

当你需要将探索纳入交付节奏时，请参阅 references/agile-integration.md，了解错开的双轨冲刺机制、故事如何承载假设，以及 UX 的完成定义。

当你需要一个可供参考的端到端实例来规划合作时，请参阅 references/case-studies.md，其中展示了四个综合场景（企业、初创公司、代理机构、内部工具），以及其中的假设、实验和前后结果指标。

常见错误

错误	失败原因	修正方法
把 MVP 当作发布版本	将 MVP 与首次发布混为一谈，导致过度构建	重新定义：MVP 是学习工具，而非产品发布
跳过假设声明	未明说的假设会变成代价高昂的意外	在启动会上安排一次 30 分钟的假设梳理会议
假设没有成功标准	无法判断实验是否通过	预先确定指标、阈值和样本量
只有设计师参与设计	交接浪费、方向不一致、迭代缓慢	与整个团队一起开展 Design Studio 活动
将研究视为一个阶段	反馈到得太晚，无法发挥作用	在每个冲刺中融入轻量级研究
忽略无效假设	构建测试失败的功能	从待办事项中移除无效项；转变方向或放弃
重记录，轻协作	撰写没人阅读的 40 页规格说明	通过共同设计建立共识，取代规格说明
衡量产出而非结果	交付的功能未能改变行为	将成功定义为行为变化，而非交付功能

快速诊断

审视任何 UX 流程或设计计划：

问题	如果答案为否	行动
是否明确声明了假设？	隐藏的假设会左右决策	开展假设梳理工作坊
是否有可测试的假设？	只是凭主观看法行事	设计前按照标准格式撰写假设
实验是否采用了能够回答问题的最低保真度？	尚未学习就投入过多	降级为纸面原型或冒烟测试
整个团队是否都参与设计？	交接造成浪费和脱节	安排一次 Design Studio 会议
是否每个冲刺都会开展研究？	反馈循环过慢	建立每周测试节奏
追踪的是结果，而不只是产出吗？	发布产品却没有从中学习	为每项功能定义行为变化指标
UX 工作能否顺畅融入 Agile？	设计成为瓶颈，或陷入冲刺零阶段	实施双轨敏捷，并错开冲刺
能否举出一个近期被证伪的假设？	没有学习；存在确认偏误	回顾实验日志，并庆祝方向调整

延伸阅读

如需了解完整的方法论、研究和案例：

• "Lean UX: Designing Great Products with Agile Teams"，作者 Jeff Gothelf 和 Josh Seiden
• "Sense and Respond"，作者 Jeff Gothelf 和 Josh Seiden（在组织中推广以结果为导向的思维）

作者简介

Jeff Gothelf 是一位组织设计师、教练和作家，曾在 TheLadders 和 Neo Innovation 等公司领导 UX 团队，拥有 15 年以上经验；亲眼见证团队在未经验证的交付成果上浪费数月后，他创立了 Lean UX。Josh Seiden 是一位设计师和产品策略师，拥有 25 年以上经验，曾与他人共同创立 Cooper 的交互设计实践，并担任 Neo Innovation 的董事总经理。两人共同撰写了 Lean UX 和 Sense and Respond。