UED应该向产品负责，而不是向PM负责。
2009-02-19 15:36 一醉而过 阅读(500) 评论(0) 编辑 收藏 举报UED应该向产品负责，而不是向PM负责。
首先，简单阐述下一个较完整的UED团队都能做那些事情 –
可用性工程师：产品前期的用户研究、市场调研、竞品分析、环境分析，产品设计过程和后期的用户调研、易用性测试和评估等等；
数据分析师： 统计和调查数据挖掘、可行性及策略分析等；（国内现在这样的人才凤毛麟角，特别是在UED方面深入的就更是少之又少，往往是”可用性工程师”在作着这样的工作）
信息架构：产品架构设计、界面结构设计等；(往往很多地方都是交互设计师和PM分担做这部分工作，在大部分产品设计过程不规范的企业中 PM或开发工程师在作着这样的事情)
交互设计师：流程设计、各类界面交互方式设计及应用展现规范等；(这里有简单描述)
视觉设计：（不只是”美化”那么简单，这里还会包括很多品牌气质塑造已经引导用户使用情感的东西）
内容优化：优化信息传达方式，充分表现给用户完整的品牌气质，准确展现给用户在不同情景中的角色感；
界面制作：制作高保真原型，提供低成本的完整的可演示的成果展示，制作标准化的界面及应用规范等；
创意思考和文化分析： (我也在学习和挖掘中，有兴趣的人可以搜索一下相关资料)
老早以前描述过我心目中的UE，当时的描述很真实，但并不完整也有些不够通俗。
今天我想尝试用一个更通俗的方式来描述一下用户体验设计在团队中的角色，我把产品比作一个孩子有了下面的描述。
第一，UED不是保姆。
用”保姆”这个词其实一点都不重，请我们的设计师们抬头看看目前在国内这个大环境下，有多少同行不是”保姆”？
且不说架构设计了，单就交互设计和视觉设计来说这种情况甚至都非常之普遍。”用什么颜色”、”直角还是圆角”、”一个小提示的弹出和消失方式”、”某个按钮放在界面中的什么位置”、”用户添加和编辑个人资料的流程”等等等等，类似这些最最基础的问题往往都被产品管理者保持和控制着，连这种细节的设计都不是设计师能发挥自己专业地方！
那么，到底是谁在设计？ 不是设计师们！是你的老板、你们的PM…
设计师往往只是产品管理者的小保姆，第一个职能就是帮他们实现他们不会实现的效果，第二个职能就是帮他们美化一下已经被他们折腾的没法设计的界面，第三个职能是设计出N套方案让他们去挑选，最后一个职能就是当产品被用户说界面很垃圾时替他们背背黑锅….
经常有设计师在我这里发牢骚，说他们做的很郁闷，不仅丝毫没有发挥自己设计才能的地方还常常被人说做出来的东西很垃圾，我一般这样回答他们：
1、无论怎样，设计不好都不能算你一个人的错，所有产品相关的人都有义务参与到设计中并承担责任。一个产品的用户体验是所有团队成员在一起协力演奏出来的，你是他们的指挥师；
2、如果你的产品管理者并没有给你这个指挥师充分的指挥权，或者过多的干涉或强制你如何设计，那么设计不好的责任承担者应该是他们；用户体验设计是一项专业而又细致和充满丰富创意的工作，用户体验设计师不是”用户体验制作师”，他们更不是任何人的保姆。
3、在设计之前你的产品管理者是否让你完整了解产品思路、产品方向以及产品所需要表现的感觉和气质？ 如果没有，那么不好的设计结果是他们造成的，不是你。
很多设计师就是在这种环境中去作设计的，他们甚至在设计完成之后都不明白自己为什么设计，设计的是什么…
4、当给需求的人已经确定需要N套设计方案才能确定最终设计时，他已经把设计师当作廉价的劳动了，那么设计不好是很自然的事情。 这不是设计师们的责任，是没有给好需求的人全责。
如果你的团队也在这种情况，那么作为UED的你有如下几个选择：
1、向他们还有你的老大们表现出来你的成绩，让他们明白在你专业的领域他们不比你强，让他们明白谁该干什么；
2、当他们说”你多设计几套出来看看”时，你告诉他们”你不给我把产品解释明白，我一套也设计不出来”
3、如果上两个步实在无效，那么你可以请他们自己去找外包公司作他们的保姆或者你教会他们用PHOTOSHP…
4、如果情况还是没有改善，你也不想在那个地方混日子，那么你可以去做些更有意义的事情。在一个企业只要尽心在做事情你就对得起一切，用户体验设计的范围很广，除了具体表现层的设计之外还有很多事情你可以去做；
5、如果这一切都不行，那就尽早离开那个地方，因为那里不会有前途，而且你也需要找到发挥自己的空间。
第二，如果PM是父母，那么UED应该是老师。
产品是一个孩子，孩子需要学习钢琴、舞蹈、体验还是绘画，需要父母做主；如何教会教好 需要老师的专业教导。
如果父母不告诉老师他需要让孩子学钢琴还是绘画，就让老师去教，那是做父母的失职，同时也在耽误老师和孩子；
也许有很多父母自己会弹一些钢琴，往往他们会在确定了需要让孩子学习钢琴后，还自以为是的指挥老师：”先教’莫斯科夫斯基练习曲’然后再教’小奏鸣曲’”，那么最后孩子是被父母耽误的。
如果老师教给了孩子专业的弹奏方法，回到家后父母又教给孩子另外的弹奏方法，然后让孩子用自己教的方法不要用老师方法，那么这个父母最终会毁掉孩子。
家长应该做好自己的事，并有义务帮助老师做一些教育的事，但绝不是指挥老师如何教。
家长在确定让孩子学什么之前要通过老师的指导和帮助，因为老师可以从自己专业的角度判断孩子是否适合学习什么，家长往往并不具备这种专业能力。
“用户需要什么”"品牌需要什么”"技术能做到什么”基本确定了产品的设计。
PM有权利也有责任去确保产品的设计方向。 产品思路、策略等等都需要他们付出很多辛勤的工作。
作为一个产品设计团队的成员，UED需要努力遵循并保证产品的思路和方向；同时PM也有责任向UED清楚地说明方向和思路(没有人可以蒙着眼睛去打仗，设计师更是如此)。
“如何做UE设计”和”为什么如此设计”都是很专业的事情，时间和精力不允许的时候UED甚至无需向其他部门解释。
但其他部门如果需要改动这些设计，必须要向UED部门解释清楚为什么要改动，而且已经需要UED同意后才能去改动。不能说不需要设计师去设计就在丝毫不知会设计师的情况下改动设计。这是协作的基本原则，也是做人的基本原则。
可现在很多情况恰恰相反：产品管理者很多时候不向UED说明他们要求UED必须如何设计(这里甚至包括很小的设计细节，比如圆角和直角)的原因，UED反倒必须向他们非常非常详细的解释自己为什么要如何设计 才可能被他们考虑是否采纳”意见”，更有甚者当PM改动UED的设计师根本丝毫不给UE打任何的招呼。
这是一个本末倒置的恶劣现象，最终的结果往往就是”专业的人做不了专业的事情，不专业的人在指挥着专业的人使他们业余的做事”。
很多企业的PM(特别是互联网公司)都是产品的高级用户，他们很自信(甚至自负)，凭借着经验和自己的理解往往他们认为自己在UED上的能力很强，很多时候他们自己在完成UED的工作；
如果一个孩子有太多的父母却只有一个老师，那孩子的未来是让人担忧的；如果一个孩子有一双父母，有四个以上的老师那才是合理的。 四个PM加上一个UED组成的团队是不合理的，合理的组合应该是一个PM加上四个UED组成的团队。
很多企业的PM其实做的根本不是PM的事情，他们在做着使用流程的设计和界面结构布局的设计等交互设计师的工作；其实他们不应该叫做PM，而应该改叫UED。
所以，看看你的团队是不是也是有很多冒牌的PM？
当然，职位叫什么不重要，重要的是如果他们在做着体验设计的工作 那么他们就需要尊重并学习UED的思维和方法，而不是用PM的思维方法作UED的事情。
就像上面比喻家长有义务参与教育孩子一样，PM在完成自己本质工作以后有义务帮助UED做一些设计的工作支持。但得记住：在UED领域UE才是指挥师。
第三，UED不只是老师，UED应该向产品负责而不是PM。
我父亲在希望小学工作，以前有很多学生的家长经常因为家里困难就让孩子旷课在家干活，很多甚至让孩子早早辍学除外打工，特别是春节的时候有些家长为了带着孩子去走亲戚而不让他们去学校上课。
父亲经常苦口婆心的找去孩子家里 给他的父母讲道理，帮他们解决问题或者让得到更多希望工程的帮助。
以前我看到他那么吃力不讨好的时候经常会说”管他们干嘛，他们害的是自己的孩子，俺兄弟俩你都没时间管呢…”
父亲说：”老师向孩子负责，而不是像家长负责”。
也许老师永远都无法真正向孩子负责，他可能永远都没有决定让不让孩子上学的权利，因为他不是孩子的父母。
所以父亲有时会眼睁睁的看着很多孩子被父母早早送出去打工，最后因为没有上学后悔终生。他却没有真正有效的办法阻止。
其实那些父母真的可怜到必须让孩子打工才能生存吗？ 不！ 没有过不去的路，只是他们不想去过而已。 (有人可能不相信有父母会这样，事实确实如此。 很多家庭并没有穷的那么可怕，只是他们的父母太愚昧。)
但，
UED不只是产品的老师，UED也是产品的父母，产品的决策不是只有PM说了算。
UED同样要对产品负责，而不是对PM负责。
作为一个产品设计团队，其中的任何角色随时都可能是项目经理；
往往PM认为只有自己最懂产品，最知道产品需要什么的时候，就好像那些认为自己孩子需要早些打工挣钱，无须把9年义务教育上完的家长们一样，他们是在摧毁自己的孩子。
在现实中老师们有时无法改变孩子的命运，但在产品的设计过程中UED应该有义务也有权利去促进产品的优良运转。
我希望在生活中父亲没有做到的事情我能在产品设计中做到，我会像父亲一样用毕生精力去努力。
也希望所有的同行都不要只做老师，我们需要有对产品负责的态度，如果只是为了完成设计而设计，那么将来的你只会越来越没有价值…
最后：
UED是要从产品设计的开始就贯穿进去的；UED不是一个只执行的部门，UED需要对产品负责；所有人都有责任去做UED，但不是所有人都有权利决定UED；四个UED加一个PM比四个PM加一个UED要更合理； …
转载请注明出自UCDChina.com，谢谢。
