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

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

DevOps的意义远不止于此 而不是开发人员如何与IT连接，如何管理基础设施，以及如何 框架 可以改进. 它是关于认识到有多少团队真正参与到软件开发过程中, 他们的角色和工作是如何交织在一起的, 找到更好的方法来确保每个人都在谈判桌上.

当产品和创意团队设计软件或系统时，开发人员和工程架构师希望参与其中. 但是，在当前的DevOps定义中，这在哪里呢? 产品, UX, 创意团队想要参与到工程过程中，但很多方法都将他们排除在外. 我们需要打破这些陈旧的藩篱.

你的客户只看到你的用户体验(UX). 他们不会看到你有多少开发人员，或者你是敏捷的还是精益的. 他们不知道正在使用哪些DevOps工具. 你公司的用户体验就是产品，它可以成就你，也可以毁掉你. 他们想知道是谁造了这个垃圾. 在如此激烈的竞争中，人们乐于卸载应用程序或离开网站, 你会得到抛弃你的客户的第二次机会吗?

敏捷很少培训用户体验或与用户体验专家一起工作

许多工程团队经常发现用户体验是孤立的，很难与之合作. 用户体验似乎并不精益，许多敏捷的风格都排除了如何处理用户体验的细节. 一些 敏捷方法 特别建议产品负责人描述的特性“足够好”.”

安全的敏捷 错误地认为解决用户体验孤岛的最佳方法是完全排除它们. SAFe“授权敏捷团队”去做他们自己的“精益用户体验”.“随着越来越多的公司了解合并的价值 用户体验专家 和一个完整的用户体验过程，SAFe走错了方向.

由于没有从敏捷培训和书籍中解释用户体验及其过程，世界各地的领导团队都排斥或尽量减少专业产品设计师的参与.

• 当你错误地认为UX只是在页面上画方框时, 人们很容易认为“我能胜任那份工作。.“就像许多《欧博体育app下载》的海选选手一样，大多数人都确信自己是这个星球上最好的歌手 产品经理 而工程师们自认为在用户体验方面很出色. 这通常意味着他们相信自己很擅长布置屏幕. 但正如本文所解释的那样，真正进入UX工作的是什么, 你将会看到用户体验专家不会将制作线框的开发人员视为应该被赋予用户体验任务的人.
• 关于Scrum的书籍建议，如果用户体验专家成为瓶颈, 她应该训练非用户体验角色来完成她的工作. This type of decision is rarely suggested about other roles in software development; nobody would want an untrained or in经验d developer to do the coding, 即使是在参加了一个训练营或者读了一本关于编程的书之后. 如果开发人员成为瓶颈，我们永远不会建议这样做, 她应该培训项目经理编写一些代码.
• 那些错误地认为UX是一项艺术(UI)工作的招聘经理会雇佣美工来做UX工作. 用户体验学位和UI学位之间没有教育上的重叠. Natural talents often don’t overlap; someone great at UX might be a poor artist and vice versa. 招聘“UX/UI”通常会给你带来一个拥有最少UX经验的优秀美工, 专业知识, 过程, 或教育.

那些只看底线的人会喜欢削减预算，把用户体验任务交给那些可能缺乏用户体验教育的人, 经验, 专业知识, 技能, 或者天赋. 但这是目光短浅的做法，可能导致生产力低下, 效率, 文化, 产品, 以及客户满意度.

为什么要在敏捷开发中加入用户体验设计

2018年底，欧博体育app下载公司 麦肯锡 & 公司发布，"设计的商业价值，这是一份他们对300多家公司进行研究的报告.

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

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

麦肯锡也报告说, “公司必须在整个过程的早期全盘接受设计，而不是将其视为日后的小工具.“团队认为对用户体验的关注是可以最小化的, 被排除在外, 或者在发布产品后采取了错误的方法.

麦肯锡收集了定量数据，发现采用用户体验设计的公司在5年内创造了32%的收入和56%的股东回报. 宣称你的公司是“以用户为中心”是不够的. 您必须将UX实践者和流程从计划和投资组合一直集成到开发和QA.

有和没有用户体验的软件开发过程

如果你的公司没有在敏捷中包含用户体验 软件设计 在开发过程中，您的流程很可能如下图所示.

客户、产品经理、首席执行官或有远见的人告诉工程师他们想要什么. 工程师构建它，测试它，并将它放在登台或生产服务器上. 有远见的人看到了，你不知道吗，他们不高兴. 他们想要一些不同的东西，或者已经改变了主意.

然后，工程必须回到起点, 找出这个人现在想要什么, 构建, 测试, 祈祷这就是魅力所在.

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

测试可能会暴露出一些缺陷，从而允许用户体验进行迭代并经常进行测试. 在UX的过程之后，你就有了一个经过全面审查的设计，可以交付给工程师了.

如果有人中途改变了主意, 这个人与用户体验对话，而不是把它作为一个变更请求提交给开发人员. 用户体验在他们的过程中运行干扰，没有用户体验参与设计，任何东西都不会发送给工程, 决定, 对真实客户或原型客户进行测试.

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

