用户体验的敏捷与精益

　　最近我见过很多关于敏捷用户体验和精益用户体验二者之间的区别是什么的讨论。我很高兴并带有愧疚地承认，我曾经也交替使用过这些术语，似乎他们都是一种更轻量级的，与用户体验的迭代方法有关。但是，当我最近受邀参加一个精益用户体验圆桌小组后，我认为这将是一个很好的机会来展示他们究竟有何不同。
　　这是我制作的幻灯片：
　　该图解释了传统用户体验、敏捷用户体验和精益用户体验的关联与差异。
　　传统的用户体验它并不是突然凭空就消失了
　　我以为有一点很容易想到，因为你采取了一种敏捷的和或精益的方法来执行用户体验实践，所有传统的用户体验原则突然就凭空消失了。除此之外再也无法进一步得出结论。随着体验质量成为产品获得成功的永久性关键因素后（换句话说，如果你有10个应用程序可供选择，他们的基特征本上都有相同，你认为人们会选择哪个？），可用性和好设计的原则依旧有着举足轻重地位，但这一切却让用户体验设计师一直犹豫不决了几个世纪（咳咳）。好设计就是好设计，不管我们是生活在一个敏捷或精益或〔插入新的术语〕的领域中。唯一真正的区别是，当我们采用这些方法的时候，如何去使用。这才是敏捷和精益用户体验的全部精髓。
　　敏捷用户体验协作和交付
　　敏捷开发一词是由企业开发者创造的，是从一个开发者的角度去看待软件产品，类似于一个在一家餐馆的厨房工作人看餐厅的感觉。这不是说的东西都摆在房子的前面，餐厅的体验部分并不像看起来那么重要，因为它不是主要的焦点。此外，在将敏捷开发作为主要焦点老牌企业中，软件产品则更类似于遵循一种体制上的餐厅，话句话说，是一种功利性很强的系统，其中的重点是提供所需的功能，而不是好的用户体验。沃德坎宁安，一个敏捷宣言的原始签署者，曾在库珀对敏捷用户体验重新探讨时说，敏捷就是快速供应热食。
　　基本上，敏捷开发指工作软件的高质量和高速度交付。在敏捷开发领域，这是想要获得进步的根本措施。然而，在实践敏捷宣言的过程中发生了一件有趣的事。想要快速推出一款优秀的软件，事实证明需要与一种叫做人的、既麻烦又非二进制的物体进行高效的合作才行。尽管用户体验设计到此时基本上还是默默无闻的，但敏捷开发的思维提供了一个能够产生转变的基本的范式，即如何与你的团队成员进行基本的和深层次的交流沟通。
　　所以，虽然软件交付（如自动化所有可以自动的东西）方面的敏捷开发思维值得用户体验设计师从中学习很多，但真正的值得用户体验从业者学习的成果，其中关于合作的那一部分。敏捷用户体验的方法，诸如组成设计工作室和跨职能的配对，让用户体验从业人员可以用快捷有效的直接互动沟通取代曾经缓慢的纸面文档阅读。换句话说，一项敏捷用户体验实践，就是一项用以协作中心取代以文档为中心的实践。这是一名敏捷开发团队中的用户体验设计者需要做的一件大事，因为这种转变，是让设计人员将自己的和敏捷开发人员的实践能够整合到一起的关键所在。
　　精益（创业）用户体验测量和验证产品和市场的适应程度
　　现在我们有了这个伟大的敏捷开发机制可以让我们以疯狂的效率将软件推向市场，这是很酷的。但是，嗯，有人去看看我们推出的软件是否是合适的呢？精益用户体验方法向我们表明，软件的推出在敏捷开发领域基本上算是大功告成了，可真实的情况是，这只是个开始。敏捷开发方法有助于用户体验设计师们转变旧的设计方式，将沟通作为他们的头等任务，精益用户体验则颠覆了我们在调查研究和检测质量方面的陈旧的方法。
　　在传统的模型中，调查研究的是你在开始创建产品之前所做的事，这么做是为了弄明白你所要创建的是一件什么样的产品。在精益的方法中，则需要不断建立和收集与我们所创建产品相关的度量值。这种最典型的例子是对登陆页面的度量收集，这个做法是在项目开始启动时就创立和实施的，而不是在即将完成产品时才开始。我们将曾经只是被视为营销失误的做法变成一个实际的假设实验，这样别人会认为我们的想法与我们之前所设想的是一样的。然后，从登陆页面搜集到的数据内容（或者它可以演变成一个完整的度量收集网站）被反馈到产品设计当中。