谈过了UED内部应该有的专业岗位分工，接下来就该聊聊UED内部的组织架构应该如何建立了。
UED的组织架构一般分为以下几种，其中每种架构又适用于特定的公司管理风格和UED规模，每种架构方式都有其优点和弊端。
1. 按业务条线纵向划分
UED完全按业务线划分的公司，一般来说是各业务条线之间协作度较低，比较重视各业务条线独立发展的公司采用的一种UED组织架构，这种组织架构一般造成的结果是UED总体管理组织结构松散，各条业务线负责UED之间的协作性、向心力较差，一般这样的组织架构下，UED的话语权也比较少。
2. 按专业岗位横向划分
一般规模比较小的UED可以采用这种架构，每个专业岗位小组里的成员针对全部业务线承接设计工作，这种组织架构方式在十几人的小团队里能够发挥出最大的能量，团队成员间的凝聚力，相互交流沟通和学习非常方便，同时每个设计师的能力和专业度都能得到最大程度的提升。但这种组织架构对UED管理者要求比较高，可能需要承担项目接口人和具体的项目管理工作，也可以把项目分配权力下放到各专业岗位组leader手中。
3. 先按专业岗位，再按业务条线
这种组织架构方式适合于UED规模特别大的公司（40人以上），这种组织方式的好处是如果在各个专业岗位组配合以资深的管理者，各专业岗位组内可以达到最大程度的专业交流，但同时整个UED的凝聚力又不会被削弱很多，因为一个组内的成员只是一个项目环节上的一环，要完成整个项目，成员必须在各个工种小组之间紧密联系，这样就既兼顾了专业度，又兼顾了业务线的业务背景熟悉，是一种比较有优势的组织架构方式，以前工作过的一家OTA公司的UED是采用这种管理方式。
4. 先按业务条线，再按专业岗位
这种组织架构方式也是适合于成员较多的UED团队，UED先按照业务条线划分为不同的组，每个组内再配备不同的专业岗位，优点是每个组因为仅针对自己负责的业务线，所以对于业务背景了解比较透彻，能够在业务线内深耕细作，同时因为和固定的业务方协作，执行效率较高。
但这种组织架构也有缺点，一方面是长期运作，可能会被业务方业务指标裹挟而在用户体验上损失独立性，因为设计组的指标和业务方指标会高度重合，而从宏观层面看，UED的目标和业务方的目标应该是有很大不同的。
此外因为项目基本上是独立在每个小组内独立完成，很容易形成小作坊，跨业务组之间的沟通和协作以及向心力会有所减弱。这就需要跨业务组的其他团队协作项目来作为有益补充，如定期分享、团队建设活动。
5. 组合方式
组合的UED组织架构就是打乱了原来的单纯按纵向业务线、横向专业岗位划分的局限，采用一种较为灵活的组织结构方式，比如把人力资源有限且使用频次较低的部门单独划分，把其他部分按业务线划分就是其中一种较常见的组织架构方式，这种架构的好处就是公共资源池共享，但又兼顾了业务线的专业度和协作度以及快速反应能力，比较接近谷歌提倡的OKR式组织结构方式，区别就是时效性上没有OKR小组那么灵活。
6. 按项目灵活划分小组
这种组织架构方式一般在外包公司或广告公司采用较多，UED是一个大的资源池和人力提供方，根据临时进入的项目不同，项目负责人自己招募需要的人，最后按人和项目贡献进行绩效考核，这种组织架构方式对人员的能力锻炼是非常有效且快速的，但同时带来的问题就是设计人员会有较为严重的焦虑感和缺少归属感。
以上列出了目前互联网公司比较主流的UED组织架构方式，当然不同的公司，有不同的企业文化和独特的管理方式，不能生搬硬套。
我曾经见过有些从大厂出来到了中小型创业公司的UED管理者，还死抱着以前那“成建制、成规模”的一套不变，拼命向公司要资源建立几十人的团队，结果项目需求根本完全不饱和，造成公司人力资源的极大浪费。
我也曾经见过有些UED管理者从小型公司一路发展壮大后，还是死抱着“扁平化”不放，事必躬亲，最后自己非常疲累但团队却得不到锻炼和成长，没有形成梯队，一盘散沙的情况。
“我之蜜糖，彼之毒药”，具体的组织架构方式要具体情况具体分析，用的顺手的就是好的，同时也要跟随团队一起成长，才能成为一个合格的UED设计管理人才。
