敏捷可用性

可用性专家和《可用性工程》的作者 Jakob Nielsen ，最近提出了这样的担心：敏捷方法对使用传统方式设计可用性会造成威胁。他说敏捷对可用性的最大威胁是，“它是一个由程序员提出的方法，主要关注系统开发的实现方面”。

Alistair Cockburn 说这种说法完全不对：

1. 谁提出观点并不重要，重要的是观点是否够好。
2. 这引起社区中“我们对他们”的分裂，而不是“我们加他们”的合作。
3. 与 Nielsen 提到的其他威胁不同，他并没有提出解决方案，所以把“我们对他们”这个悬而未决的问题留给我们，这是不能接受的。

建议方案: 好的观点拿来用就行了——不要担心它们的出处。像 Kurt Morris在敏捷可用性发贴中说的：“一旦消除了“我们对他们”的敌对心态，你就会见到令人惊羡的成果。”

Nielsen 继续提出这样的问题，敏捷习惯把故事分成更小的任务，这允许以不一致的方式开发功能，有可能掩盖了总的用户体验。他说，最糟糕的是“用户界面最终会看起来像缝缝补补”。Nielsen’s 的解决方案是：

• 快速重复地执行可用性测试。他说“每周测试完全可行，即使在最短的 sprint 开发周期，也肯定能让你整合用户的多轮反馈。”
• 采取并行轨道，让可用性工作比开发工作更早一步完成。
• 采用不需编码的低仿真原型 (比如纸)，把前面花费的时间减少到最小。

Jeff Patton 提炼了 12 个可用性的最佳实践 (与 Nielsen 的相呼应)：

1. 驱动：用户体验从业者是客户或者产品所有者团队的一部分
2. 前期研究，建模，设计——但是只需要够用就行了
3. 分解大块设计工作
4. 采用并行轨道开发，提前工作，后期跟踪
5. 从复杂故事中争取设计时间
6. 培养用户验证小组，以方便持续用户验证使用
7. 在单独轨道中进行用户持续研究，与开发分离
8. 平衡用户多个活动的时间
9. 开发前采用 RITE 方法对用户界面进行迭代
10. 低真原型
11. 把原型当作详细说明
12. 成为设计的协调者

Jeff 描述的 RITE (pdf) 方法来自于微软的游戏工作室：“RITE 与传统的可用性测试不同，它强调极快的变化，并验证这些变化的有效性”。具体来说，一旦发现问题，方案受到影响， 从业者就修改用户界面 (原型或者应用程序)。在另一个参与者到来之前，诸如重命名按钮、修改菜单条目文字这样的变化经常发生。更复杂、但是很明显的变化是 越快越好，这样变化就能被尽快地测到。

除此之外，Jeff 发现他的角色发生了变化：“由于我开始在敏捷团队内工作，我变得喜欢协同设计。我发现自己越来越多地扮演着协调者的角色：从大规模人群中收获信息并对信息建模。我发现自己同一群群的用户和开发者一起工作，撰写用户场景，起草用户接口设计。”

最后， Alistair 说道 (在提到开发者 / 可用性分歧时)：“谨记住，‘只有我们’。”

查看英文原文： Agile Usability