UE和UI (转)

其实很多人都搞不清楚这两个概念的区别，UE：user experience，直译是用户体验；UI：user interface，直译是用户界面。前者涉及运营，囊括一个网站出现在网络上时希望提供给用户的所有服务形象，包含产品流程设计、界面设计，甚至是访问速度、稳定性、站内推广活动等所有让用户形成网站印象的相关内容；后者属视觉层的劳动，从属于UE，主要是通过视觉上的统一性帮助用户接受理解网站。

　　刚和一个同事聊起，就想起了以前看过的一些文章，以及诺曼的设计心理学。我不想从UE/UI的具体应用上展开，网络上太多类似的文章，专业讲述UE/UI怎么做，不复赘言。

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

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

　　以前UED（user experience design）叫产品策划或者网站策划，一般没有很明确的分工。去年去参加UPA会议时，发现一些大的IT公司，比如Intel、alibaba、Souhu、qq等，已经有了职责明确的用户体验设计师，具体交谈时，了解到工作分工已很细致，说明他们已经意识到了UE的重要性，对中国的IT行业而言，是件好事。

　　UE团队的建立比较困难，因为这个领域本身也是近几年才发展起来，没有专业的人才可供挑选。所以成员最好不要选择同一类的，而是各种类型、层次的人都有配合。但有条基本原则，一定要遵循，不管成员有什么专业技术，不管他来自哪里，一定要对产品本身有极强的责任心。UED是个苦差，要想做出点名堂来，没有极强的责任心，根本坚持不了。

　　根据经验，比较完美的搭配是：平面设计师出身的两个，技术出身的一个，市场出身的一个，完全是门外汉甚至不懂网络的fresh(比如刚毕业的实习生，多几个都无所谓)，加经验充足全局意识强烈的开放式team leader，会比较有效率。如果公司小，团队还可以缩减到：一个技术出身+一个美工出身经验充足的leader。实在是小成本操作，支持不了太多人，就一个沟通能力强、美工出身的也可以撑过去创业阶段。不过，如果公司有实力，财力允许，还是建议加强UE团队的投入，另外把用户信息调研、网络动态分析独立成辅助团队，会对整个产品的运作有很大的影响力。

　　再说到执行，这是很多UED一直抱怨的问题，UED经常夹在中间，上有公司领导的方向性指令，下有设计部门、技术实现部门的实现问题。上头如果三天两头变脸，UE团队leader没有足够清醒的意识和全局观，或者退而求其次，没有足够的肚量听进去UE团队成员的看法，去整理化解上头不一定科学的要求，导致的结果是快速的执行产品快速的死亡，甚至严重点，会导致整个公司的混乱。

　　而这条产品链的下游，有个很多策划一直在抱怨的大问题。如果UE团队的沟通能力太差，和设计部门、技术实现部门，尤其是后者，沟通的太差，后果就是互不认同双方的意见，花费大量精力扯皮，双方关系恶化，结果呢？UE团队一味强调用户体验而不管系统性能是否能支撑，技术实现团队单方面修改产品内核，甚至擅自更改页面体现产品流程。如果公司的各项制度比较严格，还能避免这两类结果引发的产品问题，顶多就是产品过不了QA，重新走流程增加开发成本（公司财力雄厚能接受也就无所谓了）。如果碰巧公司管理制度不严格，那就催生了一大批糟糕的产品。一上线就被用户骂，久而久之，这个公司也就没什么前途了。产品不合格，用户不买账，你拿什么回报投资人？

　　很多web2.0网站，一开始就靠某个概念来吸引用户，而没有真正做过UE，或许开头不错，用某个事件网住了一批眼球，过后，网站没有真正让用户愿意使用的东西了，而其他网站又跟着这个概念抄了上来，分析前者的得失，而后用之以新生命，很容易就把前者淘汰了。还有个说法，马太效应，穷者更穷富者更富，规模效应让用户选择不换服务，但放到互联网这样的自由环境里，假如一个服务太糟糕、又同时有其他二把手的服务供选择，聪明的用户只要没有投入深厚的社会关系在该服务商，必然会选择搬家。其他的不说，看看雨后春笋般的博客服务就知道了。

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

　　总而言之，要真正做好一个产品，不光只有好的技术或好的市场推广就可以了，这个时代，以前能允许这样的产品称王称霸，现在，混口饭吃，没这么简单了。