PM(产品经理)和设计师的沟通

来源:百度文库 编辑:神马文学网 时间:2024/04/18 13:47:28

PM 的意思是产品经理,一般来说,岗位职责是对整个产品负责,按照职权对应的原则,往往他们对产品的权利最大,决定了产品的发展和前途,我们遇到的各种各样的 问题,大到美国总统应该谁来当,小到一个按钮的颜色是红色还是绿色,都跟他有关系。而且我们得承认,有些pm 很混蛋,左脑是面粉,右脑是水,只要想问题就会搅在一起变成浆糊,根本没法沟通,这个的确存在,世界就是因为他们的存在而变得丰富多彩嘛。

在 一个设计项目中,PM是需求方,设计师是要满足需求的,但是中间的界限不是那么清楚,以前在腾讯的时候我们喜欢说“pm和设计师是你中有我,我中有你”, 于是和pm的沟通往往是设计师最难做也最需要花时间去做的的事情。我不止一次两次听到设计师抱怨,典型的如“ 我们的产品什么都管,按钮红色绿色也都要他说了算,非常强势,他的项目我没法做。” “PM只想着赚钱,只想着快速发布,根本不在乎用户体验” ,往往设计师辛辛苦苦的完成了一个得意之作,PM一副冷脸,这里不行,那里不好,比王员外挑女婿还难搞,在面对这样的紧张的国际局势,有一些人选择了沉默 下去,算了,pm说怎么样就是怎么样吧。这样的设计师,一定不是好的设计师,我相信在座的一个都没有。我们都是相信我们的设计是好的,只是需要一些额外的 沟通和说服工作,从而让我们设计能真正的得到认可和尊重。

那么我们有什么灵丹妙药呢?锦囊妙计如下:

  • 开放的心态:别人对你的设计提了不同意见,认真的听,有则改之无则加勉。不要有护短的想法,自家的孩子自家疼,心态不开放,合作就不会愉快的了。
  • 消除信息不对等: 经常产品经理提出需求的时候会倾向于告诉设计师他想要什么,而不告诉你为什么,无意中就遗漏掉了很多信息没有传达给设计师。在座的各位作为优秀的设计师, 一定要尽可能的把这些信息挖掘出来,每次接到需求的时候,多问一句“为什么”,做到和pm 了解的信息一样充分,伟大的福特就是这样设计出来汽车的。
画外音:问:“有的信息是pm故意不告诉我的,说要保密”答:“什么?保密?那你还跟他做一个项目?趁早换吧”
  • 尽可能早的介入项目:在项目初期就尽可能早的介入,哪怕这时候产品只是一个简单抽象的概念,但是这个阶段往往最关键,最容易受到影响,经常很小的建议也都会影响到决策人的最终判断,同时很多方向性的决策会在概念的形成期完成,设计师介入了就保证了在最开始项目的战略决策上有考虑到用户体验。
  • 以退为进: 在战略上你已经和pm和管理层取得共识的前提下,在更为细节的问题上如果遇到不同意见,我们可以退回一步,到已经取得共识的层面再去看这个待解决的问题, 是谁的意见能够更好的为目的服务?如果说PM和你都同意产品主要面对的是商务用户,那么由此出发推导出界面的主色调改成草绿色不是很靠谱。
  • 从用户出发: 如果用户体验设计师是安泰俄斯,那么用户就是大地,设计师最大的力量来源于用户。一些从直接用户身上得到的证据往往能很好的支持你的观点,所以,多做一些 user study,多了解用户,某些场合下,用户使用产品时痛苦不堪的表情和接连犯错的录像,要比你千言万语来的更有说服力。
  • 建议权和决策权分开: 设计师可以对PM的市场策略提出建议,PM也可以对设计师的按钮颜色“指手画脚”,这个叫做建议权。最终一拍桌子,大吼一声“我说了算”,这个叫做决策 权。 作为项目的一员,任何人都对项目的发展有建议权。但是发表完你的高见之后,不要忘了加上一句“这是我的意见,当然最后怎么做你来决定”。建议权和决策权要 分开,不要过度涉及到别人的专业领域,既然是一个团队,对团队成员的专业能力的尊重和信任是最基本的前提。
  • 拿来主义:看看竞争对手产品怎么做的,他们一定经历过跟我们差不多痛苦的一个阶段。他们之所以这么决定,一定有理由的,要相信他们不全是傻X,想想看为什么,这个很多时候能够作为决策依据,或者是帮助我们说服别人。
  • 系统的力量: 如果你身在一个大公司,那么在你之前,一定有很多革命先驱前赴后继的在同一个问题摔过跤撞过墙,如果你足够幸运的话,公司可能在某个不为人知的服务器上还 有一个用设计师血泪凝聚而成的叫做设计规范的东西。这个东西,不一定是最好的结局方案,但是往往是在你们的环境下最可行的实践方案。没错,站在巨人的肩膀 上吧,用你们的设计规范来说服别人。
  • A/B test:什么?前面这么多办法都没效果?好 吧,杀手锏来了,A/B test,简单点来说,就是取出5%的用户作为一组,当他们访问时,给他们看方案A,剩下的用户全部是方案B,最后数据说话,哪个表现更好用哪个。这个往 往能够快速有效的消灭争论达到和谐状态。不过请注意,此武器成本较高,往往拉高成本拖长项目周期,慎用。

