VOCABULARY / 词条
精益 UX
Lean UX
把设计工作当作一连串需要验证的假设：团队先写下想达成的成果与背后的假设，用最少的工作做一个实验去检验风险最大的那一条，再根据结果决定继续、调整还是放弃；它借用精益创业"构建—衡量—学习"的循环，衡量进展的是学到了什么，而不是交付了多少文档。
识别特征
- 工作以"我们相信……如果……"式的假设陈述来组织，而不是以功能清单来组织
- 团队先确定这一轮最需要学到的一件事，再找验证它所需的最少工作
- 目标写成可观察的用户行为变化，而不是要交付的界面数量
概念边界
精益 UX 不等于"少做设计"或跳过研究：它减少的是不帮助学习的交付物，而不是对用户的理解。它也不等于敏捷开发本身——它是一种在敏捷节奏中组织设计与产品发现的方式，Gothelf 最早的文章就说明它也可以用在瀑布流程里。它不同于参与式设计：精益 UX 让用户以实验对象与反馈来源的身份参与，方向与取舍仍由产品团队根据证据决定；参与式设计要求受影响的人本身掌握部分决策权。用户在实验中给出了反馈，并不等于他们参与了决定。
什么时候考虑它
- 方向存在较大不确定性，做错的代价高于多做一次实验
- 团队能频繁接触真实用户并在短周期内看到结果
- 设计、产品与工程愿意共同承担对成果的判断，而不是逐级交接文档
什么时候慎用
- 错误代价不可逆或涉及安全、合规，不能拿真实用户做粗糙的实验
- 把"最小可行"当作长期交付低质量产品的理由
- 实验指标只看短期点击，忽视了难以量化的长期影响
取舍
把方案写成假设、用小实验尽早验证，能在投入大量开发之前发现方向错误，也让团队讨论证据而不是意见；代价是它依赖能被快速衡量的信号，对难以量化或需要长期观察的影响不敏感，而频繁的小实验本身也会消耗用户的耐心与信任。
条件规则 · 编辑建议
相关词条
两者都让用户频繁进入设计过程，但精益 UX 中用户是实验对象与反馈来源，决定仍由团队依据证据做出；参与式设计中受影响的人本身拥有部分决策权。
以人为中心的设计提供对需求与情境的理解，精益 UX 把这些理解写成可检验的假设并安排实验顺序。
精益 UX 适合方向已定、需要快速验证的阶段；问题本身尚不清楚时，双钻模型对问题定义的强调更合适。
以点击或转化为成果的实验可能在不知不觉中损害隐私、自主等难以量化的价值；需要事先说明哪些价值不能被实验交换。
来源与支持范围
Jeff Gothelf 在 2011 年 3 月 7 日的这篇文章中介绍精益 UX：它受精益与敏捷开发理论启发，关注体验本身而不是文档；只做核心流程的原型并尽早拿去给用户测试，经过验证的原型即可充当规格说明，繁重的交付物被视为浪费；与整个团队的协作对产品成败至关重要；文章还说明它聚焦设计阶段，因此在瀑布或敏捷流程下都可使用。本词条关于"减少不帮助学习的交付物"与"不等于敏捷本身"的说法据此转述。
检索日期：2026-10-20 · 快照待确认Gothelf 在 2021 年 6 月 28 日的这篇文章中介绍他与 Josh Seiden 在《Lean UX》一书中使用的精益 UX 画布：依次写下业务问题、以客户行为变化表示的业务成果、用户、用户收益与可能的方案，再把它们组合成"我们相信……"式的假设陈述，找出其中风险最大、最需要先学到的一点，并设计验证它所需的最少工作（如访谈、原型、落地页或 A/B 测试）。本词条的定义与"假设陈述、最需要学到的一件事、最少工作"的特征据此转述。
检索日期：2026-10-20 · 快照待确认该页列出精益创业的原则：把想法变成产品、观察客户反应、再决定转向还是坚持的"构建—衡量—学习"反馈循环应尽量加快；用最小可行产品（MVP）尽早开始学习；进展的单位是经过验证的学习。本词条只据此说明精益 UX 所借用的循环与"以学习衡量进展"的观念；把两者联系起来是本词条的编辑判断。
检索日期：2026-10-20 · 快照待确认定义参考以上来源；数字界面示例、选择建议、条件关系及配方由本样例编辑，尚未经用户研究验证。
类型扩展与实现说明
本词条尚无可操作示例；插画为编辑示意，以一个循环表现假设、实验与学习，不复制任何书中的画布原图。应用到团队之前仍须写下具体的假设、实验方法与停止条件。
{
"values": [
"进展以学到的东西衡量，而不是以交付的数量衡量",
"方案在被证明之前都只是假设"
],
"tension": "快速学习的速度与长期、难以量化的影响之间",
"questions": [
"这一轮我们最需要学到的是什么？",
"验证它所需的最少工作是什么？",
"这个实验会让哪些人承担代价？"
]
}打开本词条的 Agent JSON 文件这个文件原样收录本词条的全部字段，并附上来源、存档与编辑声明。