用户体验有一个形式化的过程

以用户为中心的设计(UCD)是一个正式的过程，包括指导用户体验专家进行研究的任务, 设计, 原型, 对真实用户或原型用户进行测试, 然后根据从测试中学到的知识进行迭代.

我们首先关注其中的几个领域 需求和早期讨论 关于特性和项目. 当用户体验第一次 需求 其他项目信息，马上开始合作是很重要的. 用户体验不应该在之后发现他们设计的东西是无法构建的.

当产品或项目经理决定功能和优先级时，首先引入用户体验工作人员或经理. 一个对用户没有价值的项目可以被删除，从而节省了数不清的时间和金钱. 这就是最大化未完成工作量的地方. 当产品和工程部门通过减少或删除功能或整个项目来减少工程部门的工作量时，他们应该支持用户体验. 然而, 太频繁, 项目有自我依恋，团队成员经常将用户体验排除在这些早期对话之外，以便项目获得资金.

研究 是用户体验的重要组成部分. 没有用户参与就不是以用户为中心. 统计数据和定量数据很重要，但访谈用户是不可替代的, 深刻理解他们, 获得定性数据. 用户体验想要知道为什么，而不仅仅是什么.

用户体验研究还通过将每个人都统一在人物角色上，让团队成员站在同一页上, 目标客户的原型. 基于对用户的采访, 我们把我们学到的东西汇总起来，把每个人都归结为6个或更少的角色. 他们的动机是什么?? 他们需要做什么? 我们的公司、产品或服务的机会在哪里?

人物角色的最佳用途是将其包含在任何地方. 产品根据人物角色(和良好的数据)想象功能. 基于角色的用户体验设计. QA测试，同时想象他们是这些角色. 市场营销可以添加他们的人口统计和其他细节, 但他们也应该考虑如何让品牌发声, 社交媒体, 广告对人物角色说话.

人物角色帮助非用户体验工作人员远离, “嗯, 我喜欢这样,” or, “CEO喜欢这样.“我们是为这些目标客户设计的，如果你或首席执行官不适合这些角色, 那么用户体验就不会被自我或个人偏好所左右. 用户体验必须以客户为中心.

信息架构 与层次结构、结构和分类法有关吗. 这可以是站点导航，也可以是如何在电子商务数据库中对产品进行分类. 我们希望确保客户能够通过类别、元数据和过滤器轻松找到产品.

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

用户体验原型就像活的线框. 它们是可点击的交互式数字模型. We don’t have to write code; we have software that helps us create these quickly. 寻找更真实原型的公司使用Axure，因为它具有条件逻辑, 变量, 手机滑动手势, 拖放, 以及各种各样的事件触发器. 你可以为任何类型的设备制作原型.

用户体验原型是为了:

• 头脑风暴
• 合作
• 迭代
• 探索解决方案
• 向投资者推销(针对初创公司)
• 测试原型，看看解决方案是否与目标用户紧密相连。.
• 向开发人员或其他团队成员交付交互式模型, 这通常优于文档页面(并且没有可点击的模型)。.

现在转到 用户测试, 也叫可用性测试, 发生在用户体验过程中，在工程师写代码之前. 你必须测试你的概念和设计，以确保你的想法和执行对目标客户来说是非常棒的.

用户测试将发现任何缺陷, 让用户体验有机会迭代想法, 在这一点上，哪个是便宜的，因为没有任何工程来建造或重建.

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

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

UX可以创建概念原型. 最好把比赛归结为最好的两个设计, 特别是如果你已经找到了各种想法和团队成员之间的妥协. 这意味着我们不是在测试用户体验想要什么、产品喜欢什么、工程主管喜欢什么、scrum主管认为听起来不错的想法、CEO的生活伴侣喜欢什么.

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

这不是没有用户参与的以用户为中心的设计. 这意味着我们研究和测试真实的或原型客户，而不是猜测, 假设, 或者“发货吧。.“我们必须确保我们‘刚刚发布’的内容已经通过用户测试，并且是对一个伟大理念的出色执行.

当用户体验被规避或减少时会发生什么?

