敏捷用户体验：如何将用户体验和产品设计融入敏捷

DevOps 通常被定义为围绕公司软件和系统开发的流程、操作、方法、工具和文化。

但是工程并不是在真空中运作的。 蓝图、想法、设计和概念来自决定布局、流程和交互性的产品设计专家。 这些是共享 DevOps 目标和期望结果的非工程个人和团队。

DevOps 不仅仅是开发人员如何与 IT 连接、如何管理基础设施以及如何改进框架。 这是关于认识到有多少团队真正参与了软件开发过程，他们的角色和工作是如何交织在一起的，并找到更好的方法来确保每个人都参与进来。

当产品和创意团队设计软件或系统时，开发人员和工程架构师希望参与其中。 但在当前 DevOps 的定义中，这在哪里？ 产品、用户体验和创意团队希望在工程过程中保持参与，但许多方法将它们排除在外。 这些是我们需要打破的旧筒仓。

您的客户只会看到您的用户体验 (UX)。 他们看不到你有多少开发人员，或者你是敏捷还是精益。 他们不知道正在使用哪些 DevOps 工具。 贵公司的用户体验就是产品，它可以成就或毁掉你。 他们想知道是谁建造了这块垃圾。 在如此激烈的竞争和人们乐于卸载应用程序或离开网站的情况下，您会与抛弃您的客户再次获得机会吗？

敏捷很少培训用户体验或与用户体验专家合作

许多工程团队经常发现用户体验是孤立的并且难以协作。 UX 似乎并不精益，许多敏捷风格都排​​除了如何使用 UX 的细节。 一些敏捷方法特别建议描述功能的产品所有者“足够好”。

SAFe Agile 错误地认为解决 UX 孤岛的最佳方法是完全排除它们。 SAFe“授权敏捷团队”做他们自己的“精益用户体验”。 随着越来越多的公司了解整合 UX 专家和完整 UX 流程的价值，SAFe 正朝着错误的方向前进。

敏捷培训和书籍中缺乏解释 UX 及其流程的情况导致世界各地的团队排除或尽量减少专业产品设计师的参与。

• 当您错误地认为 UX 只是在页面上绘制框时，很容易假设“我可以完成这项工作”。 就像许多美国偶像的试镜者确信他们是这个星球上最好的歌手一样，大多数产品经理和工程师都自认为在 UX 方面表现出色。 这通常意味着他们相信自己擅长布置屏幕。 但是，当本文解释了真正进入 UX 工作的内容时，您将看到 UX 专家不会将制作线框图的开发人员视为应该被赋予 UX 任务的人。
• Scrum 上的书籍建议，如果 UX 专家成为瓶颈，她应该培训非 UX 角色来完成她的工作。 这种类型的决策很少被建议用于软件开发中的其他角色。 没有人会希望未经培训或缺乏经验的开发人员进行编码，即使在训练营或阅读有关编程的书籍之后也是如此。 我们绝不会建议如果开发人员成为瓶颈，她应该培训项目经理进行一些编码。
• 错误地认为 UX 是一项艺术 (UI) 工作的招聘经理会聘请艺术家来从事 UX 工作。 UX 学位和 UI 学位之间没有教育重叠。 天赋往往不会重叠； 擅长 UX 的人可能是一个糟糕的艺术家，反之亦然。 为“UX/UI”招聘通常会为您提供一位出色的艺术家，而他的 UX 经验、专业知识、流程或教育程度最低。

那些只关注底线的人会喜欢通过将 UX 任务分配给可能缺乏 UX 教育、经验、专业知识、技能或天赋的个人来削减预算。 但这是短视的，可能导致生产力、效率、文化、产品和客户满意度低下。

将专家 UX 专家纳入敏捷的重要性

2018 年底，管理咨询公司麦肯锡公司发布了“设计的商业价值”，这是一份他们对 300 多家公司进行的研究的报告。

