在实践中的可用性
敏捷 Ux 开发
Dr. Charles B. Kreitzberg and Ambrose Little
内容
灵活的值
总结
Dr.Watson Charles B Kreitzberg
容纳下到开发过程的用户体验活动是 persnickety 问题但我们需要解决一。 敏捷开发正成为日益主流和充分的理由。 很可能构造要求的准确性和详尽列表，然后将其转换为真正有用、 可用，和需要产品。 用户没有真正了解他们所需直到他们使用产品，因此产品需要经过多个迭代之前它实现高级别的实用工具和波兰语。
但用户体验和敏捷开发过程之间匹配是有问题。 很有些意外因为 Ux 设计器和敏捷软件设计两个的思想用户强调迭代的优化和学习。 但也真正的问题原因如变得更广泛采用敏捷方法，用户的质量风险也遇到增加。 Jakob Nielsen 建议问题有在事实的灵活的其根 conceived 的由程序员的改进开发过程。 他已经说过的灵活"主要地址的系统开发实现一侧。 结果它通常 overlooks 处于的编码的副作用发生的交互设计和可用性"。
Ambrose Little
若要创建好的产品，敏捷方法需要合并 synergistic 与软件工程的方式中的用户体验设计。 实现这需要开发人员和 Ux 设计器 rethink 几个假设。 我们要重新检查我们假设的一个方面是设计规划。
Scott Ambler 建议，之间其他的冲突 Agile 社区拒绝早期阶段建模或预先大设计 (BDUF) 冲突与结构开始之前，向用户交互 nail Ux 社区的需求。
灵活的值
我们会通过执行它，并帮助其他人做 uncovering 开发的软件的更好方法。 根据在 Agile Manifesto 我们已有值：
- 个人和交互流程和工具
- 通过全面的文档的工作软件
- 通过合同协商客户协作
- 响应将通过执行计划
面对的它，这看起来像一个大问题。 灵活的开发人员"学习通过构建"，这会使其大预先设计的值的怀疑。 但在多基本方式灵活和 Ux 共享常见基本原理。 生成 UI 原型，并与用户对其进行测试的 Ux 设计过程与类似灵活的迭代。 Ux 设计基于本质上次迭代测试和学习从用户的反应。 四个灵活值在灵活的 Manifesto 中 2 提供的前面，演示同样适合用于 Ux 的基本原理。
最近我们对话有关我们的视图与灵活性和可用性。 我们邀请您要在侦听。 Ambrose，开发人员 / 架构师要求大部分问题。
Ambrose： 为什么不能 Ux 朋友们就设计与灵活的团队的？
Charlie： 我认为他们。 用户中心设计 (UCD) 为传统 practiced 有而重型样式。 您构建竞争的设计，然后研究在的用户的第一次测试这些 empirically，调整它们，继续测试这些，并最后将其发布为编程规范。 持续产生高质量的结果，如果您有足够的时间和资金的相当好进程。 但如瀑布式开发通常不适当在实际情况下。
使关键问题，如何管理短迭代周期中对它进行开发时维护 UI 的整体和一致视图？ 答案是您需要分隔所必需具有预先与可以被推迟到更高版本的迭代的元素。
可用性测试的功能之一是用于向 Ux 设计者提供有关如何用户响应为 UI behaviorally 信息。 这并不非常不同的学习的灵活搜寻部署的迭代结果和收集有关用户反应，给它的数据时。 事实上，评估对发布的用户反应是可能比传统的可用性测试的最小使用 UI 的模型的更为强大，可能是否功能。 用户界面模型只允许您测试最初的反应。 他们不要告诉您用户如何使用一周或一个月发布后的该工具。 它们还不大可能在 multi-touch 情况下，将测试高度动态 UI 时。 在这些方面，Agile 有优势。
Ambrose： 但不 Ux 您要创建预先设计的一个基本假设呢？ 和灵活 abhors BDUF。 您可以协调的？
Charlie： Agile 像极限编程 (XP)，多根式形式未做了大量的预先设计的使用。 实际，我认为那是有趣若要查看如何小的初始设计确实需要创建高质量 ux. 我认为非常好的设计人员可能在该环境中有效。 但不必是非常因此根式。 在没有预先不足，无法设计风险是将无法创建用户的整体体验或您会被强制 rethink UI 设计之后您已经, 发布了早期的迭代，用户必须花费时间学习如何使用产品。
我会建议是，我们限制预先设计，以用于创建了整体体验的基本元素中，并重复执行剩余的设计。 您需要一个框架，使开发人员和设计人员产品的发展维护用户界面一致性，而您需要在 UI 以展开以正常和预期的方式，以适应演变。 不能不断地重组每个版本 UI 或将使您的观众并创建可用性问题。 还需要保持与业务任务和用户特征的 UI 的连接。
因此您希望是最小设计预先所传达正确的元素。 如果您的首字母缩写词风扇，将它视为 BDUF (大设计预先) 替换 ENUF （元素需要最顶层） 并执行仅 ENUF 转到项目的设计。
Larry Constantine 引用必需最少的预先设计的三个特征：
- 适合使用用户任务的结构的用户界面的所有部分的整个组织。
- 用于所有部件之间的导航一个通用的常见方案。
- 一个视觉和交互方案提供了一致的外观以支持用户任务。
回想一下是更喜欢通过全面的文档工作软件"Agile 的第二个值 ； 早期 Ux 原型提供学习支持通过生成相同的功能。
Ambrose： 提到"产品概念设计" 您意味着通过的什么？
Charlie： 通过概念设计我表示定义设计空间的高级设计元素并提供详细设计的基本框架。 概念设计开头 Larry Constantine 概述的三个特征。 我正在设计一个产品时, 我创建一个用户界面 mockup 我称之为"键的屏幕原型，"是一组定义该产品的 wireframes。 键的屏幕原型显示如何在用户将定位到关键功能和访问群体外观的功能。 它定义基本的信息体系结构和显示信息的规则。 我通常包含可视化的设计，这样键的屏幕原型传达多个用户体验比将能使用示意性 wireframes 开发样式指南以记录在屏幕布局、 信息体系结构和可视化设计约定，因此开发人员都可以引用可用。
键的屏幕原型和样式参考线这两种轻量，轻松地改进为引入新想法。
如果我，我启动概念设计和密钥的屏幕原型业务案例分析阶段项目的利益相关者决定是否应提供资金项目能更好地理解内容将被建议。 我使用密钥的屏幕原型显示给预期的用户，并获得其反馈。 我也做一些可用性，测试其 weed 出任何主要设计缺陷。
项目获得批准键的屏幕原型时非常有用的输入帮助快速了解项目的开发。
初始设计没有在石中进行设置。 有可能 rethink 它在迭代的进度。 但不能轻松重构代码 Refactor UI。 更改用户界面时要更改与此的程序交互的方式，并且您需要考虑所做的更改会的影响。 轻松地创建混淆，烦恼，并哪些 psychologists 调用主动干扰 （以前体验使得难了解一种新方法执行操作的用户的 UI 的）。 所有在所有使用户界面将更改以便其支付正确概念设计在开头通常 unadvisable 发布后。
Ambrose： 因此，如何您执行到灵活的迭代中会集成 Ux？
Charlie： 尽可能中启动概念设计为早期的并使其像可以非常精确。 进行可用性测试您的键的屏幕原型上了解尽可能从用户和优化设计。 开发启动使您可以为开发团队提供以便验证的用户模型之前，尽可能执行尽可能 Ux 工作。
一旦开发开始，则继续 Ux 开发，但与开发活动不冲突的方式工作。 在增长普及中的一种方法是创建并行 Ux 和开发跟踪并进行项目以便 Ux 设计保持一个迭代之前，编程人员。 您可以看到在 图 1 中的此流。
图 1 集成 Agile 与 Ux
在每次迭代进入，开发人员有以便在用户界面模型。 为迭代 j 编码处于正在时, Ux 设计器正在处理的迭代 j UI + 1。 在释放迭代 j 时 Ux 团队将可用性测试以确定任何可用性设计问题和该信息返回给开发人员。
在实践中需要有关如何实现这种流灵活。 Ux 设计器应使用密切开发人员，以便它们可以帮助使用详细的设计。 为新的功能预想，在 Ux 团队可能会开发和测试能够从 UI 的模型。 Ux 团队还将解决晚在开发过程中出现的问题。 目标是始终使软件工程团队能够避免支出和返工的受挫。
Ambrose： 您不具有 Ux 专业技术开发团队时工作此流可以？ 有关瀑布式方法很好的事情之一就是您可以雇用 Ux 顾问预先哪些用户可以传递，然后进行正常的退出。 使用灵活似乎，需要有 Ux 专业知识，整个项目。
Charlie： 这是 True。 当然，许多瀑布式项目都具有可用性问题精确地因为设计器不是围绕产生实际 UI，但没有问题瀑布式环境中会更易于使用哪些用户可以传递和消失顾问。
一个灵活的设置中我想要看到 intitial 设计导致的有经验和 competent Ux 设计器的但在位置概念设计后，您通常可以使用缺乏经验的设计器创建单个的屏幕。 但如果您可以收到人专用于 Ux 问题，这是更好，则开发人员愿意 champion Ux 的原因可以做到这。 工作，因为通常所做的决定有本地而不是全局的结果，并且本地的设计始终是比全局设计更加容易。 如果您使用像 Quince 模式库将简化了大量设计决策。
Ambrose： 确定。 consternation 我发现另一个源是 Ux 的人不了解难的事情是实现有时。 我发现有些开发人员响应冲突通过只说"我们不能操作的"时合理的安全可能。 我们如何可以管理这种情况下以便我们协同工作而不是对彼此？
Charlie： 该技巧就是首先避免冲突。 我的经验有冲突的通常出现的三个源：
第一个是开发人员通常是 overworked，并且没有足够的时间执行该作业，他们希望的方式。 这是一个比 Ux 问题的更多管理。 但通过启动 Ux 设计 upfront 您降低在压力的一些由于开发团队将具有一个模型以从启动。
Ux 设计人员和开发人员步骤彼此 toes 上时，冲突的第二个排序都发生。 保持在 Ux 迭代提前有助于绕过此。 和为团队获取更多的经验过程，您可以管理此更好。
冲突的第三个源是多文化的。 它时发生开发人员不遵守重要性 Ux 或 Ux 设计器无法了解什么是开发人员很重要时。 更好地了解实现的工作是一个很好的目标。 但可以在更是直接设置共享的责任情况的开发人员和 Ux 中设计器成功，或一起失败。 一天末尾很重要的产品质量。
我见过的每个研究和每个高级 Ux 管理器我所说的是清除的集成到项目的 Ux 节省时间和资金。 但实际上是 Ux 设计始终使事情更容易如果不是，您要做一些错误。
因此从进程的角度，关键的步骤是：
- 设计您敏捷过程显式包含 Ux 作为关键组件，并将一个所有者或 champion 分配给它。
- 执行基本概念设计预先，以便随着产品发展，可确保 UI 的完整性。
- 使用轻型 UI 过程，并保持领先于编码，以便开发人员都不慢向下。
是一样的简单 ！ 视为开发过程的一个重要维度的 Ux，并确保在访问获取粗略 Ux 语音听说过。 获取团队 champion Ux，更好地还，雇用 Ux Professional 和让他们只是 ENUF 设计执行作为业务分析的一部分和作为迭代 0 的一部分 （因此必须进入迭代实心概念设计的人。 如果您执行在完全工作并从事保持领先于开发设计，以便能够从主要设计 kinks 工作之前编码，则将提高用户体验，同时保持灵活性的优点。
并如果您使用一个瀑布式过程您可以集成 Ux 设计实践它通过下列内容类似的原则。
将您的问题和发送注释 Charlie 和 Ambrose 到 magux@Microsoft.com.
Dr.Watson Charles Kreitzberg 是 CEO Cognetics Corporation ( www.cognetics.com )，它提供了可用性咨询和用户体验设计服务。 他的热情创建使用和 delight 同时支持产品的业务目标的用户的直观界面。 Charles 居住在中心新新泽西州他 moonlights 为执行的音乐家。
Ambrose Little 居住与妻子和中心新建新泽西州中的四个子项。 他的被设计和开发软件 10 年以上，honored 是一个 INETA 发言人和 Microsoft MVP。 大，他的从技术的设计移动到用户的设计，现在用户体验的 Infragistics 设计器。