很多企业开展敏捷多年，但是UX部门仍旧是一个独立的部门，没有进入敏捷团队中。UX部门依旧按照自己原有的流程运作，即UX设计师属于每个项目的共享资源，项目的需求功能进入UX部门的需求管道后需要排期。在设计过程中，UX设计师与团队的交流不多，基本上只有在需求沟通会议上澄清一次需求；UX设计师做的设计，研发团队基本上是无条件接纳。事实上，开发团队敏捷起来了，但是UX部门仍旧按照瀑布模式工作，结果导致整个产品团队的敏捷性受到严重拖累，产品设计体验感差，UX部门与敏捷团队之间的摩擦不断，大家都苦不堪言。

某大型互联网企业U也面临着上述问题。团队在实践了Scrum和微服务架构后，开发和部署上线的能力增强，每周至少能够上线一个版本，但是交付速度经常被UX部门拖后腿，原因如下。

• 由于迭代计划受制于UX部门，即迭代计划中的需求依赖于UX部门的排期计划，所以团队经常无法完成迭代计划。
• 由于UX设计师是共享资源，无法只专注于一个产品的设计，加之其对业务理解不深，所以往往导致设计稿不但没有体现出核心场景，还经常被设计师带入自己臆想的需求因素。也就是说，该满足的需求不仅没有设计到位，反而使需求范围以隐秘的方式扩大。
• 好的设计同需求一样，是随着UX设计师对用户场景的理解的深入而逐渐涌现的，不是一成不变的。而该企业的UX设计稿的评审周期长达两周，一旦评审通过就很难再更改。
• 因为UX设计师不是团队的一部分，所以UX设计师与团队的沟通有限，于是UX设计稿成为开发的单向输入。
• UX部门独立于团队以外，有自己的关键绩效指标（KeyPerformanceIndicator，简称KPI），经常会为了实现创新的KPI而画蛇添足地加入与核心需求无关的设计，使用户对核心功能的需求没有被满足，体验感差。
  

由于以上原因，UX设计师与团队矛盾很深。那么该怎么解决呢？企业可以尝试以下措施。

1. UX部门派驻全职的设计师进入敏捷团队

如果在组织结构上无法打散UX部门，使其进入敏捷团队，至少让UX设计师专注做一个项目，以项目成员的身份加入团队之中深入了解业务，而不是同时做多个项目。UX设计师可将其工位搬到团队的办公区，参与团队的Backlog梳理、Scrum站会、计划会议、回顾会议和评审会议等。

2. 产品负责人、开发团队和UX设计师要错开工作节奏

由于设计本身的工作性质，UX设计师可能需要花几天的时间设计产品的骨架和大的特性，然后与产品负责人、开发团队讨论几个回合。这样一周就过去了，留给开发的时间几乎没有。因此，公司可以尝试将产品负责人的需求规划工作、开发工作和用户体验设计工作的节奏错开，如图8-19所示。

我们从图8-19可以看出，对于新特性以及大的UI改动来说，UX设计师的工作与开发工作应错开一周甚至两周的时间，这样既能给UX设计师足够的时间创作高质量的设计，也能给开发人员足够的时间搞开发设计。当然，如果是对团队已经完成的产品特性的小修小补，将UX设计工作与开发工作并行在一周之内也是可行的。

团队在本周的开发过程中可能会发现，在上周UX设计师完成的设计中有需要修改的地方，这时候UX设计师需要及时更改设计；团队在本周的开发过程中，也会参与UX设计师对下周设计稿的讨论。因此，UX设计师与开发团队、产品负责人之间不是完全地错开工作节奏，有些工作也是相互并行的。

图8-19UX设计师、产品负责人和开发团队的工作节奏示意图

1. 对产品设计的争执是良性的互动过程，产品负责人是最终决策者

UX设计师每次给出设计稿后会召集团队和产品负责人进行设计评审，产品负责人从业务和用户场景的角度给出意见，团队从技术实现的角度给出反馈。由于不同角色有不同的视角，所以他们有不同的意见甚至发生激烈争执都是正常的。这也是一个良性的互动过程，通过碰撞可以形成更好的设计，因为大家的目标是一致的，都是为了做出更有竞争力的产品。最终的设计应该是UX部门与团队一起达成共识的设计，但是当意见分歧到难以达成共识的时候，产品负责人就是最终决策者。

在采取以上措施后，整个UX部门就能从人员到工作方式完全融入敏捷流程。

