精益用户体验：如果我们发现自己在建造一些没人想要的东西怎么办？在这种情况下，我们是否按时、按预算完成又有什么关系呢？

如果我们发现自己在建造一些没人想要的东西怎么办？在这种情况下，我们是否按时、按预算完成又有什么关系呢？ ——Eric Ries（埃里克·里斯）

精益用户体验

精益用户体验 （Lean UX） 是一种基于团队的方法，通过减少对理论上理想的设计的关注，更多地关注迭代学习、整体用户体验和客户成果来构建更好的产品。

精益用户体验设计扩展了传统的用户体验角色，而不仅仅是执行设计元素和预测用户如何与系统交互。相反，它鼓励更全面地了解功能存在的原因、实现它所需的功能以及它带来的好处。通过获得即时反馈以了解系统是否能够满足基本业务目标，精益用户体验提供了一种定义和衡量价值的闭环方法。

详情

通常，用户体验（UX）代表用户对系统的感知——易用性、实用性和用户界面 （UI） 的有效性。用户体验设计侧重于构建对最终用户有深刻理解的系统。它考虑了用户的需求和愿望，同时考虑到了他们的背景和局限性。

当使用敏捷方法时，一个常见的问题是如何最好地将用户体验设计融入快速迭代周期，从而实现新功能的全栈实现。当团队试图解决复杂且看似主观的用户交互问题，同时尝试开发增量可交付成果时，他们通常会在许多设计中翻转，从而对敏捷产生挫败感。

幸运的是，精益用户体验运动通用敏捷开发和精益创业实施方法解决了这个问题。SAFe 的思维方式、原则和实践反映了这种想法。这个过程通常从Epic文章中描述的SAFe精益创业周期开始。它使用这里描述的精益用户体验流程继续开发特性和功能。

因此，敏捷团队和敏捷发布序列 （ART） 可以利用通用策略来生成快速开发、快速反馈和让用户满意的整体用户体验。

精益用户体验流程

在《精益用户体验》中，Gothelf 和 Seiden 描述了一个我们适应 SAFe 的模型，如图 1 所示。

效益假设

精益用户体验方法从一个收益假设开始：敏捷团队和用户体验设计师接受正确的答案是预先不可知的。相反，团队应用敏捷方法来避免大设计先行 （BDUF），专注于创建有关功能预期业务结果的假设。然后，他们逐步实施和测试该假设。

SAFe 特性和效益矩阵 （FAB） 可用于描述在CDP的持续勘探方面进行的假设：

功能 – 给出名称和上下文的简短短语

效益假设 – 对最终用户或企业提出的可衡量效益

注：设计思维实践建议更改功能收益假设元素的顺序，以首先确定客户收益，然后确定哪些功能可以满足他们的需求。

结果在 CDP 的按需发布方面进行衡量。它们最好使用领先指标（参见 [1] 中的创新会计）来评估新功能满足其收益假设的程度。例如，“我们相信管理员可以在以前花费一半的时间内添加新用户。

协同设计

传统上，用户体验设计一直是一个高度专业化的领域。具有设计天赋、用户交互体验和专业培训的人通常完全负责设计过程。目标是在实施之前完成“完美像素”的早期设计。但这项工作通常是由专家在孤岛中完成的，他们可能最了解也可能不了解系统及其背景。成功的衡量标准是实现的用户界面与初始用户体验设计的一致性。在精益用户体验中，这种情况发生了巨大变化：

精益用户体验没有时间给英雄。设计作为一种假设的整个概念会立即取代英雄主义的概念；作为一名设计师，你必须预料到你的许多想法在测试中会失败。英雄不承认失败。但精益用户体验设计师将其视为流程的一部分。

持续探索采用假设并促进持续的协作过程，该过程征求不同利益相关者群体（架构师、客户、业务所有者、产品负责人和敏捷团队）的意见。该小组进一步完善了问题，并创建了清晰表达新兴理解的工件，包括角色、同理心地图和客户体验图（参见设计思维）。

