敏捷的用户体验项目

翻译：Cathy

英文原文：http://www.useit.com/alertbox/agile-user-experience.html

总结：

 

 

到目前为止敏捷项目并非完全以用户为导向的，但新的研究显示：在关键的用户体验问题上，开发人员比用户体验人员更有信心。

 

 

去年我们进行了一项研究，研究的对象是一些将可用性方法与敏捷开发项目结合得最好实践案例。

 

 

通常，一个研究时间刚过去一年的问题是不值得再次拿来研究的，因为用户行为在短时间内变化不大。但这个项目与用户行为无关，它主要研究敏捷项目实施中确保可用性的最好方法。

 

 

因为这还是一个新的领域，所以我们决定用新一轮更加细致的研究来补充去年的研究结果。这一轮研究主要集中在另外一些组织上，这些组织有更多时间来发现管理敏捷用户体验的更好方法。

 

 

用户体验：看门人的角色

 

 

在敏捷项目中，确保可用性的两个主要建议与我们原来的研究相同：

 

l 将设计和开发分开，让用户界面设计团队的进度先于实施团队一步。这样如果要着手做什么东西的时候，它已经设计好并经过测试了。（对了，你可以在一周或者两周的时间内通过使用纸上原型和打折的用户测试来完成这两项）

l 保持用户界面架构视图的和谐。开始实施前首先做一个视图，然后通过图形化设计综合工具界面一年或者半年维护一次。不能仅仅设计单个的功能；必须形成一个和谐的整体——而且必须是经过设计的。一个步骤颠倒的用户界面设计流程基本上会产生让人疑惑的用户体验。

 

在这两轮研究中，上述的两个建议在我们对许多不同公司的研究中都被证明是很有用的。很显然，在第二轮研究中，我们必须做出一个修改，这个想法是通过研究Paypal案例后得出的：派一个看门人跟踪用户体验团队与其它项目团队的需求以及交流以确保每个人都跟上，这一点是很重要的（尽管他们的流程是平行的）。

Circle D设计在这个问题上采用了另一个做法。他们为每个项目的用户体验交流都指派了一个主持人。因为每一个项目需要新的用户体验专员，于是他们就与主持人合作。由于主持人要周期性地进行轮值，那这个办法就支持了长期的跨团队交流。

集中的用户体验部门变得不常见了

可用性，交互设计，技术写作以及其它特定分队应该分别放在组织图的哪个个位置上，这个问题争论了很久。这里有两方观点：

l 集中的结构只有一个团队，团队有它的原则并将这个原则提供给跨组织项目的开发团队。例如，一个集中的可用性团队可以提供所有的交互设计和视觉设计；而一个集中的用户体验团队可以提供所有的设计和研究。然后项目团队就会采用集中团队的设计和/或研究并将其转化成一个实际的产品。

l 分散的结构放弃了集中化，取而代之的是分派专业人员直接组成个项目团队。在这个结构中，每个项目团队都有自己的可用性专员，交互设计师，视觉设计师，信息架构师，技术写作员等等。事实上，大的项目团队里面可能有几个这样的专员。

分散结构的一个明显缺点是：公司往往没有足够的用户体验专员分派给一个项目团队的每个分队。因此，各个不同的分队可能要共用一些专员或者干脆没有这些专员的参与。

集中的结构为专业人员提供了一个“家”。他们喜欢与团队成员保持亲密的关系。这样专业人员的管理和晋升就变得更简单了。例如，一个集中的可用性团队的经理通常是一个高级的可用性专员，而一个集中的设计团队的经理是一个高级的设计师，用户体验部门的经理就是一个级别更高的设计师或者可用性人员。这些经理了解他们员工的任务和需要。（相反，一个向研发经理汇报的的可用性专员往往会发现经理对研究情况的好坏一无所知。）

集中的部门也支持跨各研发项目的战略性主动步骤。这样的例子可以在设立和维护用户界面标准或准则，建立可用性实验室，收集纵向或比较的用户体验度量以及促进组织成熟度等方面找到——比如，通过向上级管理人员交流战略性的用户体验问题，然后说服他们在提高可用性上投入更多的资金。

所有这些都很好，但是如果将可用性以及好的用户体验与敏捷开发团队结合起来的话就有问题了。根据我们从案例研究中得出的经验，用户体验人员必须与开发人员和其它的项目团队人员一起。事实上，用户体验团队应该看成是项目团队的一部分，而不是一个外在的部门。

将用户体验团队部门的人员分散并不意味着你要放弃一个集中的专业团队能够带来的所有益处。通常，基地组织提供了一个好的解决方法，每天它都让用户体验的专业人员成为各个项目的一份子，但与此同时又能让他们进行整个公司范围内的协调工作。

敏捷的用户体验是好的，但可以更好

今年，我们询问研究参与者用户体验与他们的项目结合度有多高以及对目前进行的采用特殊研究方法进行的项目满意度有多高。用数字1-5来表示他们的答案，其中5代表最高程度的结合度和满意度。

一般程序方法论	用户体验的综合	这种方法的满意度
瀑布	2.5	2.9
敏捷	3.1	3.7
反覆	3.2	3.8

 

很显然，敏捷开发比原来的WATERFALL好得多。那个我们就不看了。但是，在我们最新进行的研究里，专业人员仍然觉得ITERATIVE 设计比敏捷设计要好一点；对于让敏捷项目更加注重用户，还有一些事情是可以做的。

还有一条更好的消息，最近的数据证明，我们超越了“他们和我们”——总的来说，开发人员在一些关键的用户体验意见度量上更加有信心。

开发人员将用户体验对输送质量的影响打出了4.3分，然而用户体验打4.0分（同样是1-5，5分最好）。开发人员说随着用户体验部门的参与，生产率有了一定程度的提高，但是用户体验部门给出的分仅仅比3.4高一点。开发人员和用户体验专业人员都强烈要求用户体验人员更多地参与到项目中来。在那些试图将可用性与敏捷性结合起来的公司中，一切还没有达到完美的程度但是已经很好了。