他们发现，“设计是公司脱颖而出的唯一途径。” 当竞争对手拥有接近的功能集时，是什么让他们脱颖而出？ 设计有时被认为只是美学或使它看起来像我们品牌的原因。 但是当与“UX”一起使用时，设计意味着功能的架构以及关于屏幕、步骤、流程、布局、流程、组织和菜单的决策。

UX 是持续改进过程的一部分，始终寻求更好地了解用户，选择和设计最符合他们需求的功能和产品，解决他们的痛点，并为他们带来有意义的创新。

麦肯锡还报告说，“公司必须在整个过程的早期就全面接受设计，而不是将其视为以后适应的小工具。” 假设对用户体验的关注是可以在发布产品后最小化、排除或完成的事情的团队采取了错误的方法。

麦肯锡收集了定量数据，发现采用 UX 设计的公司在 5 年内创造了 32% 的收入和 56% 的股东回报。 宣布您的公司“以用户为中心”是不够的。 您必须通过集成 UX 从业者和流程，从规划和产品组合向下到开发和 QA 来走这条路。

有和没有 UX 的软件开发过程

如果您的公司在软件设计和开发过程中不包括 UX 专家，那么您的过程很可能如下图所示。

客户、产品经理、首席执行官或有远见的人会告诉工程师他们想要什么。 工程构建它，测试它，并在登台或生产服务器上获取它。 有远见的人看到它，你不知道，他们不快乐。 他们想要不同的东西或改变了主意。

然后，工程必须循环回到起点，找出这个人现在想要什么，构建、测试并交叉手指，这就是魅力。

如果您的团队中有 UX 专家，那么这个过程就完全不同了。 有远见的人带着想法、数据和客户痛点来到 UX。 UX 在其以用户为中心的设计过程中循环执行任务，然后在工程编写一行代码之前测试这些概念。 这可以确保我们正在考虑构建的产品或功能是为我们的目标客户正确执行正确的想法。

测试可能会暴露一些缺陷，这使得 UX 可以迭代并经常再次测试。 在完成 UX 流程后，您就可以将经过全面审查的设计交付给工程部门。

如果有人在此过程中改变了主意，则该人会与 UX 交谈，而不是将其作为对开发人员的更改请求。 UX 在他们的过程中会产生干扰，如果没有 UX 参与设计、决策和对真实或原型客户的测试，则不会将任何内容发送到工程部门。

在这一点上改变主意并不是灾难，因为在这一点上改变主意的成本是微乎其微的。 工程还没有交付蓝图，他们还没有开始，也没有什么可重建的。 UX 会迭代他们的设计，并且可以进行用户测试，以确保这些想法与客户群良好、紧密地匹配。 改变主意会消耗时间，但对预算的总体影响很小。

用户体验有一个正式的过程

以用户为中心的设计 (UCD) 是一个形式化的过程，包括指导 UX 专家研究、设计、原型、测试真实或原型用户的任务，然后根据测试中的学习进行迭代。

专注于其中一些领域，我们从需求和关于功能和项目的早期讨论开始。 当 UX 首次获得需求和其他项目信息时，立即开始协作非常重要。 UX 以后不应该发现他们设计了无法构建的东西。

当产品或项目经理决定功能和优先级时，首先引入 UX 员工或经理。 可以删除对用户没有价值的项目，从而节省大量时间和金钱。 这就是最大化未完成的工作量发挥作用的地方。 当产品和工程通过减少或删除功能或整个项目来减少工程的工作量时，他们应该支持 UX。 然而，很多时候，项目都有自负，团队成员经常将用户体验排除在这些早期对话之外，以便项目获得资金。

研究是用户体验工作的重要组成部分。 它不是以用户为中心而不涉及用户。 统计和定量数据很棒，但无法替代采访用户、深入了解他们并获得定性数据。 UX 想知道为什么而不仅仅是什么。