敏捷团队有能力设计和实现协同用户体验，显著提高业务成果和上市时间。此外，另一个重要目标是在各种系统元素或渠道（例如，移动、Web、信息亭）甚至来自同一家公司的不同产品中提供一致的用户体验。要实现这种一致性，需要平衡分散控制与集中某些可重用的设计资产（遵循原则 #9 – 分散决策）。例如，创建一个设计系统 [2]，其中包含一组标准，其中包含 ART 和价值流认为有用的任何 UI 元素，包括：

编辑规则、风格指南、语音和语气指南、命名约定、标准术语和缩写

品牌和企业标识套件、调色板、版权、徽标、商标和其他归属的使用指南

UI 资源库，包括图标和其他图像、模板、标准布局和网格

UI 小部件，包括按钮和其他类似元素的设计

这些集中式资产是架构跑道不可或缺的一部分，它支持分散式控制，同时认识到某些设计元素必须集中化。毕竟，这些决策是罕见的、持久的，并且在用户群和企业应用程序之间提供了显着的规模经济，如原则 #9 中所述。

构建最低限度的可销售功能

通过假设和设计，团队可以将该功能实现为最小可销售功能 （MMF）。MMF 应该是必须提供的最小功能量，以便客户识别任何价值，并让团队了解收益假设是否有效。

通过创建 MMF，ART 应用了 SAFe 原则 #4 – 通过快速、集成的学习周期进行增量构建，以实现和评估功能。团队在定义初始 MMF 时，可以使用基于集合的设计保留选项。

在许多情况下，极轻量级甚至不具备功能性的设计可以帮助验证用户需求（例如，纸质原型、低保真模型、模拟、API 存根）。在其他情况下，可能需要仅包含 MMF 一部分的垂直线程（全栈）来测试架构并在系统演示中获得快速反馈。但是，在某些情况下，该功能可能需要继续部署和发布，其中应用程序检测和遥测提供来自生产用户的反馈数据。

评价

MMF 作为部署和发布的一部分进行评估（如有必要）。有多种方法可以确定该功能是否提供了正确的结果。这些包括：

观察 – 在可能的情况下，直接观察系统的实际使用情况。这是了解用户上下文和行为的机会。

用户调查 – 当无法直接观察时，简单的最终用户问卷可以获得快速反馈。

使用情况分析 – 精益敏捷团队将分析构建到他们的应用程序中，这有助于验证初始使用情况，并提供支持持续交付模型所需的应用程序遥测数据。应用程序遥测提供来自已部署系统的持续操作和用户反馈。

A/B 测试 – 这是一种比较两个样本的统计假设形式，它承认用户偏好是事先不可知的。认识到这一点是一种解放，消除了设计师和开发人员之间无休止的争论——他们可能不会使用该系统。团队遵循原则 #3 – 假设可变性;保留选项以尽可能长时间地保持设计选项的开放性。只要在可行且经济上可行的地方，他们就应该为关键的用户活动实施多种替代方案。然后，他们可以使用模型、原型甚至全栈实现来测试这些其他选项。在后一种情况下，不同的版本可能会部署到多个用户子集，可能会随着时间的推移进行排序并通过分析进行测量。

简而言之，可衡量的结果提供了团队重构、调整、重新设计所需的知识，甚至仅根据客观数据和用户反馈来放弃功能。测量创建了一个闭环精益用户体验过程，该过程由功能是否满足假设的证据驱动，朝着成功的结果迭代。

在 SAFe 中实施精益用户体验

精益用户体验不同于传统的集中式用户体验设计方法。主要区别在于如何通过实现代码、检测（如果适用）以及在暂存或生产环境中获取用户反馈来评估假设驱动的方面。实施新设计主要由敏捷团队负责，与精益用户体验专家合作。

当然，这种转变，就像许多其他精益敏捷开发一样，可能会对团队和职能的组织方式造成重大变化，从而实现持续的价值流动。有关协调和实施精益用户体验（特别是如何在 PI 周期中集成精益用户体验）的更多信息，请阅读高级主题文章《精益用户体验和 PI 生命周期》。