很多企业开展敏捷多年，但是UX部门仍旧是一个独立的部门，没有进入敏捷团队中。UX部门依旧按照自己原有的流程运作，即UX设计师属于每个项目的共享资源，项目的需求功能进入UX部门的需求管道后需要排期。在设计过程中，UX设计师与团队的交流不多，基本上只有在需求沟通会议上澄清一次需求；UX设计师做的设计，研发团队基本上是无条件接纳。事实上，开发团队敏捷起来了，但是UX部门仍旧按照瀑布模式工作，结果导致整个产品团队的敏捷性受到严重拖累，产品设计体验感差，UX部门与敏捷团队之间的摩擦不断，大家都苦不堪言。

某大型互联网企业U也面临着上述问题。团队在实践了Scrum和微服务架构后，开发和部署上线的能力增强，每周至少能够上线一个版本，但是交付速度经常被UX部门拖后腿，原因如下。

• 由于迭代计划受制于UX部门，即迭代计划中的需求依赖于UX部门的排期计划，所以团队经常无法完成迭代计划。
• 由于UX设计师是共享资源，无法只专注于一个产品的设计，加之其对业务理解不深，所以往往导致设计稿不但没有体现出核心场景，还经常被设计师带入自己臆想的需求因素。也就是说，该满足的需求不仅没有设计到位，反而使需求范围以隐秘的方式扩大。
• 好的设计同需求一样，是随着UX设计师对用户场景的理解的深入而逐渐涌现的，不是一成不变的。而该企业的UX设计稿的评审周期长达两周，一旦评审通过就很难再更改。
• 因为UX设计师不是团队的一部分，所以UX设计师与团队的沟通有限，于是UX设计稿成为开发的单向输入。
• UX部门独立于团队以外，有自己的关键绩效指标（KeyPerformanceIndicator，简称KPI），经常会为了实现创新的KPI而画蛇添足地加入与核心需求无关的设计，使用户对核心功能的需求没有被满足，体验感差。
  

由于以上原因，UX设计师与团队矛盾很深。那么该怎么解决呢？企业可以尝试以下措施。

1. UX部门派驻全职的设计师进入敏捷团队

如果在组织结构上无法打散UX部门，使其进入敏捷团队，至少让UX设计师专注做一个项目，以项目成员的身份加入团队之中深入了解业务，而不是同时做多个项目。UX设计师可将其工位搬到团队的办公区，参与团队的Backlog梳理、Scrum站会、计划会议、回顾会议和评审会议等。

2. 产品负责人、开发团队和UX设计师要错开工作节奏

由于设计本身的工作性质，UX设计师可能需要花几天的时间设计产品的骨架和大的特性，然后与产品负责人、开发团队讨论几个回合。这样一周就过去了，留给开发的时间几乎没有。因此，公司可以尝试将产品负责人的需求规划工作、开发工作和用户体验设计工作的节奏错开，如图8-19所示。

我们从图8-19可以看出，对于新特性以及大的UI改动来说，UX设计师的工作与开发工作应错开一周甚至两周的时间，这样既能给UX设计师足够的时间创作高质量的设计，也能给开发人员足够的时间搞开发设计。当然，如果是对团队已经完成的产品特性的小修小补，将UX设计工作与开发工作并行在一周之内也是可行的。

团队在本周的开发过程中可能会发现，在上周UX设计师完成的设计中有需要修改的地方，这时候UX设计师需要及时更改设计；团队在本周的开发过程中，也会参与UX设计师对下周设计稿的讨论。因此，UX设计师与开发团队、产品负责人之间不是完全地错开工作节奏，有些工作也是相互并行的。

图8-19UX设计师、产品负责人和开发团队的工作节奏示意图

1. 对产品设计的争执是良性的互动过程，产品负责人是最终决策者

UX设计师每次给出设计稿后会召集团队和产品负责人进行设计评审，产品负责人从业务和用户场景的角度给出意见，团队从技术实现的角度给出反馈。由于不同角色有不同的视角，所以他们有不同的意见甚至发生激烈争执都是正常的。这也是一个良性的互动过程，通过碰撞可以形成更好的设计，因为大家的目标是一致的，都是为了做出更有竞争力的产品。最终的设计应该是UX部门与团队一起达成共识的设计，但是当意见分歧到难以达成共识的时候，产品负责人就是最终决策者。

在采取以上措施后，整个UX部门就能从人员到工作方式完全融入敏捷流程。