敏捷 + UX = 敏捷 UX

之前我们探讨了敏捷方法在开发过程、产品管理中的种种运用。相信大家在理解了敏捷所传达的价值观和原则后，或多或少对你和现有所在团队的工作模式和方法有些思考和尝试。

而今天我想从另外一个我一直没有提及的角色单独出发，来分析怎么把 UX (用户体验设计) 这个角色很好的融入到敏捷环境中。让我们整个团队不仅只有“敏捷的味道”，而是打造出真正高效自组织团队，构建出色的产品。

传统 Cascade 设计模式

我们知道，敏捷是通过改变开发周期以适应市场需求的变化，避免瀑布开发导致的低质量产品和漫长的开发周期。

这需要打破我们传统部门墙之间形成的”竖井文化”，开发人员更多的参与产品愿景、用户故事的构建，可是 UX 团队除了对于 “ 我们应该将用户需求作为设计过程的中心 “ 这一敏捷中心思想之外，并没有更多的实践参与到敏捷开发过程中。

我看到很多团队在敏捷的实践中，开发可以和产品快速的构建出一支敏捷团队，但是设计团队经常会因为人员配置的问题，同时需要支持多个敏捷团队，内部其实还是单独作为一个部门进行小瀑布式工作模式。

甚至敏捷的实践对于很多设计团队来说是更大的灾难，他们没有充足的时间输出更多的规则说明文档，甚至没有时间详细的进行用户调研工作。

传统的瀑布设计大家最为熟悉的是双钻模式 ，该设计流程模式将设计分为4个阶段：Discover、Define、Develop 和 Deliver。这一设计方法也被称作是Cascade Model ，Cascade 意为 Waterfall。而现如今高强度高要求的设计环境中逐渐不能达到更好的效果。

敏捷 UX 模式

针对以上的问题，其实已经有Lean UX 这个概念的兴起，虽然还处于萌芽阶段，但是它的核心 “ 测试你所拥有的 “ 还是很值得借鉴。今天我想从敏捷 UX模式的角度出发，通过《敏捷宣言》来带 UX 团队理解敏捷的第一步，简述 UX敏捷变革的几个方面。

人和交互，重于过程和工具

UX 人员常常因为其专业性和团队其余成员有一定的距离，他们更多关心的是自己的工作，设计工作对于其他成员来说也是一个黑盒。

敏捷 UX 要求设计人员第一步是保持开放的心态，让其他团队成员为用户体验工作做出贡献，能够改进总体设计，制造出更多的产品。同时还能大大增强团队对于设计的主人翁的态度，承认他们对用户体验做出了贡献。

开发人员也要抽取特定的时间与设计一起解决问题，还可以使用敏捷方法中发展起来的结对编程。让设计人员和一位开发人员搭配工作。这种实时协作能够明显加速设计和实现过程，就像两位编码人员结对能够增加生成代码质量、减少编码时间一样。

并且在每个迭代中增加一到两次设计审核，不断得到反馈进行调整，只画草图与开发并行工作，UX 人员在代码开发的时候实时的与开发团队一起解决设计问题，这样也能减少 UX 团队的负担。

这里需要注意一个问题，在同一个冲刺工作中，UX 人员并不意味着要投入一个或几个完整的冲刺周期进行规划、概要设计或者设计构思或用户调查，也不意味着在迭代周期里不能抽出时间做其他工作，而是要求每个 UX 人员必须估算自己的工作量和跟踪现有开发的速度，可以相互结合，平衡两种方法。

可以工作的软件，重于求全而完善的文档

传统的 UX 团队需要预先完成大型的设计。规格说明往往被认为是设计团队创建的可交付成果。它的范围从描述某个特征的简短说明到描述产品中的交互细节，像一个小说一样长的说明书。

但是在敏捷的环境下，这种笨重的文档需要被抛弃，但是不同于抛弃产品需求文档，设计的规格说明一直以来是设计人员最直接具体的贡献输出，摒弃它可能导致 UX 人员觉得技能的失败。

这需要 UX 人员转变思想。用真正的沟通代替纸面工作绝对需要适应，可以开始试着用轻量级规格说明替换。或者在团队开发之前，先用故事卡片和线框图代替功能规格，不再进行绘制重量级文档交流设计意图，花费更少的精力完整掌握敏捷方法节奏的能力。记住不管你的规格文档是什么形式，它不代表全部，这是一次协作的过程。

轻量级的规格说明也可以是简单的原型，只要说明屏幕交互，这样消除静态图片的解读，同时可以用于可用性测试。

客户协作，重于合同谈判

敏捷 UX 要求设计师改变自己和客户之间的关系，将客户纳入设计团队，在设计的过程中采用灵活的方式将客户的想法及反馈贯穿到设计过程的每一个阶段，使设计团队可以即时进行修改。

相对于传统的设计模式，敏捷 UX 能够发现真正的痛点问题，同时更快地得到客户反馈，也帮助 UX 人员和客户建立更好的沟通。

数据表明，在投放市场后，使用敏捷 UX 模式的项目其成功率要远远高于传统设计模式下的产物。比如：Google 的设计项目就是遵循敏捷 UX 的方法。在国外的设计领域，特别是初创公司，能够运用敏捷 UX 是对设计师的基本要求。

可以利用调查活动，主动采用 RITE、卡片分类、头脑风暴、认知走查 与客户一起解决设计问题，加上可用性测试，就能为用户提供直接影响设计过程、表达需要的机会。参与式设计鼓励用户完全投入当前环境，想象理想的未来，并创建理想的表现形式。

这样的有趣实践能让客户更关注自身体验和需求，且不受对软件的了解或者期望限制。

随时应对变化，重于遵循计划

可以看出，《敏捷宣言》要求敏捷 UX 强调的是高效并且持续不断地进行设计以达到客户满意的标准。这个价值观要求激发个体的设计激情和团队中每个成员的合作与互动，共同达成目标。

而传统的设计模式，团队中每个人的分工不同，前期人员在进行用户调研和市场调研后，分析调研结果并进行总结，然后再进行设计、制作模型、模型测试，分析测试中存在的问题再进行完善，最终制作最终的产品。设计团队首先需要了解客户需求，从而完成一个设计师认为完美的作品。这个设计过程通常长达几个月，并且最终的设计结果可能不是客户想要的。

传统的设计流程是一种 one time active，敏捷 UX 模式则是一种可持续化的设计流程。测试是 UX 设计的另一个开始，只有如此不断地突破、不断地测试、不断地完善，才能够是敏捷ux设计发挥更大的作用，为后期的设计和开发提供更多的支持。敏捷设计强调 “make a real change” 而不是“make a report”，频繁的测试与修改是敏捷 UX 模式的首要原则。

小结

设计师在敏捷的环境下需要重新思考自己的技术和专注点。

从本质上讲，敏捷 UX 描述的是敏捷开发方法论在UX 设计中的上下文情景，是在统一开发和设计师在产品开发中的敏捷过程。通过合作，跨职能的方式来减少对于完整文档的强调，更加关注于对所设计产品的真实体验的共同理解。

希望你能因为我的文章有所收获，把握敏捷的核心，成就你的完美转型。

本文素材来自互联网