用户体验研究还通过将每个人围绕角色、目标客户的原型统一起来，让团队成员达成共识。 根据对用户的采访，我们汇总了我们学到的知识，并将每个人归结为 6 个或更少的角色。 是什么激励了他们？ 他们需要什么？ 我们公司、产品或服务的机会在哪里？

人物角色的最佳用途是将它们包括在任何地方。 产品基于角色（和良好的数据）想象功能。 基于角色的用户体验设计。 QA 测试同时想象他们是这些角色。 营销可以添加他们的人口统计和其他细节，但他们也应该考虑品牌声音、社交媒体和广告如何与角色对话。

人物角色帮助非 UX 工作人员摆脱“嗯，我喜欢这种方式”或“CEO 喜欢这种方式”。 我们正在为这些目标客户进行设计，如果您或 CEO 不适合这些角色，那么 UX 不会受到自我或个人偏好的影响。 UX 必须以客户为中心。

信息架构与层次结构、结构和分类法有关。 这可能是网站导航，也可能是产品在电子商务数据库中的分类方式。 我们希望确保客户能够通过类别、元数据和过滤器轻松找到产品。

交互设计，有时也称为体验设计，是大多数人在想象 UX 时想到的。 这些是线框和原型，是设计和概念的蓝图。 这些将显示流程、布局、菜单、交互、路径、选择等等。

UX 原型就像被赋予生命的线框。 它们是可点击的交互式数字模型。 我们不必编写代码； 我们有软件可以帮助我们快速创建这些。 寻找更逼真原型的公司使用 Axure，因为它具有条件逻辑、变量、移动滑动手势、拖放和各种事件触发器。 您可以为几乎任何类型的设备制作原型。

UX原型设计用于：

• 头脑风暴
• 合作
• 迭代
• 探索解决方案
• 向投资者推销（针对初创公司）
• 测试原型以查看解决方案是否与目标受众良好连接。
• 向开发人员或其他队友提供交互式模型，这通常比文档页面更受欢迎（并且没有可点击的模型）。

现在它进入用户测试，也称为可用性测试，它发生在 UX 过程中和工程编写一行代码之前。 您必须测试概念和设计，以确保想法和执行对目标客户来说非常棒。

用户测试将揭示任何缺陷，让 UX 有机会迭代想法，这在这一点上并不昂贵，因为没有任何东西可供工程构建或重建。

UX 在交付给工程部门之前运行测试有 5 个关键原因：

1. 最好地利用工程的时间和资源。 如果您希望测试参与者看到工程师创建的成品，您必须构建并测试它的错误。 如果用户体验测试带来了所需的更改，开发人员将不得不重新构建，QA 将不得不重新测试。 如果 UX 测试显示该概念的更大失败，这可能意味着工程的时间完全被浪费了，因为这不是最终会在任何地方结束的代码。 这个概念必须重新思考、重新设计和重新测试。
2. 在幕后迭代。 当公司只是构建它、交付它、对其进行迭代、构建并再次交付时，这意味着客户会看到各种版本。 他们正在看到正在进行的工作并观看正在制作的香肠。 这通常是一种令人沮丧和困惑的体验，需要客户不断重新学习不断发展的系统。 最好在 UX 流程的幕后进行迭代，并让测试人员清楚这是一个原型或演示版本。
3. 监测和测量。 如果一个新概念被实时发布，用户体验研究人员没有很好的方法来观察人们使用它、向他们提问并获得用户体验所需的反馈类型，以确定某件事是否已经准备好或是否需要再次迭代。 UX 总是想知道为什么，质量，而不仅仅是什么或多少。 用户如何消费、转化、参与等？ 避免正确的用户体验测试会使诊断和修复问题或客户痛点变得更加困难。
4. UX 测试是物有所值的。 用户体验测试并不是一笔巨大的开支。 一些第三方测试工具要求每位测试参与者的费用低于 100 美元，有些则要求每年至少投入数千美元。 考虑到公司对软件开发过程的总体预算以及早期测试反馈的重要性，这些费用并不大。 与让程序员构建我们可能不得不撤消或再次构建的东西相比，几轮用户测试的成本几乎总是更低，速度更快。
5. 用户测试解决了争论。 如果您的公司不允许用户体验专家对产品的设计方式做出最终决定，那么当对应该构建和发布的内容有不同的想法时，您可能会发现用户体验与产品、工程或利益相关者发生冲突。顾客。 或者，如果 UX 有两个强有力的想法，他们想知道哪个更好地与客户联系呢？ 这里的解决方案是用户测试。