好吧,我非常感谢你们看完这九条,很不容易,如果你还没关掉这个网页的话,我偷偷的泄露一个终极武器,一般人我都不告诉他的,那就是:找老板去拍板。成本低见效快,绝无环境污染,实乃居家旅行杀人放火之必备良药。考虑下吧?

本文由UXday第六期靠近门口那一组同学共同贡献,请恕我不一一署名,非著名设计师 刘亚平 记录整理。  PK: 

1、引用:我们都是相信我们的设计是好的,只是需要一些额外的 沟通和说服工作,从而让我们设计能真正的得到认可和尊重。”

  我不是很同意“相信我们的设计是好的”这句话,这个有些主观了。不仅是设计,任何一个方案、策略、战略未必永远是好的,它只能是适合当前的环境。现在看十年前的设计,像包装、建筑、时尚杂志等,和现在的设计应该是不能相比的。所以,设计是解决问题的、是一定有时效性的。“我们的设计是好的”这句话只能是暂时的。另一个层面,这个“设计”有无满足需求,或在满足需求之上做了超越,是另外一个话题。

2、引用:开放的心态:别人对你的设计提了不同意见,认真的听,有则改之无则加勉。不要有护短的想法,自家的孩子自家疼,心态不开放,合作就不会愉快的了。”

  所谓的“开放心态”,从另个角度来看就是服务意识的问题,我甚至认为亚平同学提到的“开放的心态”就是被动的心态。目前在国内大多数的设计团队应该属于支持团队,在互联网这个行业,设计师或许能够引领设计潮流,但未必能让产品或业务达到最好。有一些设计师想转行做产品经理,我想可能是想做一些引领的事情。我基本上认为心态的问题等同于服务意识的问题。再换个思路,如果身在一个以设计公司,那么甲方的产品、销售、老板都是你的客户,如果没有良好的服务,这个设计公司很难活下去。因为,甲方的任何一个人都可以对你“指手画脚”,如果认为他们脑袋里面是粉、水那就麻烦了,自己做的不爽不说,单子做不下来生活就成了问题。如果客户有选择设计师的权力,那么什么样的服务就可以决定设计师的命运。欧阳黎明有讲道在为客户设计Logo提案的时候,客户的选择选择了一个较“土”的提案。这里有完整的视频,有兴趣的同学可以看完。其中为什么客户会选择一个较“土”的Logo提案,视频中欧阳有解释原因。

  我认为提高服务意识与目标导向才是设计师首先应该关注的问题,服务意识是职业人的基本素质,目标导向设计才是设计师的关注点,理解用户的目标,从而去设计适当的交互行为、视觉表现。或许关注结果比关注客户的一两句指责更重要。近期看博客的文章,我感觉现在的设计师危机意识和压力感都小。如:无运营压力,无收入压力,无销售压力,滋生了太多“抱怨”的不下于少数。PM不是傻子,PM的信息量和对市场的敏感度比设计师要高,骂PM很混蛋的,不是沟通的问题,就是服务意识的问题。但我还是认同亚平同学的“挖掘”的方式,用来找到“问题背后的问题”,去更好的解决。个人经验在进行这种“沟通”时,最好的方式是“问答法”,不直接纠正而是用另外的问题去引导PM,最终在相互讨论的过程中产生正确的方案。

