UE UI PM的职责及职位分工.pdf

UEUIPM的职责及职位分工

其实很多人都搞不清楚这两个概念的区别，UE：userexperience，直译是用户体验；UI：u

serinterface，直译是用户界面。前者涉及运营，囊括一个网站出现在网络上时希望提供

给用户的所有服务形象，包含产品流程设计、界面设计，甚至是访问速度、稳定性、站内推

广活动等所有让用户形成网站印象的相关内容；后者属视觉层的劳动，从属于UE，主要是

通过视觉上的统一性帮助用户接受理解网站。

刚和一个同事聊起，就想起了以前看过的一些文章，以及诺曼的设计心理学。我不想从

UE/UI的具体应用上展开，网络上太多类似的文章，专业讲述UE/UI怎么做，不复赘言。

我想整理的，是关于怎么搭建UE团队，如何执行的想法。

UE团队，是个很特殊的团队，如果把一个网站比作是人体，他的作用相当于脊髓。

以前UED（userexperiencedesign）叫产品策划或者网站策划，一般没有很明确的分

工。去年去参加UPA会议时，发现一些大的IT公司，比如Intel、alibaba、Souhu、qq等，

已经有了职责明确的用户体验设计师，具体交谈时，了解到工作分工已很细致，说明他们已

经意识到了UE的重要性，对中国的IT行业而言，是件好事。

UE团队的建立比较困难，因为这个领域本身也是近几年才发展起来，没有专业的人才

可供挑选。所以成员最好不要选择同一类的，而是各种类型、层次的人都有配合。但有条基

本原则，一定要遵循，不管成员有什么专业技术，不管他来自哪里，一定要对产品本身有极

强的责任心。UED是个苦差，要想做出点名堂来，没有极强的责任心，根本坚持不了。

根据经验，比较完美的搭配是：平面设计师出身的两个，技术出身的一个，市场出身的

一个，完全是门外汉甚至不懂网络的fresh(比如刚毕业的实习生，多几个都无所谓)，加经

验充足全局意识强烈的开放式teamleader，会比较有效率。如果公司小，团队还可以缩减

到：一个技术出身+一个美工出身经验充足的leader。实在是小成本操作，支持不了太多人，

就一个沟通能力强、美工出身的也可以撑过去创业阶段。不过，如果公司有实力，财力允许，

还是建议加强UE团队的投入，另外把用户信息调研、网络动态分析独立成辅助团队，会对

整个产品的运作有很大的影响力。

再说到执行，这是很多UED一直抱怨的问题，UED经常夹在中间，上有公司领导的方向

性指令，下有设计部门、技术实现部门的实现问题。上头如果三天两头变脸，UE团队lead

er没有足够清醒的意识和全局观，或者退而求其次，没有足够的肚量听进去UE团队成员的

看法，去整理化解上头不一定科学的要求，导致的结果是快速的执行产品快速的死亡，甚至

严重点，会导致整个公司的混乱。

而这条产品链的下游，有个很多策划一直在抱怨的大问题。如果UE团队的沟通能力太

差，和设计部门、技术实现部门，尤其是后者，沟通的太差，后果就是互不认同双方的意见，

花费大量精力扯皮，双方关系恶化，结果呢？UE团队一味强调用户体验而不管系统性能是

否能支撑，技术实现团队单方面修改产品内核，甚至擅自更改页面体现产品流程。如果公司

的各项制度比较严格，还能避免这两类结果引发的产品问题，顶多就是产品过不了QA，重

新走流程增加开发成本（公司财力雄厚能接受也就无所谓了）。如果碰巧公司管理制度不严

格，那就催生了一大批糟糕的产品。一上线就被用户骂，久而久之，这个公司也就没什么前

途了。产品不合格，用户不买账，你拿什么回报投资人？

很多web2.0网站，一开始就靠某个概念来吸引用户，而没有真正做过UE，或许开头不

错，用某个事件网住了一批眼球，过后，网站没有真正让用户愿意使用的东西了，而其他网

站又跟着这个概念抄了上来，分析前者的得失，而后用之以新生命，很容易就把前者淘汰了。

还有个说法，马太效应，穷者更穷富者更富，规模效应让用户选择不换服务，但放到互联网

这样的自由环境里，假如一个服务太糟糕、又同时有其他二把手的服务供选择，聪明的用户

只要没有投入深厚的社会关系在该服务商，必然会选择搬家。其他的不说，看看雨后春笋般

的博客服务就知道了。

关于UE团队的执行，话题一起就发现有很多的内容牵扯出来，花开两枝暂且不表。

总而言之，要真正做好一个产品，不光只有好的技术或好的市