设计管理
UED，也就是User Experience Design，作为从现代互联网公司发轫，然后逐渐浸淫扩展至社会各类型商业公司实体，甚至事业机构和政府机构的一个部门。它在国内的发展，经历了漫长而又曲折的过程。
一、UED内部的专业岗位分工
UED在20世纪末，伴随着互联网公司在国内兴起而出现。最早UED一般被称作美工部，有的公司是把它作为产品部的一个组成部分（如最早的携程和易趣），有的公司是把它作为技术部的一个组成部分；而那时候的UED其职责范围也是非常简单的，主要就是“网页美化”，当时视觉设计方向的设计师并没有明确的岗位职责划分，都是“网页设计师”。
1. 早期的UED
最早的网页设计师是不负责html代码编辑工作的，但几年之内形势就发生了转变，一部分设计师开始使用frontpage，dreamweaver编辑简单的网页，这样极大地减轻了技术部的工作，毕竟当时的技术部也没有做到前后端代码分开。
真正的分水岭出现在2005年前后，当时虽然“ui设计师”“交互设计师”“前端工程师”的岗位名称还没有正式出现。但在大型的互联网公司内部，已经出现了有不同侧重点的岗位分工；特别是前端工程师，最早是从熟练运用frontpage/dreamweaver等网页编辑工具中成长起来的，并逐渐开始接触CSS和javascript，这些设计师已经基本明确自己未来的职业走向，就是轻设计重代码的发展方向。
2. 网页设计师岗位分工出现
虽然交互设计（用户体验设计）的岗位分工和前端工程师的出现几乎是同一时间，但在国内主流互联网公司里，交互设计师岗位作为一个单独的角色，则要相对较晚，大约2007年以后整个国内互联网界才逐渐认识到交互设计和用户体验设计的重要性。
此时“用户体验”已经成为一个非常热的词汇而被各大公司领导层时刻挂在嘴边了，而“UED”这个名称被大范围广泛应用，也差不多就是在这个时期。从这个时期往后，UED部门受到了前所未有的重视，用户调研、文案、运营等岗位分工也相继出现。
3. UED规模最大时岗位分工
那个时候因为公司非常重视用户体验，也就非常重视UED，UED基本上获得了它所能够获得的所有关注度和资源。很多与最初的“设计”相关度较低的岗位也成为了UED的一部分，如文案、数据分析、前端工程师等岗位；而UED的部门领导，最鼎盛时期是脱离了对于产品部门和技术部门的依附状态，直接向CEO汇报的。
每个公司的具体情况不同，UED的规模和命运也都完全不同。但基本上来说，UED的这种鼎盛状态，从2007年开始一直持续到大约2014年左右，然后就开始随着新的岗位和角色开始受到重视，慢慢回归到了本来的“用户体验”上来。这个过程是缓慢进行的，有些岗位的逐渐壮大和转变是慢慢发生的。
如前端工程师逐渐脱离UED，是随着移动互联网的出现和发展同步进行的。新的JS框架打通了前后端，一个合格的前端工程师已经不再是仅仅需要熟练掌握原生JavaScript和jQuery就足够，而是需要开始学习很多新出现的框架。这时候UED对这个岗位的羁縻，就已经是明显地力不从心了。而文案和数据分析开始逐渐远离UED的过程，可能开始得还要更早一些。
接下来也有一些岗位即将会从UI设计中分离出来，而在有些公司已经在这么做了，这些岗位如插画师、动效设计师、3D建模设计师等等。
这些岗位的逐渐发展壮大和离开UED，对于UED和整个社会的发展来说，不能算是一件坏事，因为随着技术发展，岗位分工越来越细，越来越专业化，是一种趋势，而没有任何人、任何组织，能够逆这种潮流而动。
二、UED内部的组织架构
谈过了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设计管理人才。
三、UED怎样承接各种设计项目
讲完了UED组织架构方式，接下来就要讲讲UED怎样承接各种设计项目了。
UED作为一个公共资源池，在设计项目承接、完成、验收等环节要按照一套标准流程来运行，否则就会产生资源分配不均，厚此薄彼从而导致需求方产生怀疑和意见。
设计资源“不患寡而患不均”，如果在项目安排时按照一套严格的，始终如一的标准来分派项目，就会让整个设计流程有序运行，提升产出效率；同时又不会过分对设计师造成压力，达到各方都满意的效果。
在管理UED整个部门时，对组织架构设置的专业岗位组或业务线组leader进行有效监督和管理，在各组leader行使自己权限时，不过分干预；同时了解高ROI的项目进行状态，进行重点项目有针对性的跟进是比较好的管理方法。
在具体管理一个业务条线组或专业岗位组时，一般都会牵涉到具体的项目管理。
当然有些leader喜欢把负责项目直接安排到人，如果设计资源出现冲突或资源紧张时，再进行调配，这也是一种管理方式。我个人喜欢的管理方式是设计组leader直接做项目接口人，负责项目的分派、追踪、验收工作。
UED项目跟踪流程
在管理设计项目时，可以使用多种方法跟踪项目进度：
1. 10分钟站立会
很多公司的开发部门和设计部门在每天早晨上班后让所有组员围成一圈相向，然后设置一个会议组织人（一般是leader），一个记录人员（一般是组员轮值），大家依次介绍自己上个工作日完成的工作和本工作日需要进行的工作，以及在项目进行过程中遇到的问题或获得的经验。
因为大家都是站立，所以从形式上也就杜绝了拖延，一般只需要10分钟左右。
这种方式能让leader和组员快速掌握每个组员当天的工作安排，同时在资源上可以互通有无，相互支持，这种方式确实是提高工作效率，减少沟通成本的非常好的一种方式。
2. 写日报/时报
要求组内设计师每天/每小时汇报自己在每个项目上的工作进度，以文字形式发送给leader。
这种项目管理方式是设计师的噩梦，leader的大杀器，一般情况下不能轻易祭出。
因为一方面设计工作是一种创意性的工作，前期素材准备，项目背景、用户调研、需求分析这些准备工作是非常难以量化的。把设计师时刻捆缚在具体项目上，就如同用代码行数来考核开发人员，注定要与目标南辕北辙，背道而驰；而且这种管理方式对UED凝聚力、效率伤害极大，一般不建议使用。
3. 周报
如果说日报/时报是方便了项目管理但严重伤害了设计师积极性，那么周报就是在这之间形成了一个微妙的平衡。不写周报，项目进度会难以把控，设计师工作会无法准确衡量；效率高、设计质量高的设计师得不到正向激励，就会导致劣币驱逐良币，导致设计师自由散漫，不利于项目管理。
所以要求设计师每周五总结本周工作，以固定格式发送给leader，以有效进行项目管理。
周报格式有多种，我们使用的格式是：
项目名：
项目重要程度（以星级展示）：
项目简介：
项目进度：
项目需求方：
具体到每个公司，周报格式可以有所不同。
4. 项目管理工具
现在市场上有各种各样的协作工作和项目管理工具，我个人偏好使用甘特图来管理项目进度。甘特图直观、高效，可以快速掌握UED资源使用情况和工作饱和度，同时也方便对项目进入、进行中、完成全流程进行把控。
如果追求简单，可以直接使用excel来设计自己的Excel甘特图项目管理工具（这是我以前公司领导传授的技巧）：
用Excel管理项目
用Excel生成横向纵向尺寸相同的方格，以横向来标示日期，以纵向来标示不同项目，同时冻结日期栏。甘特图中的不同颜色可以用来表示不同的设计师，也可以用来表示不同的专业岗位、或者设计阶段、或者项目类型，以你自己对项目管理的要求来定。
用这个工具即便是非常繁琐的日常项目或时间跨度非常大的项目都可以进行有效管理，因为颗粒度是天，所以对于特别琐屑的以工时计量的小项目不是很适合。
如果对颗粒度精确到工时的小项目，可以使用Outlook的日历管理工具，也是非常方便的。
Outlook项目管理可以精确到小时
也可以使用第三方的项目管理工具，如Tower（tower.im），它的日历工具也是颗粒度到天的项目管理工具，使用非常方便，而且支持多人协作，每个设计师可以自行维护自己负责的项目进度。
tower的日历管理工具
通过以上这些方式，可以让管理者快速了解项目进度，进行项目管理工作。
要应付庞杂的项目需求，还需要对项目的优先级和重要程度进行评定。这个评定可以是完全公开量化的，也可以是以自己的标准根据项目需求特点快速给出判断，一定要把影响公司战略目标实现和战略级的项目区分出来，优先考虑。
一旦确定了项目的优先级和重要程度，就要做到重点项目重点跟进，次要项目选择性跟进，日常项目放手让设计师跟进。
四、设计师对专业岗位的角色转换看法
聊完了UED的设计项目管理，接下来再谈谈设计师对专业岗位的角色转换看法。
UED内部主要的几个专业岗位是：视觉设计师、UI设计师、交互设计师，这几个专业岗位因为专业间跨度比较小，所以设计师比较容易在这几个岗位之间做转换。
在UED管理过程中，发现有些设计师之间，有一条暗的转换路径存在：
UED内部岗位迁移路径
很多视觉设计师在进行一段时间的视觉设计后，会有转作UI设计师的想法；而有些UI设计师，却想着去做交互设计师；很多交互设计师最后转行做了产品经理；而从交互设计师转作UI设计师、从UI设计师转作视觉设计师的情况虽然也存在，但却相较这条迁移路径来说，较为少见。
我自己思考了一下这种迁移路径的现象，同时在和我的领导KK讨论后，我们认为这种现象主要由以下几个原因导致：
1. 视觉设计和UI设计是需求方眼里更容易挑战的工种
其中，视觉设计是最最容易被挑战的，UI设计次之，而交互设计一般是黑白稿线框图，需要更强的逻辑思维和产品思维才能提出意见；所以基于“柿子专挑软的捏”的心理，视觉设计也就在设计工作中变成了最容易被需求方干涉的岗位。
我们经常拿来调侃的“我想要一个五彩斑斓的黑”、“我想要大气的设计”、“再放大的基础上再缩小一点”等等需求方的金句，其实是这种现状的最真实反馈。
而设计师自己也认识到了这个问题，自然希望能够更清净不受干扰地做设计，这种情况下就产生了转岗的想法，而在我同有这类想法的设计师沟通时，这个原因占比最大。
2. 视觉设计的待遇长期落后于其他专业岗位
视觉设计师因为进入门槛低，所以很多设计师都是从这个岗位起步进入用户体验这个领域。
因为进入门槛低，所以行业内长期以来视觉设计师的待遇是低于UI设计师和交互设计师的。而交互设计师这个岗位因为是随着用户体验被公司越来越重视的背景下出现和发展的，它一开始就站在比较高的起点上，所以创业公司和小型互联网公司一般没有这个岗位，只要是有交互设计师这个的岗位的公司，岗位待遇一般是比较好的，这也客观造成了设计师“人往高处走”，追求更好待遇的现实。
但这种现象慢慢也在被扭转，因为我们可以看到好多大厂和创业公司发出来的JD，对于资深视觉设计师开出的价码是令人咋舌的；而我认识几个真正热爱视觉设计的设计师大牛，在行业产生一定影响力后，都拿到了非常丰厚的报酬。所以说设计师朋友如果因为这个原因想要转换岗位，真的需要三思。
3. 因为真的热爱其他岗位
很多设计师是懵懵懂懂进入用户体验这个领域的，而在进入这个领域以后，在实际工作中才发现自己更加喜欢另外一个岗位的工作，这种情况也是很常见的。
我认识好几个UI设计师是因为真的喜欢交互设计所以千方百计想要转变，但很遗憾的是我内部无法帮他们实现这个目标，最后他们离开后去其他公司转交互设计，结果都做出了很大成绩。其中一位甚至还成了大牛，写了一本交互设计方面的专著，这个案例也是我一直喜欢拿来跟设计师朋友分享的。
因为兴趣爱好是最好的老师，基于这个原因转换专业岗位的设计师，目标最纯粹，所以转换后也最能快速适应，并做出更大成绩。
虽然我的权限范围内可能因为当初招聘原因和承接项目类型原因等无法让一个设计师转岗，但我努力为每个设计师提供尝试不同类型岗位的机会。
我会要求视觉设计师具备一定的UI设计领域的知识，UI设计师具备视觉设计师的功力和一定的交互设计能力，而交互设计师需要具备一定的UI设计功力。这样可以让设计师在日常工作中，可以体验不同岗位的工作内容，同时可以让设计师真正了解自己的优势和特长。这样的管理方式能帮助设计师认清自己的优势，而且也让设计师增加新鲜感，具备全栈能力，而且更加稳定。
所以如果有设计师朋友遇到了类似苦恼，想要向我咨询是否需要转变的意见，我觉得这个问题的答案，其实就在每个设计师自己心里：
你真的喜欢这个岗位吗？你愿意为这个岗位奉献自己所有的热情和努力吗？
如果答案是肯定的，那么义无反顾地去追求自己的目标吧。
人生最重要的追求就是找到适合自己的那个位置，并努力为之奋斗。
以上就是我在多年的设计管理工作中积累的一些经验和心得体会，希望能够跟各位设计师leader们一起探讨，共同提高。
题图来自Unsplash，基于CC0协议
相关阅读
序言纵观运维的
#目录文章目录#简介格兰杰因果关系作为一种可以衡量时间序列之间相互影响关系的方法，最近十几年备受青睐。无论是经济学[1]，气象科
日常使用 App 的时候，我们几乎天天都会碰见「小红点」「消息角标」，今天简单梳理下小红点及其产品特性。小红点是什么小红点在技术
《漫谈CRM体系化建设》系列共分五篇，前三篇讨论了企业客户管理的基本业务问题和新客户开发管理问题，以及如何进行客户分析并实现精
离开大学校园，从一个底层的Coder，在多个技术领域深浅不知的跋涉过，渐渐专注于现在的微软Dynamics平台和Data技术。 以前总是在网络间