3、引用:画外音:问:“有的信息是pm故意不告诉我的,说要保密”     答:“什么?保密?那你还跟他做一个项目?趁早换吧” "

  画外音很有意思。有人经常和你说他的个人的事情,说明他信任你,当他或其它人不和你说的时候,一定是信任出了问题。设计师应学会和各种人沟通,没有什么比“朋友”之间的信任更重要了,中国人有酒文化,在我看来,就是在做信任关系。这个做好了,我想除了真正“保密”的事情,PM应该是知无不言了。

4、引用:尽可能早的介入项目:在项目初期就尽可能早的介入,哪怕这时候产品只是一个简单抽象的概念,但是这个阶段往往最关键,最容易受到影响,经常很小的建议也都会影响到决策人的最终判断,同时很多方向性的决策会在概念的形成期完成,设计师介入了就保证了在最开始项目的战略决策上有考虑到用户体验。”

  关于设计师尽可能早的介入项目,我个人倾向于有一个项目经理的角色介入整个项目。这方面国外比较强,还有正式的PMP考试。如果每个项目能有一个项目经理,由项目经理来统筹安排,这个项目成功应该又往前进了一步。关键问题是要把设计师和产品经理绑在一起,这个是组织架构的问题,纵横的架构在这里说起来还是有很多好处。

5、引用:从用户出发: 如果用户体验设计师是安泰俄斯,那么用户就是大地,设计师最大的力量来源于用户。一些从直接用户身上得到的证据往往能很好的支持你的观点,所以,多做一些 user study,多了解用户,某些场合下,用户使用产品时痛苦不堪的表情和接连犯错的录像,要比你千言万语来的更有说服力。”

  对“从用户出发的看法”,现在我也有另外的一些看法。关于从用户操作上反馈出来的问题,要分两个维度去看。如果是UI端的问题,那设计师和相关的同事就要去改;如果是产品的问题,那就要看产品思路是不是正确的。设计是有义务去设计产品逻辑,如果说用户走不通,那PM和设计师都有责任。互联网的产品形态是多变的,大部份的时候是来不及做User Study的,我不觉得这种方法适合互联网上的所有项目。重要的产品可能才需要做这些研究,如A/B test这个方法,是要花费资源的,同时还有统计的问题。提倡敏捷开发实际上来看,是和A/Btest在意义上是一样的。都是为了快速发布后通过线上互动来验证产品上的方向性,从而再来调整设计。如果说设计师说产品的特性不好(最典型的是强制弹出框),设计师未必把用户端的观点搬出来,因为用户都没有用,提的观点就会处于想象中。互联网产品中,是需要更快速的研究方案,一些用户端的考虑方式和产品端的策略是相互矛盾的,我认同从用户端习惯、从设计前瞻性的角度给到产品意见,而不是连用户都没有用过,就把UCD的观点抬出来,未必和产品的方向相一致。

6、引用:系统的力量: 如果你身在一个大公司,那么在你之前,一定有很多革命先驱前赴后继的在同一个问题摔过跤撞过墙,如果你足够幸运的话,公司可能在某个不为人知的服务器上还 有一个用设计师血泪凝聚而成的叫做设计规范的东西。这个东西,不一定是最好的结局方案,但是往往是在你们的环境下最可行的实践方案。没错,站在巨人的肩膀 上吧,用你们的设计规范来说服别人。”

  关于“系统的力量”。我做过一些规范,感觉目前的规范缺乏“戴明环”,说白了就是做完了不改进了。比如先前有经验说一个网页的色彩最好不要超过三种,时过境迁,现在能遵循这条的不知道能有多少。规范也是一个项目,也是一个质量管理的过程。和记英文单词一样,你只有不断反复、不断循环才能记忆成功。规范只能是一段时期内的要求,一旦有业务发生变化时,规范就应该随之而适当调整,久而久之才能够。年前和Paulfu沟通的时候,他认为规范不应变的太快,我想有一定的道理,但前提是规范要足够的丰满和完善才可以达到。