Skype最近宣布了其2017年的重新设计, 目的是让它更像Snapchat, 失败了. 用户不想要、不需要、也不喜欢这些新功能. 这种强烈的反弹足以让Skype在2018年宣布，他们将重新设计Skype. (http://devops.icu/skypes-coming-reDesign-of-their-last-reDesign/)

用户体验专家在其流程的许多步骤中都知道这些功能可能是不需要的或失败的. 对目标用户的研究可能很快就会发现，他们不希望Skype变成Snapchat. 扼杀这个项目或在这个早期阶段转向可能会为Skype节省数百万美元，加上负面新闻和客户疏远.

即使用户体验研究被忽略了, 在用户身上测试用户体验原型会让用户清楚地知道，用户不希望Skype往这个方向发展. 由于用户体验仍在进行过程中，工程师还没有编写一行代码. 这样可以节省大量的时间, 钱, 人力资源, 赞美简单和工程不需要做的工作.

敏捷用户体验设计流程

记住敏捷宣言的原则. 您的最高优先级是通过构建有价值的软件来满足客户. 给(UX)员工提供他们需要的环境和支持，相信他们能完成工作. 将工作量最大化 不 完成. 持续关注好的设计可以提高敏捷性.

正在进行的项目需要给用户体验一个巨大的跑道，以便进行适当的研究, 设计, 测试就可以开始了. 不要邀请用户体验参加你的启动会议，然后要求他们在几天内交付最终的线框图，让他们大吃一惊. 这不是用户体验.

不要将此视为预先设计(BDUF)。, 这是一个旨在让人们畏缩的术语，并宣称这是我们必须远离的东西. 当一个项目或特性是大的或新的, 对于用户体验来说，有必要在大多数情况下进行循环, 如果不是全部, 以用户为中心的设计过程. 对于用户体验来说，一个更大的功能的最小可能部分是用户的工作流或过程. 如果我们设计和测试更小的东西, 我们冒着没有把握真正用户体验大局的风险.

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

在功能, 故事, 或者修复很小, 用户体验从业者可以做一个以用户为中心的设计过程的子集，并且工作得更快. 用户体验总是尽可能地快, 但优秀的用户体验专家会尽其所能避免牺牲工作质量. 在“快”与“好”的较量中，用户体验总是会选择“好”而不是“快”，你也应该这么做.

预算和时间限制阻碍了用户体验获得快速反馈和迭代. 用户体验实践者总是希望得到反馈和改进产品的机会, 致力于设计真正适合客户的产品. Bringing UX practitioners in as early as portfolio management and planning allows UX to estimate the time and budget they will need; these shouldn’t later be surprises or causes of conflict.

用户体验实践者是敏捷团队的一部分

将你的UX设计师嵌入到敏捷团队中. 邀请他们参加发布计划、站立式、复古式和任何可能讨论UX的会议. 允许用户体验在发布计划期间估计他们的时间，这样就不会对用户体验任务所需的时间感到意外. 不要在没有他们的情况下做决定. 如果你的UX队友错过了会议, 等到你能亲自找到他们再说吧, 在聊天, 电子邮件, 或者你公司使用的任何方法.

分配问题, 模棱两可, 或者把bug告诉你在JIRA中的UX队友，或者你使用的任何bug跟踪系统. Make sure the UX issues are in the same system as other issues; don’t drop UX issues in a Trello board if you are using VersionOne for everything else.

在用户体验经历了漫长的历程之后, 如果此功能或产品需要的话, 最好的做法是让UX先于工程完成2个或更多的sprint. 用户体验可以和你一起冲刺. 将大量的技术故事或解决技术债务纳入待办事项. 这种方式, 如果用户体验的创造性和周期性过程延迟或需要更多的冲刺, 开发者可以做到真正的敏捷. 而不是等待UX, 他们可以转向产品或工程优先考虑的一些唾手可得的成果.

还要考虑资源、分配和人员配置. 根据项目的大小，将不超过3个项目分配给一个UX设计师. 如果你有单独的, 专业用户体验研究人员, 谁也做测试和分析, 为一名研究人员分配不超过3名UX设计师. 如果你的UX从业者是t型的, 这意味着她在研究方面也很优秀, 测试, 和其他用户体验子专业, 然后确保她不会因为被分配到太多项目而不小心成为瓶颈.

测量结果

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

• 少抱怨
• 更好的应用评价
• 更高的应用评级
• 更少的支持票
• 呼叫中心呼叫减少
• 社交帖子更积极的语义
• 更多的应用安装，更少的卸载
• AOV(平均订单价值)增加
• 更高的转化率

您还可以度量期望的DevOps目标，例如上市时间和修复之间的时间. 在你的用户体验革命前后，故事、项目和史诗需要多长时间才能进入市场? 当开发人员最终确定UX设计时，他们的时间估计可能更准确，而不是根据故事或您现在正在做的任何事情进行估计.

如果用户体验提供了蓝图，并且正在遵循这些蓝图, 我们希望通过减少意外变化和重建，工程可以减少工作量. 早期更好的用户体验设计，之后更少的修复.

敏捷用户体验设计不仅仅是为自己买单

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

埃里克·里斯，《 精益创业他问道:“如果我们发现自己做的东西没人想要怎么办? 既然如此，我们按时按预算完成又有什么关系呢?即使你的组织没有使用精益方法，这个警告仍然是正确的. 当我们的目标是为客户构建正确的东西时，DevOps的期望结果与此相呼应, 提高客户满意度, 并开发具有高客户价值的功能.

了解你的客户, 让你的客户参与到这个过程中, 最终，满足他们真正的需求和偏好比时间表更重要, 预算, 框架, 和工具. 相信如果你正确地执行了正确的想法，收益就会出现.