一、活在童话里，很傻很天真
　　白鸦说过，UED 要做的就是要没有UED ，让人人都是UED。但我觉得这只是个美好的幻想罢了。现在好了，每个部门都在喊用户需求，用户体验，貌似声势挺好大，就好像当一件事情的责任和大家都相关的时候，那就和大家都没关系了，因为找不到主要负责的人。我看到的多是把自己想要做的事情包装成用户需求。其实，和以前一样，各个部门还是干自己那摊事，各扫门前雪，只不过扫雪的时候说是为用户扫得，用户需求经常被“绑架”。

二、招不到人，团队无法建立
　　这个行业圈子很小，挖来挖去就那几号人。小公司没招牌，没人愿意去。大公司门槛高，招不到合适的人。国内高校里基本没有相关专业，就算有，也很难培养出企业需要的人才。

三、没有立项权，只是跑腿的
　　有些公司的UED，其实就是把以前网站的视觉设计部门改了个名字，没有立项目的权限，对产品或服务的设计和规划基本没有控制权。试想产品和服务的项目发起方是产品经理，UED 只不过是产品经理的资源方罢了。整天伺候那些产品经理的需求就忙得吐血了，还说什么替用户需求呐喊。自己天天给人家跑腿，就算事情做成了，功劳主要还是人家的。

四、没有掌握用户数据， 变成了近视眼
　　很多公司UED没有接触网站用户行为数据的权限，当然也没有专门用户研究人员， 就看了几本用户体验相关的书，就开始天天跟人家谈可用性了。而且还得了敏感症，一些不痛不痒的鸡肋问题，用户还没喊疼了，自己先喊疼了。不知道自己设计的东西用户是谁，每天各种页面和功能的使用量是怎么样的，用户有什么样子的特征和行为。自己坐在那里闭门造车，设计靠拍脑袋，和产品经理吵的时候，就钻可用性的牛角尖，却没有考虑问题的普遍性和优先级。

五、没有前端资源，就没有了手和脚
　　很多公司UED 没有专门前端工程师。导致UED连简单页面和功能的改进都无法独立完成，而公司技术资源一般都被大的商业项目或者产品线的产品经理把控。这样的UED就算给了立项的权利也没资源推动。而有的公司UED虽然有专门前端工程师,但是前端资源要不就被搞新产品的产品经理给瓜分了，要不就被一些日常运营的小需求消耗光了，导致本该UED主导的非商业型的产品改进项目也无法推进。

六、没有尚方宝剑，上面没人
　　很多公司的UED 数在企业里影响力都不大，缺乏上层的支持。 UED 总是把用户摆在首位， 却很少研究一下高权重的内部用户的需求，自然得不到应有的支持。我经常能看到下面的场景。UED的人一旦有机会和上层接触，就大吐苦水，什么网站可用性的问题没有解决之类呀。只见老板表面上满脸堆笑，连说：好，好，我回去考虑一些。心里暗骂：妈的，还用你说呀，我坐在上头看到的问题不比你少。哪个部门不找我吐苦水呀，市场部门说什么没钱做推广呀， 技术部门说要卖新服务器，产品经理说工程师资源不够要求特批，各个运营方为要首页的推广位争得头破血流的。这么多问题，我早就焦头烂额了，你还来烦我。换句话说，老板耳朵里不是没有问题，而是问题太多了。上头不想只听到问题，更想听到这个问题你可以帮他解决。如果你说的问题，你解决不了，那你就不用去烦他了。不要让老板觉得你只把用户挂在嘴边，从来不替他这个掌握生杀大权的内部用户着想。

　　我经常能听到一个传说：说是有个某个购物网站因为改进用户购买流程，让用户不注册也能购买，为这个网站赢得了3亿美金的钱（这个故事的版本貌似很多，如有类似经历者，可以不去纠结于这个例子）。我也最近看到有网友（finger）写的《用户体验——真实的贡献还是洗脑运动？》中提到了这个例子。finger认为那个网站的用户数大，所以放大了改进的效果。我部分同意这个观点。因为事情还有另外一个方面。这个网站的庞大用户基数和规模，放大的不仅仅是用体验设计改进的效果，还放大了用户体验设计改进的成本。

