精益 UX 是敏捷开发方式里一个非常有用的 UX 方法。传统的 UX 在紧急开发情况下经常不能适——没有足够的时间用同样的方式交付 UX 。基本上精益 UX 与其他形式的 UX 都有着一样的目标；只是提供好的用户体验的工作方式略有不同。所以让我们看一下精益 UX 是如何执行的。

精益 UX 是什么？

精益 UX 专注于设计体验，与传统 UX 相比较对可交付成果关注更少，需要整个团队更好地合作，核心目的专注于更快地获得更好的回馈，使其可被用来快速决策。敏捷开发的原则是在快速的迭代循环中工作，精益 UX 跟这个循环类似，并确保所产生的的数据能快速用于迭代。

精益 UX 下对假设的需求

传统 UX 下项目建立在需求的捕捉和可交付成果，其目的是确保可交付成果越详细越好并且适当的回应那些在项目开始时的需求。

精益 UX 则有些不同。你不是专注于可交付成果的细节，而是要产生一些改变，并藉此改善产品——其本质是让你的结果变得更好。

实际上精益 UX 是从挖掘“需求（requirements）”并使用“问题状态（problem statement）” ，引出一系列可以被用来创造假说（hypotheses）的假设（assumption）。

什么是假设？

假设是我们认为某件事情是真实的基本陈述，假设被设计用来让人们开始对某个想法产生真实的理解。假设可能不是正确的，当团队中出现更好的见解时它也可能在项目的执行中被更改。

假设通常由团队提出。你可以让整个团队阐述问题并允许团队头脑风暴他们的想法来解决问题。在过程中你会产出一些针对特定问题的答案，而这可以形成你的假设。

典型的问题可能包含：

谁是我们的使用者？

这产品是用来做什么的？

什么时候会被用？

什么情境下会被用？

什么将会是最重要的功能？

在产品的交付上什么会是最大的风险？

每一个问题都可能有超过一个以上的答案。实际上一次只采用一种解决方案，而假设可以形成很多个。这种情况下，团队可以快速给出假设优先顺序。一般而言，会将假设的优先顺序按照它们所代表的风险（严重的错误会导致怎样的后果？越严重的后果，它的优先顺序就越前面）和目前对于问题理解的程度（对其越少的了解，优先顺序就越高）。

在精益 UX 中创造假说

在精益 UX 中所创造的假说，被设计来测试我们的假设。这里有简单的格式你可以使用来创造你自己的假设，快速且容易。

举例：

我们相信在任何时间让人们储存他们的进度对手机用户是必须的。这会实现更多的完成注册。当我们测试完成率提升百分之二十，我们将会采用它。

我们阐述我们的信念以及为什么它很重要和对谁重要。我们会遵循它并伴随什么是我们所期待达成的。最后，我们会查明什么样的证据是我们需要用来证明我们的信念是对的。

如果我们发现没有方法可以证明我们的假说 — 我们可能朝着错误的方向因为我们的结果没有明确地被定义。

这种工作方法的其中一个大的优势是，消除很多的“我不觉得这是一个好的想法”和 UX 设计过程中的内部争论。每一个想法和证据的证明都将清楚地被证明。没有证据？那就是时候放弃这个想法去尝试其他的。

如果每个人都能理解假设及其期望，那么他们会乐于等待看看它是真的，而非一股脑儿争论自己主观的意见。

最小可行化产品与精益 UX

最小可行性产品（Minimum Viable Product）是精益 UX 的核心概念， MVP 是指建立一个概念的最基础版本，测试它，假使没有任何有价值的结果那就放弃它。 MVPs 可以被纳入将来的设计，并且围绕它开发没有太多的麻烦。

这是最大化资源利用率的一个伟大的方式，并且它与敏捷开发相辅相成的原因是：它允许大量的实验，并非不可更改。

精益 UX 中的用户研究与测试

精益 UX 中的用户研究与测试跟传统 UX 环境下使用着一样的原理。然而，进行的方式倾向于“快速直接” ——在下一个敏捷 Sprint 开始前结果就需要被提交；所以较少的著重在厚重的，缜密的文件，更多著重于原始资料。

研究的责任也倾向于跨整个团队更广泛地展开，使团队中没有因为让一个单独的 UX 设计资源尝试着在紧迫的时间下完成所有工作而产生“瓶颈”。这通常使研发也“亲身体验” UX 中的工作，一定程度上增加了开发团队对 UX 工作的理解和支持。

结论

这些基本的概念应该能让你在敏捷开发环境中导入精益 UX 时朝着正确的方向。

本文由吆喝科技编译自：www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux