“变得与众不同很容易，但是想要变的更好就很难。” — 苹果首席设计官乔纳森·艾弗
在产品需求和开发成果不一致的情况下保持平衡是一项挑战。尤其是当团队缺乏任何指标来衡量他们对发布的影响时。
为你的团队确定正确的产品开发流程往往是一个悖论。在产品需求和开发结果不一致的情况下保持平衡对于大型和中型组织来说都是一项挑战，尤其是当团队缺乏任何指标来衡量其对发布的影响时。
当用户的心智模型与产品功能不匹配时，就会产生摩擦。当开发团队发现自己处于难以为继的状态时，指责游戏就开始了。但正如美剧《广告狂人》中的男主角Don Draper经常说的那样，“向前迈进”。
为了确定正确的用户体验流程，设计人员需要质疑他们对当前流程的假设，并了解其团队正在使用的软件开发生命周期（SDLC）的类型。
每个系统化的且一致的交付流程都必须易于学习、理解和遵循。许多设计师不确定他们应该使用哪种用户体验流程。为了确定正确的用户体验流程，设计人员需要质疑他们对当前流程的假设，并了解其团队正在使用的软件开发生命周期（SDLC）的类型。
设计是一种非常反思的实践，今天的企业需要以用户为中心的服务，专注于为本地受众提供与用户心理模型相匹配的软件。产品开发不是关于实现功能和测试其可用性，而是关于设计具有吸引力并支持人类需求和价值的产品和服务。选择正确的用户体验过程取决于许多因素，包括交付模型、上市时间、用户体验、人才资源、团队管理、技术、灵活性、控制和趋势等。
在为你的团队确定最佳的用户体验流程时，定制该流程以确保其满足你的需求非常重要。但是，你仍然可以从你已经熟悉的东西开始，并适应它。首先你需要提出几个基本问题：
- 需求有多稳定？
- 用户是谁？
- 项目的范围是什么？
- 项目团队在哪里？
- 预算类型是固定的还是可操控的？
用户体验流程的类型
本文将讨论以下几种用户体验流程：
- 瀑布流式用户体验（UX for waterfall）
- 敏捷用户体验（agile UX）
- 精益用户体验（Lean UX）
- 痛点驱动设计（pain-driven design）
- 用户体验跑道（UX runway）
瀑布流式用户体验（Waterfall UX）
用户体验设计师可以遵循以用户为中心的设计方法，但必须遵守商定的范围和时间表。
瀑布流式用户体验是一种规范的、连续的、线性的软件开发方法，在这种方法中，没有迭代设计或开发的灵活性。用户体验设计师可以遵循以用户为中心的设计方法，但必须遵守商定的范围和时间表。通常，由于此方法的连续性流程限制，实验的自由度较低。项目的预算是估算的，通常是预先确定的或有限的，因此瀑布流式用户体验方法在执行过程中可能会遇到很多挑战，尤其是在流程出现偏差时。在研究期间，最好从项目开始就收集所有用户故事，并让必要的利益相关者参与进来。
何时应该使用瀑布流式用户体验？
在以下情况使用瀑布流式用户体验：
- 你正在进行短期固定投标项目。
- 团队具有执行类似项目的良好经验。
- 要求稳定且固定。
- 团队对该技术有丰富的经验。
- 项目范围很广。
- 你对自己需要做的事情有充分的了解。
设计师面临的挑战
瀑布流式用户体验给设计师带来了如下挑战：
- 更长的审核，签收和返工时间
- 详细的可交付成果，然后是文档
- 视觉设计与详细的开发风格指南
- 线框流程详细说明每个交互和样式
- 可用性测试可能对设计没有直接影响
- 在需求收集阶段尽早邀请可用性专家进行参与或协调
- 确保利益相关方接受
时间和价值之间的任何二分法取决于执行计划。由于瀑布式的线性方法，在这种环境中工作的用户体验团队经常受到意想不到的要求和技术限制，这些限制会影响设计解决方案的可行性。客户可能会担心，一旦收到用户体验研究的结果，产品就会改变方向。此外，如果团队在项目开始时花在研究上的时间太少，那么预算往往会在SDLC结束时增加。图1显示了瀑布的设计顺序和开发阶段。
图1 — 用户体验与瀑布模型
图片来源: Wikipedia 瀑布模型
修改后的瀑布模型
修改后的瀑布模型有很多版本。其中一种最流行的变体如图2所示。在这个版本中，团队可以灵活地迭代前面的阶段，并在某些阶段进行更深入的挖掘。这种灵活性可以使团队重新定义一些更具推测性的解决方案。
图2 — 修改后的瀑布模型
敏捷用户体验（Agile UX）
敏捷最适用于需求频繁变化且团队正在进行迭代开发的情况。
近年来，敏捷已成为业界最流行的软件开发方法。最适合需求频繁变化且团队正在进行迭代开发的情况。敏捷专注于开发和时间线。它还体现了解决问题的定期、渐进式的开发方法。
由设计师、研究人员和业务分析师组成的中心团队致力于初始发现阶段，然后将需求交给用户体验设计人员和实施设计解决方案的Scrum团队。敏捷用户体验专注于构建包含以下内容的产品待办事项：
- 产品愿景
- 体验图
- 旅程地图
- 业务和用户体验策略
- 市场调查
- 功能需求文件
- 竞争分析
- 利益相关者地图
- 任何老式系统的可用性测试分析
- 生态系统地图
- 功能列表
- 功能优先级矩阵
- 角色
设计工作至少在一个冲刺 (sprint) 阶段之前就可以展开。在冲刺 (sprint) 计划期间，团队优先考虑功能列表; 然后，Scrum团队选择产品积压代办项目，将它们移动到冲刺 (sprint) 积压代办，并根据团队的速度实施这些项目。用户体验设计师制定计划并促进协作活动，如设立设计工作室以及与Scrum团队进行头脑风暴会议，Scrum团队由Scrum主管、开发人员、产品所有者/经理和技术开发人员组成。
在每个冲刺 (sprint）阶段结束时，Scrum团队在冲刺审核（sprint-review）会议期间演示其结果。这有助于团队评估他们的整体进度与产品路线图的一致性。
何时应该使用敏捷用户体验（Agile UX）?
在以下情况使用敏捷用户体验（Agile UX）：
- 你需要针对固定结果进行测试。
- 你必须根据时间表快速发布产品。
- 你需要能够根据预算、质量和价值，通过多个冲刺 (sprint) 来确定功能的范围，设计范围或优先级。
- 你需要随时根据客户需求采取行动。
- 你必须通过在开发期间与客户协作来确保产品的用户友好性。
- 你的目的是通过快速、持续地提供最低可行体验（MVE）来实现客户满意度。
设计师面临的挑战
敏捷用户体验（Agile UX）为设计人员带来了以下挑战：
- 用户体验设计师和项目团队正确理解他们在敏捷团队中的角色
- 协调整个团队，以传达产品的共同愿景
- 有时，团队如此专注于执行用户故事，而不是从更广泛的角度看待事物。
- 注重发展的方法
- 用户体验设计师在为期两周的冲刺中 (sprint) 有太多事情要做
- 在冲刺准备阶段（sprint 0）开始之前没有做用户体验研究
- 在项目开始时没有对设计师进行适当的培训
- 保持冲刺领先
- 责任太多
项目结果的成功取决于通过在每个冲刺 (sprint) 或关键版本发布时接收来自用户和利益相关者的持续反馈来验证设计。当产品范围很大时，项目中可能会有多个Scrum团队。在这种情况下，核心用户体验团队负责管理整个流程。在整个SDLC的初始发现和评估会话期间，此用户体验团队团队也应参与其中。
敏捷用户体验（Agile UX）流程的可视化
图3显示了敏捷用户体验（Agile UX）流程的工作原理。我已经从Tallan的Krish Mandal的博客文章中修改了敏捷用户体验（Agile UX）流程的这种可视化。图4显示了Jeff Gothelf对敏捷用户体验（Agile UX）流程的另一种可视化。
图3 — 敏捷用户体验（Agile UX）可视化流程
图片来源: Tallan博客的用户体验scrum流程
图4 — 另外一个敏捷用户体验（Agile UX）可视化流程
图片来源: “Jeff Gothelf的文章用户体验设计如何与敏捷及Scrum集成”
在以下情况下，组织还可以考虑使用SAFe（Scaled Agile Framework 规模化敏捷框架）：
- 当一个团队想要在多个项目和组合中复制他们当前敏捷流程的成功时。
- 当需要团队独立工作时，可以跨组织、角色、产品组合和计划扩展敏捷。
- 当团队在当前的敏捷流程中遇到差距、延迟和失败时。
- 当需要改善开发周期时。
精益用户体验（Lean UX）
“如果我们发现自己创建了没人想要的东西呢？那样的话，即使我们按时且按预算完成了又有何用呢?” — 埃里克·莱斯 Eric Ries
精益用户体验（Lean UX）遵循迭代、参与式设计流程，确保设计和开发团队成员的平等参与，并为问题产生许多的想法和可能的解决方案。
精益用户体验（Lean UX）源于精益制造，专注于消除浪费的不必要的功能。它的构建，测量和学习循环允许团队根据用户反馈跨多个冲刺迭代他们的设计，以构建最小可行产品（MVP）。精益用户体验遵循迭代、参与式设计流程，确保设计和开发团队成员的平等参与，并为问题产生许多的想法和可能的解决方案。如图5所示，由于整个团队都参与了整个过程，因此团队能够学习到很多东西，这可以防止孤岛和大师的出现。一套12项原则推动了精益用户体验，它专注于共同创建和快速迭代设计，然后在每个冲刺（sprint）期间验证这些实验。采用精益用户体验存在一些挑战，例如：
-
当没有需求扩散时，共识机制有时会迫使团队成员妥协或导致团队成员误判设计并消除其最具创新性的元素。
-
精益用户体验最适合并置团队，而不是分布式团队。但是，你可以通过确保采用更好的研究和设计协作工具和方法来解决此问题。其中一些工具包括：
-
对于具有多个模块的大型项目，较短的冲刺周期和快速失败方法可能会使团队成员感到沮丧。
图5 — 团队合作是精益用户体验流程中固有的
图片来源:《精益设计：设计团队如何改善用户体验》，作者：杰夫·戈塞尔夫 / 乔什·赛登
何时应该使用精益用户体验（Lean UX）?
虽然在很多情况下你可以使用精益用户体验（Lean UX），但我将以下列表归结为几个关键点，并在这些情况下使用精益用户体验（Lean UX）：
- 当需要以启动速度构建产品时，敏捷性受到重视。
- 当团队需要进行实验时，通过迭代创建MVP，其结果会产生可用性产品。
- 如果团队想要退出可交付成果业务。
- 如果团队希望产生更少的文档。
- 在选择正确的产品成功方法时需要很大的学习曲线。
- 当大多数团队成员并置时。
- 当组织已经遵循敏捷流程时。
设计师面临的挑战
精益用户体验（Lean UX）为设计师带来了以下挑战：
- 在迭代期间持续保持专注
- 并行创建和跟踪多个原型
- 与产品所有者（PO）定义项目边界
- 与产品经理协商发布
- 理解并不断传达产品愿景
- 为受众选择合适的便利和沟通技巧，特别是当团队没有并置时
- 通过修改适用于团队的流程来构建自定义框架
- 让一些团队成员分布在不同地区
图6显示了精益用户体验（Lean UX）如何与迭代设计冲刺协同工作。
图6 — 精益用户体验流程
图片来源：《精益设计：设计团队如何改善用户体验》，作者：杰夫·戈塞尔夫 / 乔什·赛登
痛点驱动设计（pain-driven design）
痛点驱动设计（PDD）就是在开始解决设计问题之前弄清楚导致疼痛的原因，即预测痛点，然后对它做出反应。PDD使组织能够在发现阶段获取知识，并让初创公司能够安全地失败。大多数成功、成熟的组织已经直接或间接地遵循这种方法，而不知道这就是一个痛苦驱动的设计过程。以工程为主导的组织从客户那里获得反馈，然后实施客户的要求。通常，利益相关者会因客户的要求或销售团队对市场的反馈而产生偏见。
PDD 的指令包括以下内容：
- 早期验证
- 寻求生态系统内的外部合作
- 持续学习
- 灾难预测
- 痛点驱动的设计和开发
PDD遵循精益创业（Lean Startup）的方法，尽早验证产品以确保其成功。PDD和精益用户体验（Lean UX）都建议构建一个假设并与用户进行验证。但是，它们之间的关键区别在于验证发生的时间点。精益用户体验（Lean UX）在冲刺 (sprint) 周期中通过实验测试他们的假设。正如Laura Klein在她的著作《精益创业UX篇 — 高效用户体验设计》中所建议的那样，PDD专注于预发现。使用PDD的团队有很多成功的例子，但最有趣的案例是缓冲区（buffer）和Dropbox。
缓冲区（buffer）的创始人Joel Gascoigne通过启动三个屏幕验证了他的产品理念（如图7所示），以了解是否有人有兴趣为这个想法付费。他最初承诺一周，并最终在七周内推出了该产品。你可以从Joel Gascoigne的博客了解更多信息。
图7 - 缓冲区的早期验证过程
图片来源: buffer
PDD的推荐方法是关注与用户功能作业相关的问题，而不是特性和功能。正如哈佛商学院教授Theodore Levitt所说：“人们不想购买四分之一英寸的钻头。他们想要一个四分之一英寸的洞。”
将PDD集成到你的开发过程中，通过将痛点驱动的决策制定的复杂性分解为行动，你可以清楚地表达可预测问题与不可预测的痛点之间的差异。快速周转和构建假设的操作包括以下内容：
- 理解
- 咨询
- 回应
- 预测
- 感知
- 实验
- 法案
- 分类
- 分析
- 学习
- 调查
- 设计
你将得出一个类似于精益用户体验（Lean UX）的流程，可以根据你的决策灵活地修改你的操作。根据我的经验，我试图将此方法描述为图8所示的过程。结果是一个专门的团队，其重点是解决组织客户的痛点。该团队由来自产品组合中各个部门的冠军组成，包括用户体验、技术、销售、营销、财务和管理。首席体验官（CXO）领导这个团队。
图8 - 改进的痛点驱动设计模型
图片来源: Deepak Arasu
另外，请考虑图9中所示的Cynefin框架 。
图9 - Cynefin框架
图片来源：《哈佛商业评论》中的 《A Leader’s Framework for Decision Making》学术文章，作者David J. Snowden / Mary E. Boone
用户体验跑道（UX runway）
用户体验跑道（UX runway）的想法最初来自规模化敏捷框架 Scaled Agile Framework (SAFe)。许多人抱怨敏捷只适用于小规模项目，而且扩展效果不好。SAFe可以为这个问题提供解决方案，因为它采用精益（Lean）和敏捷（Agile）原则，将它们结合起来，有效地用于涉及多个Scrum团队的大型项目。SAFe流程允许你跨团队扩展工作，并利用计划和组合级别的流程。
用户体验跑道（UX runway）最适合SAFe，专注于在团队和计划层面保持用户体验的精益和敏捷。它的重点是实时设计（just-in-time design），生产刚好足以满足开发的开始。用户体验团队本身是一个具有不同级别的的敏捷团队，包括用户体验经理、用户体验产品所有者、研究人员、战略家和多个交互设计师。作为一个敏捷团队的一员，设计师与多个SAFe开发团队合作。设计人员在开发前通过两到三个冲刺（sprint）工作，并将其10％的能力用于设计变更和集成支持。设计师们还并行处理某些研究峰值。
用户体验团队开发用户体验积压和范围并计划他们的工作，如图10所示。Natalie Warnert发布并推广了用户体验跑道（UX runway）方法，并在她的网站上详细介绍了该流程。
图10 - Natalie Warnert的用户体验跑道（UX runway）流程
图片来源: Natalie Warnert
简而言之：用户体验跑道（UX runway）= 敏捷用户体验（Agile UX） + 规模化敏捷框架（SAFe） + 昂贵的精益用户体验（Lean UX）方法。
总结
显然，痛点驱动设计（PDD）有着美好的未来。这个过程非常简单，随着机器学习和人工智能代理的出现，你可以在一定程度上实现自动化，并以最低的总成本解决风险最高的问题。
虽然精益用户体验（Lean UX）是一种很出色的方法，但大多数组织倾向于使用精益用户体验（Lean UX）和敏捷用户体验（Agile UX）的组合。敏捷用户体验（Agile UX）和精益用户体验（Lean UX）提供的灵活性使团队能够根据需要修改其流程。
为你自己的团队选择正确流程的第一步，首先要探索你的选择，并向利益相关者和决策者介绍这些选择。最终，你可以将流程制度化，测试方法，取得小成功，然后修改和扩展你的方法。
通过采取阻力最小的路线，我们最终关注大多数人想要的东西。作为用户体验设计师，重要的是要打破孤岛，促进团队选择正确的方向并做出正确的决策。什么是最好的方法？创建你自己的方法！
（编译完）
英文原文：地址
原文作者：Deepak Arasu
原文译者：Twitter / Linkedin / 微博
以上译文仅代表原作者观点。如需转载请遵循CC版权协议正确标明出处。
image
网友评论