网上讨论UED设计管理的四个部分和产品经理与 ued的相关题，大家都众说纷纭，那么今天小编为各位带来详细的讲解。
UED（UserExperienceDesign）是一个始于现代互联网公司，逐渐扩展到公共机构、政府机关等各类业务的部门。国内的发展是一个漫长而艰难的过程。
1.UED内部专业职位的分类
UED是随着20世纪末中国互联网公司的崛起而出现的。最初，UED通常被称为美术部门；在一些公司它是产品部门的组成部分；在另一些公司它是技术部门的组成部分；当时UED的职责范围非常简单。主要是“网页美化”，当时视觉设计方向设计师之间的分工并不明确，大家都是“网页设计师”。
1初始UED
早期的网页设计师并不负责编辑HTML代码，但几年之内，情况发生了变化，一些设计师开始使用FrontPage和Dreamweaver来编辑简单的网页，这使得技术部门的工作变得更加轻松。就连时间工程部门也未能将前后端代码分开。
真正的分水岭发生在2005年左右，当时‘UI设计师’、‘交互设计师’、‘前端工程师’这些职业还没有正式出现。但大型互联网公司内部却存在侧重点不同的分工。尤其是前端工程师，从小就熟练使用Frontpage/Dreamweaver等网页编辑工具，逐渐接触CSS和Javascript。设计师们基本明确了自己未来的职业方向，即轻设计、重编码的发展方向。
2网页设计师分工的出现
虽然交互设计的分工与前端工程师的出现几乎同时发生，但交互设计师在国内主流互联网公司中作为独立角色的确立却相对较晚。国内整个互联网行业正在逐渐认识到交互设计和用户体验设计的重要性。
这时，“用户体验”成为了一个非常热门的词，经常被大公司的领导挂在嘴边，而“UED”这个名字也正是在这个时候被广泛使用。从这个时期开始，UED部门受到前所未有的重视，用户研究、文案、运营等分工相继出现。
3、UED巅峰时的职责分工
当时公司非常关心用户体验，所以也非常重视UED，基本上给了它所有能得到的关注和资源。很多与原来“设计”关联不大的岗位，比如文案、数据分析、前端工程师，也成为了UED的一部分，其部门负责人在巅峰时期与产品部分离，成为了一个技术部门依赖并直接向首席执行官报告。
每个公司的具体情况不同，UED的规模和命运也完全不同。但基本上，UED的鼎盛时期从2007年左右持续到2014年左右，随着新职位和角色开始受到关注，它开始回归最初的“用户体验”。这个过程进展缓慢，一些地点的逐渐增长和转变发生得很慢。
例如，前端工程师越来越多地离开UED，这恰逢移动互联网的出现和发展。新的JS框架打通了前端和后端。合格的前端工程师不再仅仅需要精通基本的Javascript和jQuery，他们还需要开始学习许多新兴的框架。UED目前对这一职位的监督显然超出了其能力范围。逐渐将文案和数据分析流程从UED中移走的过程可能更早开始。
接下来，一些职位很快就会从UI设计中剥离出来，一些公司已经在这么做了，包括插画师、动效设计师、3D建模设计师。
这些职位的逐步发展壮大以及离开UED对于UED和整个社会的发展来说并不是一件坏事。因为随着技术的进步，分工越来越细化、专业化。这是一种趋势，任何人、任何组织都无法抵制它。
2、UED内部组织架构
说完了UED内部的专业岗位划分，现在就来说说UED内部的组织架构如何搭建。
UED的组织架构一般分为以下几种每种结构都适合特定的公司管理风格和UED规模，并且每种结构方法都有优点和缺点。
1按业务领域纵向划分
UED完全按业务部门分开的公司所采用的UED组织结构，一般业务部门之间的合作程度较低，更注重各个业务部门的独立发展。
这种组织架构的总体结果是UED整体管理组织架构松散，负责UED的各业务单元之间协调性和集中性较差。通常，在这种组织结构下，UED的发言权较小。
2按专业职位横向划分
通常，较小的UED可能会采用这种结构，由每个专业小组的成员为所有业务线执行设计工作。这种组织结构可以在12人或更多人的小团队中释放最大的能量，使团队成员非常方便地相互联系、沟通和学习，同时最大限度地发挥每个设计师的能力和专业知识。广告。
然而，这种组织结构对UED管理人员提出了较高的要求，他们可能需要与项目对接并执行具体的项目管理任务，并将项目分配权委托给各个专业职位组的领导。
3首先单击“专业职位”，然后单击“业务线”。
这种组织结构特别适合较大的UED公司，其优点是每个专业职位组都关联一名高级经理，以最大限度地提高每个职位组内的专业沟通水平。但与此同时，整个UED的凝聚力并不会被大大削弱，因为一个小组的成员只是项目中的一个环节，成员必须跨各个工作小组紧密联系才能完成整个项目。
这是一种比较有优势的组织架构，兼顾了专业知识和对业务业务背景的熟悉程度，而我之前工作过的一家OTA公司UED就采用了这种管理方式。
4首先按行业排序，然后按职位排序。
这种组织结构也适合成员较多的UED团队。UED首先根据业务领域分为不同的小组，每个小组都有不同的专业职位。优点是每个小组只专注于自己的业务。因为是负责这条线，所以对业务背景了解透彻，能够在业务条线内集中工作，同时与固定的业务方协作，所以执行效率高。
但这种组织架构也有缺点，一方面，由于设计团队的指标和业务方的指标不同，长期运营可能会受到业务方业务指标的影响，失去用户体验的独立性。从宏观层面来说，UED和业务方的目标应该是有很大不同的。
另外，由于项目基本都是各集团内部独立完成，很容易形成小作坊，企业和集团之间的沟通、协作、向心力都会减弱。这需要整个业务部门的其他团队协作项目，并提供有用的补充，例如定期共享和团队建设活动。
5种组合方法
一体化的UED组织架构打破了传统的纯粹垂直业务线与横向专业岗位的划分，采用更加灵活的组织架构，包括将人力有限、不常用的部门划分为单独的部门。直线是最常见的组织结构之一。
这种结构的优点是公共资源池的共享，但也是一种兼顾业务群体的专业、协作、快速响应的结构，更接近谷歌倡导的OKR组织结构。在时效性方面不如OKR团队灵活。
6根据项目灵活分组
这种组织结构一般用在外包公司或者广告公司，UED是一个大的资源池和人力资源供应商，项目负责人根据临时项目招聘必要的人员，最终确定人员和项目贡献。这种进行绩效考核的组织架构方式，对于员工能力的培养非常有效、快捷，但同时也造成了设计师严重的不安全感和缺乏归属感的题。
以上列出了当前互联网公司主流的UED组织架构，当然每个公司的企业文化不同，管理方式也不同，所以不能机械复制。
我见过从大工厂跳槽到中小型创业公司的UED管理者，仍然固守着以前的“体制和规模”，拼命向公司索要资源，组建一个几十人的团队。导致项目需求根本没有饱和，造成公司人力资源的巨大浪费。
我也见过一些UED的管理者，从小公司成长为大公司，但仍然执着于“扁平化”，什么事都要亲力亲为。最后很累，但却不允许团队锻炼和成长。而且没有任何分泌物，一片狼藉。
“我的蜂蜜是别人的药。”具体的组织架构要根据情况具体分析。易于使用的东西就是好的。同时，你要与团队一起成长，成为一名合格的UED设计人员。管理人才。
3.UED如何开展各类设计项目
说完UED的组织架构，我们再来说说UED是如何进行各种设计项目的。
UED作为公共资源池，在设计立项、竣工、报批等过程中必须按照一套标准流程进行运作。否则，可能会导致资源分配不均，从而产生关于哪一方更受欢迎、哪一方更受欢迎的疑和意见。边。
设计资源“不担心稀缺，他们担心不均匀”。在项目准备过程中按照严格一致的标准分配项目，将使整个设计过程有序进行，提高产出效率。走得太远会给设计师带来压力，要求他们取得令各方满意的结果。
在管理整个UED部门时，必须对组织架构中设立的专业岗位组或业务单元组组长进行有效监督和管理，了解各组组长的地位，同时避免对其行使职权进行不当干涉。更好的管理方法是追求高投资回报率项目、执行核心任务并跟进项目目标。
管理特定业务或专业团体通常涉及管理特定项目。
当然，有些领导喜欢直接指派项目经理，在设计资源冲突或缺乏时指派也是一种管理方法。我个人喜欢的管理方式是由设计组长充当项目接口人，负责项目的分配、跟踪和审批。
UED项目跟踪流程
管理设计项目时，有多种方法可以跟踪项目进度。
1次10分钟站立会议
很多公司的开发设计部门要求所有团队成员每天早上下班后围成一圈，面对面，然后设立会议主持人和记录员。该工作日所需的任务不仅包括执行的任务，还包括项目期间遇到的任何题或经验。
因为大家都是站着的，所以没有正式的耽搁，一般只需要10分钟左右。
这是领导者和团队成员快速了解每个团队成员当天的工作安排的好方法，同时也可以交换资源并相互支持，提高工作效率并降低沟通成本。方法。
2完成每日报告/小时
小组内的设计师必须每天/每小时报告每个项目的进度，并以文本格式发送给领导。
这种项目管理方法是设计师的噩梦，也是领导者的杀手锏，一般情况下不能轻易使用。
因为设计工作一方面是创意工作，前期的材料准备、项目背景、用户研究、需求分析等都很难量化。将设计师与特定项目联系起来不仅总是达不到目的，因为这就像使用代码行来评估开发人员一样，而且这种管理方法对UED的凝聚力和效率非常不利，因此通常不建议这样做。
3周报告
虽然日报/报纸有利于项目管理，但严重削弱了设计师的热情，而周报在两者之间取得了微妙的平衡。不写周报将导致项目进展困难
No Comment