Lean UX - Jeff Gothelf
将精益创业方法应用于 UX 设计，强调快速迭代、跨职能协作和以用户为中心的设计流程。本书介绍了如何通过 MVP（最小可行产品）和持续验证来减少浪费，提高设计效率，让设计团队更好地融入敏捷开发流程。
关于作者
Jeff Gothelf 是 Lean UX 方法的创始人：
- Lean UX 倡导者：提出精益用户体验方法论
- 敏捷教练：帮助团队实现敏捷转型
- 技术作家：著有多本关于敏捷和 UX 的书籍
- 演讲家：在全球各大会议分享 Lean UX 理念
Jeff 以其"减少浪费、快速学习"的理念著称，他帮助无数团队摆脱了传统文档驱动的设计流程，转 向更加敏捷、协作的工作方式。
核心内容
1. Lean UX 原则
Lean UX 核心原则：
1. 跨职能团队
- 设计师、开发者、产品经理紧密协作
- 打破部门壁垒
- 共同对产品负责
2. 小批量工作
- 小的设计迭代
- 快速交付
- 减少在制品
3. 持续发现
- 持续的用户研究
- 定期的用户测试
- 数据驱动决策
4. 实验驱动
- 假设先行
- A/B 测试验证
- 学习优于完美
5. 减少浪费
- 减少文档
- 减少交接
- 减少等待时间
6. 结果导向
- 关注业务结果
- 关注用户行为改变
- 而非交付物数量
2. 假设驱动设计
假设陈述模板：
"我们相信 [目标用户]
需要 [解决方案/功能]
来实现 [预期结果]
我们将通过 [指标] 来验证
当 [指标达到目标值] 时
我们就知道假设是正确的"
示例：
"我们相信 新用户
需要 快速入门引导
来实现 首次成功使用产品
我们将通过 7 日留存率 来验证
当 7 日留存率提升 10% 时
我们就知道假设是正确的"
假设类型：
1. 价值假设：用户是否认为这个功能有价值
2. 增长假设：用户是否会推荐使用
3. 可用性假设：用户是否能顺利使用
4. 可行性假设：技术是否可实现
3. MVP (最小可行产品)
MVP 类型：
1. 视频 MVP
- 用视频演示产品概念
- 测试用户兴趣
- Dropbox 的经典案例
2. 着陆页 MVP
- 创建产品 landing page
- 收集用户邮箱
- 测试市场需求
3. 人工 MVP (Wizard of Oz)
- 后台人工处理
- 前端看起来自动化
- 测试核心流程
4. 单功能 MVP
- 只实现核心功能
- 快速上线测试
- 根据反馈迭代
5. 原型 MVP
- 可交互原型
- 用户测试
- 收集定性反馈
MVP 原则：
- 最小：只包含必要功能
- 可行：能完整跑通流程
- 产品：是完整的产品体验
4. 设计冲刺
5 天设计冲刺流程：
Day 1 - Monday: 理解
- 确定目标
- 绘制用户旅程
- 专家分享知识
- 选择目标用户旅程
Day 2 - Tuesday: 构思
- 头脑风暴
- 草图绘制
- 方案收敛
- 选择最佳方案
Day 3 - Wednesday: 决定
- 故事板
- 确定原型范围
- 分配任务
- 准备原型制作
Day 4 - Thursday: 原型
- 制作可交互原型
- 准备测试脚本
- 招募测试用户
- 内部演练
Day 5 - Friday: 测试
- 5 个用户测试
- 团队观察
- 总结发现
- 决定下一步
产出：
- 验证/证伪的假设
- 用户反馈洞察
- 下一步行动计划
5. 持续发现
持续发现习惯：
1. 每周用户访谈
- 每周 3-5 个用户
- 团队轮流参与
- 记录关键洞察
2. 可用性测试
- 每周测试原型
- 5 个用户足够发现问题
- 远程测试工具
3. 数据分析
- 定义关键指标
- 建立数据看板
- 定期 review
4. 反馈收集
- 应用内反馈
- 客服工单分析
- 社交媒体监听
5. 用户画像更新
- 基于新数据更新
- 保持鲜活
- 团队共享
工具推荐：
- UserTesting: 远程用户测试
- Hotjar: 热图和录屏
- Google Analytics: 行为分析
- Typeform: 用户调研
6. 协作方法
协作实践：
1. 共享工作区
- 物理白板墙
- Miro/FigJam 在线协作
- 所有人可见进度
2. 设计工作室 (Design Studio)
- 6-8 人跨职能团队
- 快速草图 (5-10 分钟)
- 轮流展示
- 集体讨论
3. 结对设计
- 两个设计师一起
- 设计师 + 开发者
- 实时协作工具
4. 每日站会
- 15 分钟
- 昨天做了什么
- 今天计划做什么
- 有什么阻碍
5. 展示与分享 (Show & Tell)
- 每周一次
- 展示工作成果
- 全员参与
- 庆祝学习
协作原则：
- 透明度：所有人可见
- 及时性：快速反馈
- 尊重性：每个人都有价值
7. 从交付物到成果
传统 UX vs Lean UX:
传统 UX:
- 交付物：线框图、高保真、规范文档
- 流程：研究 → 设计 → 评审 → 开发 → 测试
- 成功标准：按时交付、符合规范
- 问题：文档过时、交接损耗、反馈滞后
Lean UX:
- 交付物：可工作的软件、学习成果
- 流程：假设 → 原型 → 测试 → 学习 → 迭代
- 成功标准：用户行为改变、业务指标提升
- 优势：快速验证、减少浪费、持续学习
成果指标：
虚荣指标 ❌:
- 页面浏览量
- 下载量
- 功能使用率
行动指 标 ✅:
- 转化率
- 留存率
- 任务完成率
- 用户满意度 (NPS/CSAT)
示例：
❌ "本月新增 10 万用户"
✅ "本月新用户 7 日留存从 20% 提升到 28%"
经典摘录
Lean UX 的核心是学习，而不是交付物。
好的设计团队不是交付功能，而是改变用户行为。
文档不会验证假设，只有用户会。
跨职能协作不是可选的，是必须的。
速度是竞争优势。快速迭代让你比竞争对手学得更快。
失败不是问题，不学习才是问题。
读书心得
《Lean UX》是一本关于"如何工作"的书，而不是"如何设计"的书。它帮助我重新思考设计师在团队中的角色和价值。
书中对我影响最深的是假设驱动设计的理念。之前做设计时，经常基于个人直觉或老板喜好做决策。现在会先明确假设，然后设计实验验证。这不仅减少了主观决策，也让设计决策更有说服力。
持续发现的习惯也改变了我的工作方式。用户研究不再是项目开始时的"一次性活动"，而是贯穿整个产品生命周期的日常实践。每周与用户交流，让设计决策始终基于真实的用户需求。
减少浪费的理念帮助我重新审视工作流程。哪些文档是必要的？哪些会议可以精简？哪些等待可以避免？持续优化工作流程，让团队把更多时间花在创造价值上。
对于前端开发者来说，这本书的价值在于：
- 理解设计师的思维方式：更好地与设计师协作
- 参与早期验证：开发视角帮助团队避免技术风险
- 快速原型能力：用代码帮助团队快速验证假设
- 数据驱动思维：用数据而非直觉评估设计效果
强烈推荐给在敏捷团队工作的设计师、开发者、产品经理。