登录 |

打印 | 字体大小: « 关于新BLOG的几个变化,和提请大家注意的地方近日阅读 »

不是只有UE部门才能\才应该做UE设计


1、最近有不少非UE设计的朋友(多是IT企业的职业经理人)找我聊天,意在咨询一些关于UE部门建设和产品UE设计的一些情况。言谈之中经常可以听到这样一句话:
我们公司的设计部门很弱人手也比较少,所以我们的产品在设计方面比较差,也根本没有什么很好的易用性,现在这方面的人才很难找呀…

2、于是我不断的给他们反驳回去:我不完全赞成你们的说法。 产品设计差易用性差确实跟设计人员有关系,而且有直接的关系;但并不是说所有的责任都在于你们的设计部门弱! 一个产品的UE设计工作不只是UE部门要做,不是只有设计部门才能去做UE设计。  你们的PM和RD甚至包括客服部门一样应该承担产品设计不好的责任,也有义务一起去改进!

3、我们经常看到不少优秀的产品设计出来,但这些优秀的产品设计的背后不一定都有一个很庞大的专业设计部门。
zhuaxia、douban、甚至一两年以前的baidu、google他们都没有什么像样的UED部门,但他们的用户体验做的非常好。

4、(杭州的时候)在计算机世界报专访中我这样说过:
可用性应该只能算是一个新的词或者新的工种,并非是一个新的理念或概念。
实际上在很早以前我们一开始做网站设计、产品设计的时候就在搞可用性相关的工作, 只是那个时候我们没有专门安排一个职位或者部门叫做‘可用性工程师’而已!
不是只有叫做‘可用性工程师’的人才能去做可用性,也不是只有‘可用性工程师’才应该去做可用性。
我们有很多的PM、软件工程师在可用性方面都具备着很强的能力,比如baidu的绝大部分PM基本上都可以拉出来做一个很好的交互设计师,因为他们具备着很强的交互设计能力。
所以我们现在其实是在把工作做的更精细、更符合用户而已,而非“提出了一个新的概念”。

5、在这个要求高质量无缝协作的年代。无论是什么部门或什么角色在主导项目,沟通永远都应该是第一位的。
各个角色之间的共同语言是沟通的基础,RD(技术)不应该只懂代码、PM(产品经理)不应该只懂产品和市场、UE也不应该只懂用户体验…
一个好的团队应该是项目补充的。UE更多是站在用户角度、PM是市场和企业品牌体系的角度、RD是技术;三个角色的协作非常重要, 互相的共同语言和思路需要协调一致。
每个角色在自己的角度上一定还需要具备其他角色的能力,不然一定会出问题。
大家是冲着一个目标的团队,要做的是互相帮助着冲向目标. 而绝非各自完成任务!

6、一个团队就像一个联合国,在联合国的大会上如果每个国家的代表都只会自己国家的语言,这个会就不可能开成功!            

7、所以,我认为:一个产品的用户体验设计应该:有UE部门主导、多个部门一起努力

8、
在说“我们不只是美工”的同时一样要意识到“程序员也不只是写代码的”!       

分类:UCD ,06/12/04 6:56 PM | 28,307 Views |