UX 可以对概念进行原型设计。 最好将竞争归结为最好的两个设计，特别是如果您已经可以在想法和团队成员之间找到折衷方案。 这意味着我们不是在测试 UX 想要什么、产品喜欢什么、工程主管喜欢什么、scrum master 认为听起来是个好主意还是 CEO 的生活伴侣喜欢什么。

用户测试让客户畅所欲言，并帮助您找到功能或产品的正确方向。 它通过为团队提供可靠的定量和定性数据来解决争论，这些数据告诉每个人哪个想法可能带来最大的客户满意度。

不涉及用户，就不是以用户为中心的设计。 这意味着我们与真实或原型客户进行研究和测试，而不是猜测、假设或“只是运送它”。 我们必须确保我们“刚刚发布”的内容已经通过用户测试进行了审查，并且是对一个好主意的出色执行。

当 UX 被规避或减少时会发生什么？

Skype 最近宣布，旨在使其更像 Snapchat 的 2017 年重新设计失败了。 用户不想要、不需要或不喜欢这些新功能。 强烈的反对声音足以让 Skype 在 2018 年宣布他们将再次重新设计 Skype。 （https://devops.icu/skypes-coming-redesign-of-their-last-redesign/）

用户体验专家会在他们流程的许多步骤中知道这些功能可能是不需要的或失败的。 对目标用户的研究可能很快表明他们不希望 Skype 成为 Snapchat。 在这个早期终止项目或转向可能会为 Skype 节省数百万美元以及负面新闻和客户疏远。

即使用户体验研究被绕过，在用户身上测试用户体验原型也会清楚地表明，客户不希望 Skype 朝这个方向发展。 由于 UX 仍在进行中，工程人员还没有编写任何代码。 这可以节省大量时间、金钱和人力资源，庆祝简单性和工程不需要做的工作。

敏捷用户体验过程

记住敏捷宣言原则。 您的首要任务是通过构建有价值的软件来让客户满意。 为（UX）员工提供他们需要的环境和支持，相信他们能够完成工作。 最大化未完成的工作量。 对良好设计的持续关注可以提高敏捷性。

正在向前发展的项目需要为用户体验提供一个巨大的跑道，以便可以开始适当的研究、设计和测试。 不要邀请 UX 参加您的启动会议，并要求他们必须在几天内交付最终线框，这让他们感到惊讶。 那不是用户体验。

不要将其视为大设计前期（BDUF），这是一个旨在让人们畏缩并宣称这是我们必须摆脱的东西的术语。 当一个项目或功能很大或很新时，UX 有必要循环通过大部分（如果不是全部）以用户为中心的设计过程。 对于 UX，更大功能的最小可能部分是用户的工作流程或过程。 如果我们设计和测试更小的东西，我们就会冒着无法全面了解真实用户体验的风险。

例如，如果我们正在设计用户注册和购买的流程，我们不能只设计密码选择字段并将其提交给工程。 如果用户体验是小块的，那么什么时候会测试整个过程？ 如果不测试整个流程，我们就无法知道用户对整个流程的反应……这意味着必须在进行可用性测试之前设计整个流程。

在功能、故事或修复很小的地方，UX 从业者可以完成以用户为中心的设计过程的子集并更快地工作。 UX 总是会尽可能快地进行，但优秀的 UX 专家会尽其所能避免牺牲正在完成的工作的质量。 在快与好的战斗中，用户体验总是会选择好而不是快……你也应该这样做。

