你们觉得 UED 团队组织架构应该是怎么样的？

你们觉得应该按照业务支持来划分好，还是按照专业维度来划分好？

还是其他？

【xidea的回答(7票)】:

这个，可能要考虑到团队规模。在大公司里面，我觉得从公司整体的运作来说，还是按照业务支持来划分好。理由如下：

1、公司一旦大起来，跨部门的沟通与协作成本将会非常非常的高，如果UED作为一个公共部门存在，而不是在具体业务中，又将极大的提升这种成本。

2、在人员相对稳定的基础上，UED团队中的任何职位，都必须非常熟悉产品和业务，才能够提供靠谱的设计。很多时候，对产品的了解，要比实际的技能和通用的设计经验更重要。

3、跟UED团队中的成员合作最频繁最紧密的，并不是团队内部的同事，而是处于UE上游的PM，以及处于UE下游的前端等技术团队。那么，按产品线划分，有利于合作的各个环节的相互交流、沟通和了解，有利于彼此的适应，进而有利于提升整体效率。

但是，就像上面的朋友提到的，“如果按照业务维度，只是一时增加了和业务团队的紧密合作程度，时间一长，ued一定会被业务压下去而无法发挥作用。”所以，以上理由，还需要基于下面的前提：

1、UED跟其他团队，需要拥有同等的话语权。至少不能很弱。

2、在相互合作和沟通的前提下各负其责，对于UE所涉及的细节，UE有否决权，任何PM和技术人员，只能提建议，然后大家讨论，但最终如何设计，必须由UE决定。（同样，PM等团队，也对于自己所负责的那部分拥有否决权。比如，一个功能，要不要上，大家都可以提出自己的见解，但是最终由PM决定。）

3、从管理上，KPI分配上进行调节，保证个团队人员都做事相对客观。

【刘伟的回答(3票)】:

专业维度更利于长远发展。如果按照业务维度，只是一时增加了和业务团队的紧密合作程度，时间一长，ued一定会被业务压下去而无法发挥作用。到时候用户体验就是扯淡了，不停的上新产品，不停的下老产品，所有人都是流水一般。退一万步说，ued和业务、技术团队的合作好坏，不应该是由部门架构决定的，而是靠人和制度。

原文地址:知乎