lean-ux
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseLean UX Framework
Lean UX框架
A practice-driven approach to user experience design that replaces heavy deliverables with rapid experimentation, cross-functional collaboration, and continuous learning. Based on a fundamental truth: teams that obsess over pixel-perfect specs before testing with real users waste months building the wrong thing. Lean UX shifts the question from "What should we design?" to "What do we need to learn?"
一种以实践为导向的用户体验设计方法，用快速实验、跨职能协作和持续学习取代厚重的交付物。它基于一个基本事实：那些在与真实用户测试前就执着于像素级完美规格的团队，会浪费数月时间构建错误的产品。Lean UX将问题从"我们应该设计什么？"转变为"我们需要学习什么？"
Core Principle
核心原则
Outcomes over outputs. The value of a design is not measured by the fidelity of the deliverable but by the change in user behavior it produces.
The foundation: Traditional UX waterfalls requirements into wireframes, wireframes into mockups, mockups into specs, and specs into code. At every handoff, context is lost and assumptions go untested. Lean UX eliminates waste by compressing the distance between idea and evidence. Instead of debating opinions in conference rooms, teams declare assumptions, form hypotheses, run the smallest possible experiment, and let real user behavior settle the argument. Shared understanding replaces documentation. Learning velocity replaces pixel perfection.
成果优先于产出。设计的价值不在于交付物的保真度，而在于它带来的用户行为变化。
基础逻辑：传统UX瀑布流程将需求转化为线框图，线框图转化为原型图，原型图转化为规格说明，再将规格说明转化为代码。每一次交接都会丢失上下文，且假设从未经过验证。Lean UX通过缩短想法与实证之间的距离来消除浪费。团队不再在会议室里争论观点，而是明确假设、形成假说、开展最小可行实验，让真实用户行为来解决分歧。共识理解取代了文档记录，学习速度取代了像素完美。
Scoring
评分标准
Goal: 10/10. When reviewing or creating UX processes, design plans, or team workflows, rate them 0-10 based on adherence to Lean UX principles. A 10/10 means full alignment with hypothesis-driven design, minimal deliverables, collaborative practices, and outcome-focused metrics; lower scores indicate heavy-deliverable thinking or untested assumptions. Always provide the current score and specific improvements needed to reach 10/10.
目标：10/10。在评审或创建UX流程、设计方案或团队工作流时，根据对Lean UX原则的遵循程度打0-10分。10/10意味着完全符合假设驱动设计、最小化交付物、协作实践和成果导向指标；低分则表示仍存在厚重交付物思维或未验证的假设。需始终给出当前分数及达到10/10所需的具体改进措施。
1. Declaring Assumptions
1. 明确假设
Core concept: Every design starts with assumptions. Lean UX makes those assumptions explicit so they can be prioritized and tested, rather than baked invisibly into specifications.
Why it works: When assumptions remain unspoken, teams build on shaky ground and discover problems only after launch. By surfacing assumptions early, the team can focus energy on the riskiest ones first, reducing the cost of being wrong.
Key insights:
- Business assumptions define what must be true for the business to succeed (revenue model, market size, willingness to pay)
- User assumptions define who the users are, what they need, and what behaviors they exhibit
- Assumption prioritization is based on two axes: risk (how damaging if wrong) and uncertainty (how little we know)
- High-risk, high-uncertainty assumptions are tested first
- The team writes assumptions collaboratively, not in isolation
Product applications:
| Context | Application | Example |
|---|---|---|
| New feature kick-off | Assumption mapping workshop | "We assume users want to share reports with teammates" |
| Redesign initiative | Identify what you believe about current users | "We assume users leave because the dashboard is confusing" |
| Roadmap planning | Rank features by assumption risk | Prioritize features whose success depends on untested beliefs |
| Stakeholder alignment | Expose hidden assumptions across roles | PM assumes pricing works; engineer assumes scale works; designer assumes flow works |
Ethical boundary: Assumptions should be honest assessments, not post-hoc justifications for decisions already made. If leadership has already committed to a direction, acknowledge that constraint rather than pretending the assumption is open to falsification.
See: references/hypothesis-canvas.md
核心概念：每一个设计都始于假设。Lean UX将这些假设明确化，以便进行优先级排序和测试，而非将其无形地融入规格中。
优势：当假设未被明确提出时，团队会在不稳定的基础上构建产品，且只有在上线后才会发现问题。通过尽早暴露假设，团队可以将精力集中在风险最高的假设上，降低犯错成本。
关键要点：
- 业务假设定义了业务成功必须满足的条件（盈利模式、市场规模、付费意愿）
- 用户假设定义了用户是谁、他们的需求是什么以及他们的行为特征
- 假设优先级基于两个维度：风险（如果错误会造成多大损害）和不确定性（我们了解的程度）
- 高风险、高不确定性的假设优先测试
- 假设由团队协作编写，而非孤立完成
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 新功能启动会 | 假设映射工作坊 | "我们假设用户希望与同事共享报告" |
| 重设计项目 | 明确对当前用户的认知 | "我们假设用户流失是因为仪表盘过于复杂" |
| 路线图规划 | 按假设风险对功能排序 | 优先开发那些成功依赖于未验证假设的功能 |
| 利益相关者对齐 | 暴露跨角色的隐藏假设 | 产品经理假设定价可行；工程师假设可扩展性可行；设计师假设流程可行 |
伦理边界：假设应是诚实的评估，而非对已做决策的事后合理化。如果领导层已确定方向，应承认这一约束，而非假装假设可被证伪。
参考：references/hypothesis-canvas.md
2. Hypothesis Statements
2. 假说声明
Core concept: A hypothesis translates an assumption into a testable prediction. The Lean UX hypothesis format links a proposed change to a measurable outcome for a specific user segment.
Why it works: Hypotheses force precision. Instead of "make onboarding better," the team commits to a specific prediction that can be proven or disproven. This prevents scope creep, sharpens success criteria, and makes the learn step unambiguous.
Key insights:
- Standard format: "We believe [outcome] will happen if [persona] achieves [action] with [feature]"
- Every hypothesis should specify the persona, action, outcome, and measurable signal
- Sub-hypotheses break a large bet into smaller, independently testable parts
- Hypotheses are not goals; they are predictions that could be wrong
- The team must agree on what "validated" and "invalidated" look like before running an experiment
Product applications:
| Context | Application | Example |
|---|---|---|
| Feature design | Write hypothesis before wireframing | "We believe trial-to-paid conversion will increase by 10% if new users complete a guided setup wizard" |
| A/B tests | Formalize test rationale | "We believe click-through will rise 15% if we move the CTA above the fold" |
| Sprint planning | Attach hypothesis to each user story | Story: "As a user I can filter by date." Hypothesis: "We believe task completion time drops 30%" |
| Retrospectives | Review validated vs. invalidated hypotheses | "3 of 5 hypotheses validated this quarter; 2 pivoted" |
Ethical boundary: Never cherry-pick metrics after the fact to declare a hypothesis validated. Pre-commit to success criteria.
See: references/hypothesis-canvas.md
核心概念：假说将假设转化为可测试的预测。Lean UX假说格式将提议的变更与特定用户群体的可衡量成果关联起来。
优势：假说迫使团队精准思考。不再是"优化入职流程"，团队需做出可被证实或证伪的具体预测。这能防止范围蔓延、明确成功标准，并让学习步骤清晰无误。
关键要点：
- 标准格式："我们认为，如果[用户角色]通过[功能]完成[操作]，[成果]就会实现"
- 每个假说都应明确用户角色、操作、成果和可衡量信号
- 子假说将一个大的赌注分解为更小、可独立测试的部分
- 假说不是目标；它们是可能错误的预测
- 在开展实验前，团队必须就"验证通过"和"验证失败"的标准达成一致
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 功能设计 | 在绘制线框图前编写假说 | "我们认为，如果新用户完成引导式设置向导，试用转付费转化率将提升10%" |
| A/B测试 | 正式化测试理由 | "我们认为，如果将CTA按钮移至首屏上方，点击率将提升15%" |
| 冲刺规划 | 为每个用户故事附加假说 | 用户故事："作为用户，我可以按日期筛选。" 假说："我们认为任务完成时间将缩短30%" |
| 回顾会议 | 回顾已验证和未验证的假说 | "本季度5个假说中有3个得到验证，2个被推翻" |
伦理边界：绝不能在事后挑选指标来宣称假说已验证。需预先承诺成功标准。
参考：references/hypothesis-canvas.md
3. MVPs and Experiments
3. MVP与实验
Core concept: An MVP in Lean UX is the smallest design artifact that can test a hypothesis with real users. It is not a product launch; it is a learning tool.
Why it works: Heavy deliverables delay learning. A paper prototype tested with five users in a hallway can invalidate a hypothesis that would otherwise consume a full sprint of engineering. By matching experiment fidelity to the risk of the assumption, teams learn faster and waste less.
Key insights:
- Experiment types range from low fidelity (paper prototypes, concierge tests) to high fidelity (coded A/B tests, Wizard of Oz)
- Choose the lowest-fidelity experiment that can answer the question
- A good experiment has a clear hypothesis, defined audience, measurable signal, and time box
- "Proto-personas" can stand in for full research when speed matters, but must be validated later
- The goal is to learn, not to ship
Product applications:
| Context | Application | Example |
|---|---|---|
| Early concept validation | Paper prototype or clickable mockup | Sketch 3 concepts, test with 5 users same day |
| Demand validation | Landing page smoke test | "Sign up for early access" measures real interest |
| Usability validation | Clickable prototype test | Figma prototype tested with 5-8 users |
| Technical feasibility | Wizard of Oz | Manual backend, automated frontend to test experience |
| Pricing validation | Painted door test | Show pricing page, measure click-through before building billing |
Ethical boundary: Smoke tests and fake door tests must not mislead users into believing a product exists when it does not. Always disclose the test status and offer a way to opt out.
See: references/experiment-patterns.md
核心概念：Lean UX中的MVP是能够用真实用户测试假说的最小设计产物。它不是产品发布，而是一种学习工具。
优势：厚重的交付物会延迟学习进程。在走廊里用5个用户测试纸质原型，就能推翻一个原本会消耗整个冲刺周期的假说。通过匹配实验保真度与假设风险，团队能更快学习、减少浪费。
关键要点：
- 实验类型从低保真（纸质原型、礼宾测试）到高保真（编码A/B测试、绿野仙踪测试）不等
- 选择能回答问题的最低保真度实验
- 好的实验有清晰的假说、明确的受众、可衡量的信号和时间限制
- 当需要速度时，"原型用户角色"可以替代完整的用户研究，但后续必须验证
- 目标是学习，而非发布产品
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 早期概念验证 | 纸质原型或可点击原型 | 绘制3个概念，当天用5个用户测试 |
| 需求验证 | 着陆页烟雾测试 | "注册获取早期访问权限"衡量真实兴趣 |
| 可用性验证 | 可点击原型测试 | 用5-8个用户测试Figma原型 |
| 技术可行性验证 | 绿野仙踪测试 | 手动后端+自动化前端来测试体验 |
| 定价验证 | 画门测试 | 展示定价页面，在构建计费系统前衡量点击率 |
伦理边界：烟雾测试和画门测试不得误导用户，让他们相信产品已存在。需始终披露测试状态，并提供退出方式。
参考：references/experiment-patterns.md
4. Collaborative Design
4. 协作式设计
Core concept: Design is a team sport. Lean UX replaces the solitary designer-then-handoff model with cross-functional design sessions where developers, product managers, and designers sketch solutions together.
Why it works: When the whole team participates in design, shared understanding replaces documentation. Developers who helped sketch the solution do not need a 40-page spec to build it. Diverse perspectives generate more creative solutions. Handoff waste drops dramatically.
Key insights:
- Design Studio method: diverge (individual sketching), present, critique, converge (refined sketch), iterate
- Shared understanding is the currency of Lean UX; it replaces heavy documentation
- Style guides and pattern libraries are living documents, not static PDFs
- The goal is not consensus but informed commitment: the team agrees on what to test, not what is "right"
- Cross-functional participation means engineers, QA, data analysts, and stakeholders sketch too
- Reduce UX deliverables to the minimum needed for shared understanding (often a whiteboard photo)
Product applications:
| Context | Application | Example |
|---|---|---|
| Sprint kick-off | Design Studio session (90 minutes) | Whole team sketches solutions to the sprint's hypothesis |
| Feature exploration | Collaborative sketching workshop | 6-up sketches: each person draws 6 ideas in 5 minutes |
| Design system maintenance | Living style guide updates | Engineers and designers update the guide together as they build |
| Remote teams | Virtual whiteboard sessions | FigJam or Miro board with timed sketch rounds |
Ethical boundary: Collaboration must not become design by committee. A designated designer synthesizes input; the team does not vote on pixels.
See: references/collaborative-design.md
核心概念：设计是团队协作的工作。Lean UX取代了设计师单独完成再交接的模式，采用跨职能设计会议，让开发人员、产品经理和设计师一起构思解决方案。
优势：当整个团队参与设计时，共识理解取代了文档记录。参与构思解决方案的开发人员不需要40页的规格说明就能构建产品。多样化的视角能产生更多创意解决方案，交接浪费大幅减少。
关键要点：
- 设计工作室方法：发散（个人草图）、展示、评审、收敛（优化草图）、迭代
- 共识理解是Lean UX的核心，它取代了厚重的文档
- 风格指南和模式库是活文档，而非静态PDF
- 目标不是达成共识，而是做出知情承诺：团队就测试内容达成一致，而非判定什么是"正确的"
- 跨职能参与意味着工程师、QA、数据分析师和利益相关者也要参与草图绘制
- 将UX交付物减少到共识理解所需的最低限度（通常是白板照片）
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 冲刺启动会 | 设计工作室会议（90分钟） | 整个团队针对冲刺的假说构思解决方案草图 |
| 功能探索 | 协作式草图工作坊 | 6格草图：每人在5分钟内绘制6个想法 |
| 设计系统维护 | 活风格指南更新 | 工程师和设计师在构建时共同更新指南 |
| 远程团队 | 虚拟白板会议 | 用FigJam或Miro白板进行定时草图绘制环节 |
伦理边界：协作不能变成委员会式设计。指定设计师整合输入；团队不投票决定像素细节。
参考：references/collaborative-design.md
5. Feedback and Research
5. 反馈与研究
Core concept: Continuous, lightweight research replaces big-bang usability studies. Lean UX embeds research into every sprint so teams learn from real user behavior constantly rather than quarterly.
Why it works: Feedback that arrives months after a design decision is too late to influence it. By running small research activities every sprint, teams correct course incrementally. The cost of each research activity is low, so the team can afford to test frequently.
Key insights:
- Research types: usability tests (5 users), customer interviews, A/B tests, analytics review, surveys, diary studies
- Five users uncover approximately 85% of usability problems (Nielsen)
- Continuous research cadence: recruit weekly, test weekly, synthesize weekly
- Research is not a phase; it is an ongoing activity embedded in every sprint
- The whole team should observe at least some research sessions to build empathy
- Proto-personas are refined and eventually replaced by evidence-based personas
Product applications:
| Context | Application | Example |
|---|---|---|
| Weekly usability testing | Test prototype with 3-5 users every Thursday | "Testing Thursday" ritual with rotating facilitators |
| Post-launch learning | Monitor analytics + run 3 follow-up interviews | Identify drop-off points, interview users who churned |
| Persona validation | Compare proto-persona assumptions to interview data | "We assumed power users are marketers; data shows they are ops managers" |
| Competitive research | Lightweight competitive teardown each quarter | Team reviews 3 competitors for 30 minutes, captures patterns |
Ethical boundary: User research must be conducted with informed consent. Participants should understand how their data will be used and have the right to withdraw.
See: references/experiment-patterns.md
核心概念：持续的轻量化研究取代了大规模的可用性研究。Lean UX将研究嵌入每个冲刺，让团队持续从真实用户行为中学习，而非按季度开展研究。
优势：在设计决策做出数月后才收到的反馈，对决策已无影响。通过在每个冲刺开展小型研究活动，团队可以逐步调整方向。每个研究活动的成本都很低，因此团队可以频繁测试。
关键要点：
- 研究类型：可用性测试（5个用户）、客户访谈、A/B测试、数据分析、调研、日记研究
- 5个用户能发现约85%的可用性问题（尼尔森研究）
- 持续研究节奏：每周招募用户、每周测试、每周整合结果
- 研究不是一个阶段，而是嵌入每个冲刺的持续活动
- 整个团队都应观察至少部分研究环节，以建立同理心
- 原型用户角色会逐步完善，最终被基于实证的用户角色取代
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 每周可用性测试 | 每周四用3-5个用户测试原型 | "测试周四"惯例，轮换主持人 |
| 上线后学习 | 监控分析数据+开展3次后续访谈 | 识别流失点，访谈流失用户 |
| 用户角色验证 | 将原型用户角色假设与访谈数据对比 | "我们认为核心用户是营销人员；数据显示是运营经理" |
| 竞品研究 | 每季度开展轻量化竞品拆解 | 团队用30分钟评审3个竞品，捕捉模式 |
伦理边界：用户研究必须在知情同意的前提下进行。参与者应了解其数据的使用方式，并有权退出。
参考：references/experiment-patterns.md
6. Integration with Agile
6. 与Agile集成
Core concept: Lean UX is designed to work inside Agile development. Dual-track agile separates discovery (learning what to build) from delivery (building it), running both tracks in parallel.
Why it works: Traditional UX struggles in Agile because design work does not fit neatly into a sprint. Dual-track solves this by running discovery one sprint ahead of delivery. The discovery track generates validated hypotheses and tested prototypes; the delivery track turns them into shippable software.
Key insights:
- Dual-track agile: discovery track (research + design) feeds the delivery track (engineering + QA)
- Discovery runs one sprint ahead, so validated designs are ready when the delivery sprint begins
- Staggered sprints prevent the "sprint zero" anti-pattern where design is always catching up
- User stories gain a hypothesis and success metric alongside acceptance criteria
- "Definition of Done" for UX includes validated learning, not just shipped pixels
- Backlog items from invalidated hypotheses are removed, not deferred
Product applications:
| Context | Application | Example |
|---|---|---|
| Sprint planning | Include hypothesis validation in sprint goals | "Sprint goal: validate that inline editing reduces task time by 20%" |
| Backlog refinement | Attach experiment results to stories | Story moves to delivery only after hypothesis is validated |
| Retrospectives | Review learning velocity alongside delivery velocity | "We validated 4 hypotheses and invalidated 2 this sprint" |
| Roadmap updates | Adjust roadmap based on experiment outcomes | Invalidated feature removed from Q3 roadmap |
Ethical boundary: Do not use Lean UX as an excuse to skip accessibility, security, or compliance work. These are non-negotiable quality standards, not assumptions to be tested.
See: references/agile-integration.md
核心概念：Lean UX专为在Agile开发环境中工作而设计。双轨Agile将探索（学习要构建什么）与交付（构建产品）分离，并行运行两条轨道。
优势：传统UX在Agile中难以落地，因为设计工作无法完美适配冲刺周期。双轨模式通过让探索轨道比交付轨道提前一个冲刺来解决这一问题。探索轨道生成已验证的假说和经过测试的原型；交付轨道将它们转化为可发布的软件。
关键要点：
- 双轨Agile：探索轨道（研究+设计）为交付轨道（工程+QA）提供输入
- 探索轨道提前一个冲刺运行，因此当交付冲刺开始时，已验证的设计已准备就绪
- 交错冲刺避免了"冲刺零"反模式，即设计总是跟不上进度
- 用户故事除了验收标准外，还附加了假说和成功指标
- UX的"完成定义"包括已验证的学习，而非仅发布的像素
- 未验证的假说对应的待办事项将被移除，而非推迟
产品应用场景：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 冲刺规划 | 将假说验证纳入冲刺目标 | "冲刺目标：验证内联编辑是否将任务时间缩短20%" |
| 待办事项细化 | 为故事附加实验结果 | 只有当假说得到验证后，故事才会进入交付环节 |
| 回顾会议 | 同时回顾学习速度和交付速度 | "本季度我们验证了4个假说，推翻了2个" |
| 路线图更新 | 根据实验结果调整路线图 | 未验证的功能从Q3路线图中移除 |
伦理边界：不得将Lean UX作为跳过可访问性、安全性或合规工作的借口。这些是不可协商的质量标准，而非可测试的假设。
参考：references/agile-integration.md
Common Mistakes
常见误区
| Mistake | Why It Fails | Fix |
|---|---|---|
| Treating MVPs as launches | Team over-builds because they conflate "minimum viable product" with "first release" | Reframe: MVP = learning tool, not product launch |
| Skipping assumption declaration | Hidden assumptions become expensive surprises | Run a 30-minute assumption mapping session at kick-off |
| Hypothesis without success criteria | Cannot determine if experiment passed or failed | Pre-commit to metric, threshold, and sample size |
| Designer-only design | Handoff waste, misalignment, slow iteration | Run Design Studio sessions with the full cross-functional team |
| Research as a phase | Feedback arrives too late to influence decisions | Embed lightweight research into every sprint |
| Ignoring invalidated hypotheses | Team builds features that failed testing | Remove invalidated items from backlog; pivot or drop |
| Documenting instead of collaborating | 40-page specs nobody reads | Replace specs with shared understanding from collaborative sessions |
| Measuring outputs not outcomes | Shipping features that do not change behavior | Define success as behavior change, not feature delivery |
| 误区 | 失败原因 | 解决方法 |
|---|---|---|
| 将MVP视为产品发布 | 团队过度构建，因为他们将"最小可行产品"与"首次发布"混淆 | 重新定义：MVP = 学习工具，而非产品发布 |
| 跳过假设明确环节 | 隐藏的假设会变成昂贵的意外 | 在启动会时开展30分钟的假设映射工作坊 |
| 假说无成功标准 | 无法判断实验是否通过 | 预先承诺指标、阈值和样本量 |
| 仅由设计师完成设计 | 交接浪费、对齐偏差、迭代缓慢 | 与整个跨职能团队开展设计工作室会议 |
| 研究作为一个阶段 | 反馈来得太晚，无法影响决策 | 将轻量化研究嵌入每个冲刺 |
| 忽略未验证的假说 | 团队构建已测试失败的功能 | 从未验证的待办事项中移除相关条目；转向或放弃 |
| 用文档代替协作 | 40页的规格说明无人阅读 | 用协作会议达成的共识理解取代规格说明 |
| 衡量产出而非成果 | 发布的功能无法改变用户行为 | 将成功定义为用户行为变化，而非功能交付 |
Quick Diagnostic
快速诊断
Audit any UX process or design plan:
| Question | If No | Action |
|---|---|---|
| Are assumptions explicitly declared? | Hidden assumptions drive decisions | Run assumption mapping workshop |
| Is there a testable hypothesis? | Team is building on opinion | Write hypothesis in standard format before designing |
| Is the experiment the lowest fidelity that can answer the question? | Over-investing before learning | Downgrade to paper prototype or smoke test |
| Does the whole team participate in design? | Handoff waste and misalignment | Schedule a Design Studio session |
| Is research happening every sprint? | Feedback loop is too slow | Establish weekly testing cadence |
| Are you tracking outcomes, not just outputs? | Shipping without learning | Define behavior-change metrics for each feature |
| Does UX work feed into Agile smoothly? | Design bottleneck or sprint zero trap | Implement dual-track agile with staggered sprints |
| Can you point to a hypothesis you invalidated recently? | Team is not learning; confirmation bias | Review experiment log and celebrate a pivot |
审计任何UX流程或设计方案：
| 问题 | 如果答案为否 | 行动 |
|---|---|---|
| 假设是否已明确提出？ | 隐藏假设驱动决策 | 开展30分钟的假设映射工作坊 |
| 是否有可测试的假说？ | 团队基于观点构建产品 | 在设计前按标准格式编写假说 |
| 实验是否是能回答问题的最低保真度？ | 在学习前过度投入 | 降级为纸质原型或烟雾测试 |
| 整个团队是否参与设计？ | 交接浪费和对齐偏差 | 安排设计工作室会议 |
| 是否每个冲刺都开展研究？ | 反馈循环过慢 | 建立每周测试节奏 |
| 你是否在跟踪成果，而非仅产出？ | 发布产品但未学习 | 为每个功能定义用户行为变化指标 |
| UX工作是否能顺畅融入Agile？ | 设计瓶颈或冲刺零陷阱 | 采用交错冲刺的双轨Agile |
| 你能否指出最近被推翻的一个假说？ | 团队未学习；存在确认偏差 | 回顾实验日志，并为转向庆祝 |
Reference Files
参考文件
- hypothesis-canvas.md: Hypothesis statement format, assumption prioritization matrix, business vs. user assumptions, sub-hypotheses
- experiment-patterns.md: UX experiment types, choosing the right experiment, experiment design template, minimum viable tests
- collaborative-design.md: Design Studio method, collaborative sketching, cross-functional design, living style guides
- agile-integration.md: Dual-track agile, fitting UX into sprints, staggered sprints, Definition of Done for UX
- outcome-metrics.md: Outcomes vs. outputs, leading vs. lagging indicators, OKRs for UX, vanity metrics to avoid
- case-studies.md: Enterprise product team, startup, agency, and internal tools team scenarios
- hypothesis-canvas.md：假说声明格式、假设优先级矩阵、业务与用户假设、子假说
- experiment-patterns.md：UX实验类型、实验选择、实验设计模板、最小可行测试
- collaborative-design.md：设计工作室方法、协作式草图、跨职能设计、活风格指南
- agile-integration.md：双轨Agile、UX适配冲刺、交错冲刺、UX的完成定义
- outcome-metrics.md：成果与产出、领先与滞后指标、UX OKRs、需避免的虚荣指标
- case-studies.md：企业产品团队、创业公司、代理机构和内部工具团队场景
Further Reading
延伸阅读
This skill is based on Lean UX principles developed by Jeff Gothelf and Josh Seiden. For the complete methodology, research, and case studies:
- "Lean UX: Designing Great Products with Agile Teams" by Jeff Gothelf & Josh Seiden
- "Sense and Respond" by Jeff Gothelf & Josh Seiden (scaling outcome-focused thinking across organizations)
About the Authors
关于作者
Jeff Gothelf is an organizational designer, coach, and author who helps companies build better products and cultivate outcome-focused cultures. He spent over 15 years as a UX designer and team leader at agencies and product companies, including TheLadders, Publicis Modem, and Neo Innovation (now Pivotal Labs). His experience watching teams waste months on unvalidated deliverables led him to develop Lean UX as a practical fusion of design thinking, Agile development, and lean startup principles. Gothelf coaches Fortune 500 companies and speaks internationally on product management, organizational agility, and evidence-based design.
Josh Seiden is a designer, product strategist, and coach with over 25 years of experience helping teams build digital products. He co-founded the interaction design practice at Cooper, one of the first UX consultancies, and later served as Managing Director at Neo Innovation. Seiden specializes in helping organizations shift from output-driven to outcome-driven ways of working. Together with Gothelf, he co-authored Lean UX and Sense and Respond, both of which have become essential reading for product teams adopting Agile and Lean practices.
Jeff Gothelf是组织设计师、教练和作家，帮助企业构建更好的产品并培养成果导向的文化。他在代理机构和产品公司拥有超过15年的UX设计师和团队负责人经验，包括TheLadders、Publicis Modem和Neo Innovation（现Pivotal Labs）。他目睹了团队在未验证的交付物上浪费数月时间，因此将设计思维、Agile开发和精益创业原则融合，开发了实用的Lean UX方法。Gothelf为财富500强企业提供教练服务，并在国际上发表关于产品管理、组织敏捷性和基于实证的设计的演讲。
Josh Seiden是设计师、产品策略师和教练，拥有超过25年帮助团队构建数字产品的经验。他共同创立了Cooper的交互设计实践，这是最早的UX咨询公司之一，后来担任Neo Innovation的董事总经理。Seiden专注于帮助组织从产出导向转向成果导向。他与Gothelf合著了《Lean UX》和《Sense and Respond》，这两本书已成为采用Agile和Lean实践的产品团队的必读资料。