网友评论(30)

  1. 赞同!^_^重视UE要成为产品队伍里所有人都要有的思维方式和习惯。UE部门只不过更专注于此。

  2. 呃。。。
    联合国大会不需要与会代表懂多国语言。有现场即时翻译
    除了这个比喻不太恰当,其他都赞成

  3. 比较同意。

  4. 很有道理

  5. 同意~UE工作在我们现行开发的项目中都是由我们UI组提出,需求组和demo组、开发组还有测试组一起进行大会讨论的,这也是我们UI组成立后在公司烧的一把小火,而且大家似乎都很感兴趣呢~呵呵

  6. 说得是挺有道理的.
    UE,PM,RD应如何配合呢?即负责哪些工作?如何分工?
    我想这些问题应该是大家最关注的..

  7. 赞同

  8. 问几个问题:
    1产品经理除了根据市场需求制定出产品需求外,还需要做的工作是?他需要分析数据库结构,服务器等技术性很强的东西吗?
    2整个产品开发过程需要哪些岗位,他们的具体工作职责和工作流程是?

  9. to gogo:

    你的问题N多人问过, 但我无法给你确定答案。  每个企业应该有自己不同的标准, 我想应该没有人能能够给你通行的答案…
    最近很忙,如果有时间我会把我的相关想法写出来。

  10. 很有理。。。

  11. UE,现在叫UX,应该说这是一种理念,一种渗透进IT人士血液中的理念,期待中……

  12. […] 8、我经常给PM阐述:(作为一个UE设计师大多数情况下也必须有这样的心态..) UE坚持必须要从用户的了解做起,从交互设计作起,其实并非是因为我们认为我们的交互设计作的不好(很多时候PM也能把产品的交互设计作的很好)。 我们要做用户研究要做交互设计更多时候其实质是为了更加了解产品的需求、了解产品的整体概念思路,因为这里了解和吃透了这些我们后面的UI设计才能更有灵魂更有思想,才能不致于”行尸走肉”… […]

  13. 一个产品的用户体验设计应该:有UE部门主导、多个部门一起努力。

    非常同意!

  14. […] 1. Web Developer可以做得更多 2. Web2.0时代的搜索 3. 产品设计中可能需要注意的十个细节 4. 东拉西扯:Vista来了 5. 东拉西扯:反商业作为一种商业 6. 改变未来IT业发展的趋势 7. 不是只有UE部门才能才应该做UE设计 […]

  15. 非常的赞成 其实UE是一个企业对可用性本身的关注度相关的

  16. […] 经常有设计师在我这里发牢骚,说他们做的很郁闷,不仅丝毫没有发挥自己设计才能的地方还常常被人说做出来的东西很垃圾,我一般这样回答他们: 1、无论怎样,设计不好都不能算你一个人的错,所有产品相关的人都有义务参与到设计中并承担责任。一个产品的用户体验是所有团队成员在一起协力演奏出来的,你是他们的指挥师; 2、如果你的产品管理者并没有给你这个指挥师充分的指挥权,或者过多的干涉或强制你如何设计,那么设计不好的责任承担者应该是他们;用户体验设计是一项专业而又细致和充满丰富创意的工作,用户体验设计师不是”用户体验制作师”,他们更不是任何人的保姆。 3、在设计之前你的产品管理者是否让你完整了解产品思路、产品方向以及产品所需要表现的感觉和气质? 如果没有,那么不好的设计结果是他们造成的,不是你。 很多设计师就是在这种环境中去作设计的,他们甚至在设计完成之后都不明白自己为什么设计,设计的是什么… 4、当给需求的人已经确定需要N套设计方案才能确定最终设计时,他已经把设计师当作廉价的劳动了,那么设计不好是很自然的事情。 这不是设计师们的责任,是没有给好需求的人全责。 […]

  17. […] 经常有设计师在我这里发牢骚,说他们做的很郁闷,不仅丝毫没有发挥自己设计才能的地方还常常被人说做出来的东西很垃圾,我一般这样回答他们: 1、无论怎样,设计不好都不能算你一个人的错,所有产品相关的人都有义务参与到设计中并承担责任。一个产品的用户体验是所有团队成员在一起协力演奏出来的,你是他们的指挥师; 2、如果你的产品管理者并没有给你这个指挥师充分的指挥权,或者过多的干涉或强制你如何设计,那么设计不好的责任承担者应该是他们;用户体验设计是一项专业而又细致和充满丰富创意的工作,用户体验设计师不是”用户体验制作师”,他们更不是任何人的保姆。 3、在设计之前你的产品管理者是否让你完整了解产品思路、产品方向以及产品所需要表现的感觉和气质? 如果没有,那么不好的设计结果是他们造成的,不是你。 很多设计师就是在这种环境中去作设计的,他们甚至在设计完成之后都不明白自己为什么设计,设计的是什么… 4、当给需求的人已经确定需要N套设计方案才能确定最终设计时,他已经把设计师当作廉价的劳动了,那么设计不好是很自然的事情。 这不是设计师们的责任,是没有给好需求的人全责。 […]

  18. 好文,受教了!多谢!

  19. 大家都在讲UE设计师的重要性,那么UI设计师有改如何定位自己的位置呢?

  20. […] 经常有设计师在我这里发牢骚,说他们做的很郁闷,不仅丝毫没有发挥自己设计才能的地方还常常被人说做出来的东西很垃圾,我一般这样回答他们:1、无论怎样,设计不好都不能算你一个人的错,所有产品相关的人都有义务参与到设计中并承担责任。一个产品的用户体验是所有团队成员在一起协力演奏出来的,你是他们的指挥师;2、如果你的产品管理者并没有给你这个指挥师充分的指挥权,或者过多的干涉或强制你如何设计,那么设计不好的责任承担者应该是他们;用户体验设计是一项专业而又细致和充满丰富创意的工作,用户体验设计师不是”用户体验制作师”,他们更不是任何人的保姆。3、在设计之前你的产品管理者是否让你完整了解产品思路、产品方向以及产品所需要表现的感觉和气质? 如果没有,那么不好的设计结果是他们造成的,不是你。很多设计师就是在这种环境中去作设计的,他们甚至在设计完成之后都不明白自己为什么设计,设计的是什么…4、当给需求的人已经确定需要N套设计方案才能确定最终设计时,他已经把设计师当作廉价的劳动了,那么设计不好是很自然的事情。 这不是设计师们的责任,是没有给好需求的人全责。 […]

  21. 看了您的文章受益匪浅。
    我是一个PM,也犯过您在‘UED应该向产品负责而不是向PM负责’的文章里提到的错误,自己忍不住做了很多交互设计的工作。我说一下自己对PM和UE设计在产品设计工作上的理解以及我的疑惑,欢迎拍砖和提出建议。

    PM应该是提出用户的需求,而UE设计的工作是帮助用户在实现其目的时的交互任务的设计。但是这中间也存在模糊地带,比如哪些是属于需求,而哪些是属于任务?比如我在做用户调研后发现,多数用户希望某功能放置在页面左上方,而UE却认为应该在右边。如果我坚持应该在左边,UE就会认为限制了他们的发挥。我想有时候UE设计的抱怨也来源于此。如何调和这样类型的矛盾?

    另外我认为产品的定义是PM的核心工作,而有的UE的管理者也经常参与到产品定义的工作中去,而且直接对产品的定义提出异议,这本身也给产品的定义工作带来阻力。所以我很想弄明白PM在产品设计应该做到什么样的程度,而UE设计师又应该在产品定义中扮演什么样的角色?

  22. […] 8、我经常给PM们阐述:(作为一个UE设计师大多数情况下也必须有这样的心态..) UE坚持必须要从已开始就介入项目中去,从用户的了解做起、从基础交互作起,其实并非是因为UE认为我们现在的交互设计不好(很多时候PM也能把产品的交互设计作的很好)! 我们要做用户研究要做交互设计更多时候其实质是为了更加了解产品的需求、了解产品的整体概念思路,因为了解和吃透了这些我们后面的UI设计才能更有灵魂更有思想,才能不致于”行尸走肉”. […]

  23. 我觉得第二个白鸦就快蛋生了,那就是我,哈哈

  24. 我们公司的设计部门很弱人手也比较少,所以我们的产品在设计方面比较差,也根本没有什么很好的易用性,现在这方面的人才很难找呀…

  25. 受教,学习中

  26. 这篇文章非常好!主旨谈到的是研发团队管理的问题。

    事实上,团队配合不通畅的问题不仅仅存在于UED设计这个环节中,事实上是贯穿于整个项目的研发过程中。请问大家,需求分析是不是一个人的事情?软件质量是不是仅仅是测试人员的事情?项目的成败是仅仅研发团队的责任或者销售人员的责任吗?不是的,是所有人必须承担的责任,不管你愿不愿意承认。放到任何一个公司都是如此。

    追根溯源,本质上这是个管理的问题,即什么时候应该分工才不至于破坏原有的合作关系。我的答案是,如果分工后无法合作,不如不分工。白鸦的观点“由UE部门主导、多个部门一起努力”的想法是好的,但是能否执行得了才是关键。

    从经济发展规律来看,任何公司在初创期都是混沌状态,不成熟意味着没有那么多的分工。为了生存,遇到问题时大家一起上,先解决问题再说,所以大家觉得很团结。而事实上,这是因为牵涉到每个人的利益的缘故。因此,我认为对于小公司,管理者更多的应该强调合作文化、创业文化,而不是制度上的奖惩。道理很简单,皮之不存毛将焉附,公司的生存才是首要的。这方面,我特别喜欢一个朋友的管理哲学,他说”对于创业的人,根本不需要管理,因为我把梦想都给你了,你还要什么?!”

    然而,当公司进入发展阶段时,为了规模化(这是做大的必要条件之一)不得不进行岗位细分,不得不建立标准化工作流程,否则几十个人、几百个、几千人如何协同工作?当公司扩大,业务量增加后,每个员工并行工作的可能性会大大增加,这时岗位专业化是十分必要的,因为专业化可以提高效率。记住,效率和成本是管理者最问题的两个。如果分工无法提高生产效率、降低成本,那么管理者一定不会采纳分工,要做好这种变革,在我看来至少要具备三个基本条件:人员足够专业化、流程能够确实起到协同的效果、公司不断强调合作的文化。做到这一点,谈何容易!我们做技术的朋友切忌避免将问题简单化,否则不会有那么多大型公司会聘请咨询公司来给自己企业看病了。

    “由UE部门主导、多个部门一起努力”的思想是每个项目应该有一个人总负责,这个人可以是项目经理,也可以是产品经理。可是,这个人必须具备很强的沟通协调能力和专业能力,这种人才需要时间来培养,我们需要时间和耐心。

  27. […] 来源 […]

  28. 确实是不应该只有UE部门去做相关的事。问题是,各个部门的分工如何界定。无缝协作当然好,可是无缝过了头,就是重叠了,重叠之后就是分工不明确,大家都去做,最后大家都无法做。我的一个观点是,适当的分工是协作的基础。公司上了规模,人一多起来,大家一起去做一件事情只会导致混沌。所以,我更想听到的是鸦总讲讲如何在你的这种理念下各部门的协调和沟通,如何分工协作,各自的角色,具体一些。
    还有,UED部门主导在公司是否能够实现?能够执行下去?如何执行?我们当然希望是UED部门去主导,但是各部门都有自己的想法和理由。

  29. […] 从UCD到UCS 本来打算再翻译篇手机OS市场分析的文章,被一哥们说你丫Blog名字还叫Rayistihnking呢,天天翻译你Thinking个毛,就是不动脑筋偷懒。哎,其实一点都没偷懒,我这半吊子英文水平每天翻译都是吭哧吭哧费劲大发了,比自己写一篇难多了。不过都被这么说了,还是自己来写吧,当然翻译还是得继续,就当我自己学E文写作业了(爱看不看,咱自娱自乐)。这个标题有装×之嫌,不过人在IT哪能不装×,只是少装多装而已,那个啥洗洗更健康,咱们就装装更快乐嘛。前段时间我整理Google Reader时,把有关UE/UI/IxD的三十多个博客全部退订掉,只保留了UCDchina,为什么?一个是越来越多实在是快看不完了(我有强迫症,不管多晚每天必须看完所有订阅),还有一个原因就是:我不能老是在“D”这里打转了。毕竟,我不是交互设计师,也不会再去转行做UI了。开始说正题,用户体验在神州大地茁壮成长,这几年估计也是听的耳边都磨出茧子来了。我不知道其他人是怎么知道这个名词的,反正俺是当初看白鸦博客才明白这些,后来知道有UCDchina后简直是欣喜若狂,06年那时候经常是通宵泡在上面一篇不拉的看下去(看懂看不懂是另一回事,哈),觉得用户体验好的网站简直是天下无敌,不是吗?看看GG,看看Flickr,再看看Facebook,看看人家那页面设计的,看看人家那流程,看看人家那。。。。。。前几天我在做一个网站的优化方案,因为对整个网站业务不是很熟悉就先提了一些UI和交互性的问题,没有敢深入进去动架构。后来开会时用这个PPT做讲解的时候,感觉好像大家有这样一种想法存在:只要把这些问题修掉,优化界面和流程,就行啦,那我们就是一个以用户为中心的站点,为用户提供良好的用户体验,没有理由不成功了。可是同志们,我们做互联网产品的人大多数都是看着UCDchina和油茶会(挂了?)这类站点熏出来的,我们太在意UI和交互了,我们有时甚至会恍惚觉得这就是用户体验的全部。不,绝对不是!在写这篇日志之前,我依稀记得白鸦当初在Blog里提过这个,于是搜索了一下,不但找到了他当初的想法,还看到了一个争论。用户体验确实不应该是一个部门的事情,更不应该把这个责任压到设计师头上来,非常不应该的是:一个网站,一个互联网公司,不能仅仅满足于以用户为中心的设计(User Centered Design),而应该致力于去创造以用户为中心的服务(User Centered Service)!我在隐形冠军系列中写到Akamai时,说到eBay当年的当机和淘宝上次的改版。很巧的是,今天写这篇时,昨晚淘宝首页又出了点小毛病,咱不知道原因就不乱猜,但是肯定的一点是:那段时间正在登陆的用户是不爽了。访问速度是用户体验的一部分,系统稳定性自然也是,还有,品牌呢?一天到晚在各大门户和传统媒体上有某个网站的负面报道,一说给朋友听这个网站不错人家立马说那站点整天被曝光垃圾站一个有什么好上的。。。。。同志们,咱们是从业者,咱们说起每个站点的背景故事都是如数家珍,我们不能对用户抱那么高的希望。从以用户为中心的设计到以用户为中心的服务,互联网公司本身就是一个服务型的公司,用户体验贯穿于网站各个部门,假如呼叫中心客服态度不好,你能怪UED?阿里B2B的Sales一天到晚的电话骚扰你(说到这个我就上火),你能怪设计师?如果你是设计师,看到这里的话我想这篇文章对你没有太大意义,抱歉浪费你的时间了,如果你和我一样是PM或者PD,那么我觉得可能会对你有一些帮助,我们的生存空间就从来没怎么舒坦过(图舒坦就别做这个),我们做原型,交互设计师们嗷嗷叫的冲过来给我们抢走了,我们定战略,老板说这公司是你开的我开的?我们做市场分析,Marketing说别搞笑了,你来做三个月的Sales试试。我们说页面用户体验不好,设计师说你来切个体验好的页面给我看看?我们说数据库不稳定,DBA说你知道什么是SQL语句吗。。。。。但是同志们,咱们还是得继续做产品,UCD是设计师们的事情,UCS才是咱们的,为用户提供好的产品和服务,只要能做出个好产品,咱就是累一点少活个几年又他妈算什么。这是我们的信仰!!!又:发现Wikipedia上居然还没有UCS这个条目,要不写一条,装到国外去 Read more from 产品设计 4 Comments Post a comment […]

  30. UE的体验设计是个循序渐进的过程,好的UE体验一定让用户感觉很舒服,自然的感觉

发表评论

*必填

*必填 (不会被公开)