预算和时间表阻碍了 UX 获得快速反馈和迭代。 用户体验从业者总是想要反馈和改进产品的机会，旨在设计真正适合客户的产品。 尽早将 UX 从业者引入投资组合管理和规划，使 UX 能够估计他们需要的时间和预算； 这些不应该是后来的意外或冲突的原因。

UX 从业者是敏捷团队的一员

将您的 UX 设计师嵌入敏捷团队。 邀请他们发布计划、站立会议、回顾会议以及可能讨论 UX 的每次会议。 允许 UX 在发布计划期间估计他们的时间，这样就不会对 UX 任务所需的时间感到意外。 不要在没有他们的情况下做出决定。 如果您的 UX 团队成员错过了会议，请等到您可以亲自、通过聊天、电子邮件或您公司使用的任何方法找到他们。

将问题、歧义或错误分配给 JIRA 中的 UX 队友或您使用的任何错误跟踪系统。 确保用户体验问题与其他问题在同一个系统中； 如果您将 VersionOne 用于其他所有内容，请不要在 Trello 板上丢弃 UX 问题。

在 UX 有长长的跑道之后，如果此功能或产品需要它，最佳实践是让 UX 比工程提前 2 个或更多 Sprint。 UX 可以和你一起冲刺。 将大量技术故事或技术债务修复到积压中。 这样一来，如果 UX 的创意和循环流程运行较晚或需要更多冲刺，开发人员就可以真正变得敏捷。 他们可以切换到产品或工程优先考虑的一些容易实现的目标，而不是等待用户体验。

还要考虑资源、分配和人员配备。 根据项目的大小，分配给一位用户体验设计师的项目不超过 3 个。 如果您有独立的、专业的 UX 研究人员，他们也进行测试和分析，请分配一名研究人员到不超过 3 名 UX 设计师。 如果你的 UX 从业者是所谓的 T 型，这意味着她在研究、测试和其他 UX 子专业方面也有资格和优秀，那么请确保她不会因为被分配到太多项目而意外成为瓶颈。

测量结果

没有客户满意度，您可能就没有客户。 您可以使用客户满意度指标来确定通过集成 UX 来改进您的流程是如何产生积极变化的。

• 更少的投诉
• 更好的应用评论
• 更高的应用评分
• 更少的支持票
• 更少的呼叫中心呼叫
• 社交帖子的更积极语义
• 更多应用安装，更少卸载
• AOV（平均订单价值）增加
• 更高的转化率

您还可以衡量所需的 DevOps 目标，例如上市时间和修复之间的时间。 在您的 UX 革命前后，故事、项目和史诗需要多长时间才能进入市场？ 当开发人员最终确定 UX 设计作为他们估计的基础时，开发人员的时间估计可能会更准确，而不是根据故事或您现在正在做的任何事情进行工作。

如果 UX 提供蓝图并且正在遵循这些蓝图，我们希望通过减少意外更改和重建来减少工程工作量。 早期更好的 UX 设计，以后更少的修复。

敏捷 UX 是一项不仅物有所值的投资

许多项目经理将用户体验视为可以删除或减少的预算线，而招聘经理对将用户体验任务与另一个角色结合起来的想法感到兴奋。 然而，越来越多的公司了解到，没有什么可以替代由训练有素且经验丰富的 UX 专家进行的适当 UX 流程的投资。

The Lean Startup 的作者 Eric Ries 问道：“如果我们发现自己在构建没人想要的东西怎么办？ 在那种情况下，如果我们按时按预算完成有什么关系？” 即使您的组织没有使用精益方法，警告仍然适用。 当我们的目标是为客户构建正确的东西、提高客户满意度并开发具有高客户价值的功能时，DevOps 的预期结果与此相呼应。

了解您的客户，让您的客户参与到流程中，并针对他们的真实需求和偏好进行构建，最终比时间表、预算、框架和工具更重要。 相信如果你正确地执行正确的想法，就会有收入。