　　不要以为上面提到的改进只是加一两个页面，几个按钮，若干文案的事情。网站大了自然工作流程和牵扯到的部门就多了。做这个改进可能有四个主要步骤：一、发现有这个问题，并知道问题的根源在哪里。二、把发现的问题和各个相关部门沟通，大家讨论呀、扯皮呀，在对问题的态度上取得一致（就是说大家一致或者是大多数觉得这个问题要解决）三、产品经理和设计师一起合作出各种解决方案，并最后有老板或者有权势的头拍板决定最终方案。四、最后，执行方案，开发，新改进的页面上线。这个改进要花多少钱？我们可以把项目相关各个工作人员的薪水乘以相应的工作时间求和估算出人力成本。而且开会要占用会议室，沟通要打电话，水电费（大家总要喝口水呀，沟通要写报告,ppt呀），厕所要清洁（抱歉有点扯远了）。。。。 这个改进总共要花的钱肯定不小。虽然这个改进的具体花费我不知道，不过有的公司的网站页面上要改个字体，预估仅仅人力成本就也要几千块。因此，我们可以发现网站大了用户多了，不仅放大了改进用户体验设计带来的收益，同时也放大改进用户体验设计付出的代价。一般情况下，我们在面对要改进的问题列表时，要考虑的是产出和投入比，并以此来判断改进问题的优先级。

    在我的记忆里，我总是听到那些提概念设计、传递情感的人，言必提苹果公司。确实苹果公司设计上的成功有目共睹。但是不知道，那些空谈概念设计和传递情感的人有没有读过苹果公司10多年前写得<<Macintosh Human Interface Guidelines>>。文档里说明了小到一个icon该怎么设计，设计的时候应该注意什么。没有在团队里确立一个相对统一的标准。团队里的设计师一个人一个风格，就连一个按钮的样式和文案都没统一，也没有专门的设计文档说明和记录设计思路，天天靠开会来沟通，上线了也没有人持续根据上线后的数据(就看上线后一周)。还空谈什么概念设计、传递情感……笑谈吧。

　　其实，我觉得现在企业里还是敏捷的用户体验设计比较实用（Agile User Experience Design)。大部头的用户体验流程图，在很多企业对外宣传的册子上印着，但是他们流程工作还是按照老套路。“用户体验流程图”比较适合在学校里搞研 究。相对于学校研究，企业来更看重项目时间和项目投入产出比（Return of Investment）。很少有企业愿意走“完整的用户流程图”，因为投入太大，项目时间拖得太长，而且投入产出很难预估。

　　企业中的用户体验设计，尤其是互联网公司，很多情况下，只在原有的工作流程上多了两个步骤：1）产品上线前的高保真原型的可用性测试；2）产品上线后的定 量的web analytics并配合定性用户调研. 步骤1是为了预防出现重大的问题。步骤2中Web Analytics为了分析真实的用户使用数据，而定性的用户调研是了深入地了解Web Analytics中发现问题的原因，然后为设计改进提供依据。

　　设计前期的用户调研不是每个公司都会做的。真正比较实用的是竞争对手分析(Competitor Analytics)。因为用户的需求往往都会抽象在成功的竞争对手的设计中，而他们的问题就是你的机会。这往往比前期的用户调研更省时省力，而且对于设 计的指导更直接。

　　另外，在设计过程中太多的让用户参未必就能保证产品的成功。尤其是在设计新产品时，用户很难给你意见，因为他从来没有用过。一些新产品在开始用户调研的时 候，用户都反映不错，但新产品上线后却反响平平；这大多是因为“新产品”听上去不错，但仅仅是“听”上去，实际使用就未必了。

　　我觉得比较实用的是，具体情况具体分析，在适当的时间，用适当的方法和步骤，而不是醉心于整个引入看似”精妙“和”完整“的用户体验设计流程。在做设计 中，真正能让设计师天马星空地设计的机会极少，大多数情况下，我们都是在”限制下“做设计，也就是”走钢丝“设计。这也是设计师的价值体现，在限制下解决问题，完成设计。