设计与沟通 - UCD大社区

即兴与设计——如何进行有效的设计沟通

范忱 — 2010-04-14 11:26:48

Jazz是门很奇妙的艺术，尤其是音乐家们即兴创作时互相激发、灵感四溢，一气呵成，酣畅之至。这种状态，恐怕也是各位设计师渴望的境界。如果你发现自己整天陷于琐碎的细节与无谓的争吵时，不妨尝试“即兴创作”的沟通与创作方法。

Liz Danzico在一篇文章里提炼过几点Jazz即兴创作的特点，且看这些特点如何能用在设计过程中（其中“练习沟通”和“加点魔法”是我加入的原则）：

集中精神，聆听
在台上最重要的一点是，聆听你的伙伴，任何一个音符或律动都可能成为下一段的动机。同样，在设计沟通的过程中，不能对同伴的任何一句发言掉以轻心。
2009年，在交互设计协会于纽约举办的讲座中，Steve Portigal建议，在沟通中给予足够的安静，允许对方“speak in paragraphs instead of a sentence”。
练习沟通
这里讲的是自我修炼，而不是彼此磨合（最初的Jazz即兴演出，也是在几个彼此并不相识的音乐家间进行的）。研究表明，所谓天才，至少要10000小时的努力。正因为音乐家数十年苦练，才造就了他们在台上的精妙配合与如诗妙章。在设计与沟通中，仅仅脑中充满奇思妙想是绝对不够的，如何发言表达出自己的看法同等重要。你要做的不是说服，而是启发与共鸣。如何达到这一境界？从现在起练习。
互相支持
在演出中，无论对方奏出了多烂的旋律，音乐家要做的都是——彼此支持。一损俱损，一荣俱荣。因此，在设计沟通中，如果任何一个建议没有得到回应，就会像乐曲中没有支持的旋律，造成残缺的感觉。
“我同意，而且……”
这句话是即兴创作的根本。除非是按照特定的对话（比如贝九第四乐章开头）进行创作，音乐家要做的首先是肯定对方的旋律，并且相应，加强，共鸣；而不是说“不”。
在Pixar，这种方式被称为“Plus-ing”。Pixar的Randy Nelson说到，这不是评论或者说“这不错，我怎么能让他变得更好”，而是“我就从这里出发，接下来怎么做呢？（Here’s where I’m starting. What can I do with this?）”
下台后再说
音乐家绝对不会在台上互相指责或反思，一切，等台下再说。在头脑风暴的原则中，叫做“推迟评价”（withhold judgement）
加点魔法
以我的经验，在即兴演出中，脑子里只有一个大概朦胧的影子，很少会去想到具体如何弹奏，如何进行和弦配置，一切都是到时候自然的流淌出来的。这一点跟Alan Cooper在他的研讨班中提到的“魔法法则”有一点相像，他建议，一旦确立了目标，不妨放弃对技术细节的考虑，而是假设有一个魔法师帮助你实现目标，比如说“将数码相机里的图片导入电脑”这个操作，就可以抛弃“取出SD卡，插入到转换头”里的细节。

团队合作和跨领域合作一直是美国设计界的重要方法。如同现在科研界的趋势一样，单凭设计师单枪匹马引领风潮的时代可能即将过去。摆脱“你们不懂设计”、“这是我的专业“的思维，学会团队合作将是设计师面临的挑战之一。同时对于设计团队的其他成员（如产品经理、研发工程师），如何进行高效沟通也将越来越重要。

当下次讨论即将陷入僵局后，你可以建议：”换个思路，来即兴一下吧“！

相关话题：设计与沟通源地址：http://www.lanrenux.com/?p=400

精致的web设计

jonathonwong@yahoo.cn(折折熊) — 2009-11-24 21:54:40

工作中遇到一个很棘手的问题，交互设计师和视觉设计师在做出高保真原型后提交给前端开发工程师，最后得到的web产物从细节上和布局上都和高保真原型有所差距，比如应该有鼠标手型的地方没有鼠标手型，导致用户不知道这个可点，又或者一行文字上下高低参差不齐，看起来就很廉价没有品质感。导致交互和视觉不得不放下手中的工作去一一核对这些问题，并指出给前端开发工程师让其改正，最后发现其实这些问题都可以迅速的做好，那为什么前端开发却不愿意在一开始的时候就做好这些工作？

从几方面来看待这个问题：

1.过细的专业消磨掉“默契”。相信大部分有一定互联网经验的人都是做过前端开发工程师，在那个年代从设计到开发都是同一个人，所以完成的东西往往和预期的符合度比较高。因为在做前端开发的时候自己心里知道哪些地方应该加粗，哪些地方应该有间距，哪些地方应该让用户更突出地看到。但是现在大家分工越来越细，每个工种的能力也越来越专业化，所以导致了原来的那种“默契”也越来越消失掉。前端想要做的就是写出牛B的代码，最好是能够超越google产品的技术水平。但是往往越专业就越偏离真正做产品的目的。之前一次讨论中，一位前端同事说对他们来讲，代码的整齐比用户看到的页面整齐更加重要。我不反对代码整齐的确体现了前端的专业性，但是换句话讲代码整齐是前端的基础，对前端的要求是不管用户看到的页面有多复杂，有多绚丽，你们的代码还是依然要那么整齐，这才是最牛B的。

2.等待中的沟通。项目中为了能够保证质量，通常都会用产物传递的方式来帮助每个角色的沟通。我也一直“致力于”制定和update各式各样的规范，但是我发现，无论你的产物多详尽，总会在传递过程中消耗一部分，导致后端的角色无法完整真正理解你的初衷。幸好在传递的过程中增加了会议沟通的形式，但是一个会议让所有人能够理解并且提出建议是不大可能的。那除了产物传递和会议以外，我们还能做什么？我们需要的是主动沟通。工作中有句话，能够用IM的，绝不用邮件，能够用电话的，绝不用IM，能够当面沟通的，绝不用电话。这就是最好的沟通方式，当然经验告诉我们，每次沟通完之后，必须用邮件抄送所有人来做个沟通记录，以免大家事情太多最后忘掉。但是沟通又会引发一个问题，前端、视觉往往是等着交互和需求方去找他们沟通，也就是后置角色一直都是等着前置角色来找他们沟通，其实这个是错的。所谓的沟通是相互的，不要等！当后置角色发现问题时应该主动及时地找到对应的前置角色去把问题解决了，这样的方式一定可以把那些疑惑和不确定都弥补掉。

3.不够统一的产品思想。在每个专业角色的领域大家都在说往前走，意思就是不要停留在技术层面，要往前往远看。从后台一直到产品规划，大家都有往前进的趋势。当然这和社会的现状有关，往往代码工程师会羡慕前面的设计师甚至是需求方，只要口头说说，他们就要做很多工作，谁都希望做上游。我不反对往前走，但是我希望大家能够摆清定位，所谓的往前走是希望每个角色的思想是统一的，不仅能够有出色的专业能力，而且能够站在更高的角度去看产品，并把自己的专业能力反应在产品上。现在大多数人都在嚷着说我们要往前走，要去挑战上游的专业能力，但是我想问问这些人，你们自己的专业能力够出色了么？如果连最基本的web可用性都没注意起来（例如鼠标手型表示可点击，元素间的对齐，大区域指示有助于用户找到目标等），你们怎么可能往前走，怎么可能把自己的专业能力应用地更出色。

4.没有规划的技术。所谓规划，大家都会想到产品前期的市场调研，其实每个角色都应该对自己的工作进行规划。我经常遇到问题是，当前端开发工程师完成的产物没有达到设计师的要求时，前端开发总会说这个什么dom结构、什么js本身都不支持等等，甚至有时候需要优化和升级的时候才发现，前端把代码写死了，根本不可能有优化，只能重写。面对这些问题时，应该两个解决办法，一个是在做之前主动找上游沟通整个产品的方向和目标，并把它落实在技术中，预留好接口和开放结构，从而使升级优化成为可能。另外一个是认真仔细读懂交付产物说明，看清每种状态和分支情况，当发现问题时应该在做之前向别人提出，从而大家可以一起来找到新的解决方案，不要等到完成时再说什么都做不了。

5.细节决定成败，要体现专业能力必须以细节为基础。一开始说的前端开发做的产品细节上的不完善，有个前端的同事说，要做他们感兴趣的东西，他们才能注意起这些问题。的确在前端的领域写js比写css更令人兴奋和有动力。那我只能觉得，产品不是儿戏，更不是因为你感兴趣而去做的。创新的东西人人喜欢，但并不是每个人都可以创新，你一味等着上游的角色给你令人激动的工作，那只能说明你本身并不适合这份工作，所谓的创新就是在专业领域做比别人更专业的事。另外，我不否认写css比js更枯燥，但是这并不意味着css就不重要，其实更多时候css比js重要很多，很多web2.0的网站用的就是css去引导用户，描述产品等。并不是交互和视觉一直关注这些布局和细节的问题，换句话讲，这个都是基础的东西，应该前端开发工程师本身的意识提高，才能让大家关注更多体验的问题。我也希望不要再这些基础的领域绕来绕去，好好做产品，做好自己的角色，做到完美！

最后我想说的是不要认为web设计就是粗糙低劣的，好的web设计更能够提现产品的品质感，我们要升级体验就必须把基础做好，把这些细节都处理好，我们才有可能有精力去做创新，去做体验。

相关话题：设计与沟通源地址：http://www.jojobox.cn/blog/default.asp?id=161

用户体验中沟通的技巧

王俊煜 — 2009-07-16 09:56:46

      对许多在大型企业中工作的用户体验设计师来说，经常感到郁闷的一件事情就是，自己拿着辛辛苦苦熬夜做出来的设计稿去给产品项目组中其他职责的同事一起过目，结果莫名其妙挨了一通不靠谱的板砖——小学学过画画的产品经理小A说，蓝色不好看。客户支持部门的交际花小B说，右边空白挺多，要不放个聊天室窗口让用户能在这聊天吧？名牌大学计算机专业博士毕业的小C问，这个注册按钮为什么放在右边不放在左边，这么放有什么科学根据？专司前端开发的实习生小 D这会儿也忍不住发了个言，这个半透明的圆角阴影咱们做不了呀，你得换个效果……
      到这里你已经有撞墙的冲动。最后会议不欢而散，每个人都愤愤不平地走出会议室，你不明白为什么这帮家伙会提这么多不靠谱的问题，而你的同事们当然也想不通，这个顽固的家伙怎么就这么听不进别人的意见呢？
      无论你是上面情境中的设计师，还是参与的其他人员，你一定都希望这样的情况少发生。设计沟通如何能够更顺畅？设计师如何更容易地把自己的想法推销给项目组中的其他同事？设计师之外的其他团队成员，又如何更有效地表达自己关于用户体验的看法和意见？

沟通是设计师的本职工作
      沟通和团队协作是一名用户体验设计师最基本的能力，也是他的本职工作。虽然许多企业的组织架构中设立了专门的用户体验职位或部门，但事实上用户体验并不是某个人或某个部门的事情。产品团队中的每一个人，都会影响到产品最终呈现给用户的体验。所以，纵然设计师有天才的想法和设计，如果不能把这些想法和设计传递给团队的其他成员并获得认同，那么其价值都大打折扣。
      “用户体验”的另一个特点是：团队每个成员都可以轻而易举地对这个话题发表自己的见解，因为每个人都是用户，都可以很容易从自己的使用经验出发，推断出 “用户会……”。因此，相比起开发人员等其他岗位的团队成员来说，设计师可能需要更多地“忍受”同事的“说三道四”。如何既能在讨论的过程中引导别的同事不断贡献有建设性的意见，又能赢得其他团队成员在用户体验这个领域上的尊重，并在这个自己的“一亩三分地”里面保持一定的决定权，也需要设计师在不断的沟通协作中逐渐实现。
      明确了这一点，或许工作中的困扰也能少一点。许多设计师常抱怨：“同事完全没有设计的sense”，“设计环境不好，老板不理解我的看法”等，这反而说明了这位设计师的工作没有做好。反过来说，如果大家都有sense、如果公司上下都已经有很好的设计环境，你做为设计师能发挥的作用也会小很多。
      对于设计师以外的其他团队成员，若在合作的时候能更清楚对方的专长、职责和定位，也能让双方的协作进行得更加顺畅。许多人至今还狭义地认为用户体验就是负责画画图标的、在产品成型以后做做界面修饰的美工。若仍抱有这样的认识，就很难期望在合作过程中让设计师对整个团队贡献最大化的价值。

确保共识始终存在
      设计归根结底是为了解决问题。不管整个产品设计的流程被分为了几个阶段，不同的阶段实际上都是为了解决不同层面、不同规模的问题。产品团队中的其他同事未必熟悉设计的流程，也未必清楚目前要解决的到底是什么问题。因此，设计师在和不同职责的同事开展讨论之前，都需要确保对方明白整个设计流程是如何规划的、现在进行到哪个部分、今天要讨论的是什么问题、下一步是什么等。先确保了大家都站在同一条船上，才能保证大家力气使到一块。
      另外，在从一个阶段进行到下一个阶段的时候也要确保大家在上个阶段中达成了共识，再往前推进。否则如到了视觉设计的阶段突然发现大家对非常底层的产品定位问题都还没有共识，一切都推倒重来的话损失将非常惨重。
      为保证沟通的有的放矢，设计师在流程的不同阶段也应注意用不同的呈现形式来向同事展示自己的工作。例如，在早期呈现内容规划时，简单粗糙的线框图就要比高保真设计稿更易引发高效的讨论和获取有价值的反馈；而到了后期进行视觉设计确立的阶段，则需要采用高保真的原型来尽可能地模拟真实的产品形态。初入行的设计师可能会觉得始终用较高保真度的设计稿会显得自己的工作做得比较细致，实则不然——其他同事在审阅设计方案时的注意力可能会被许多如按钮阴影、用色等视觉细节所转移，而你本来只是想给大家看一个交互设计的方案。
      如果合作的同事并没有太多和用户体验部门打交道的经验，那务必要花一些时间来对正在使用的呈现形式或方法做一些解释说明。我自己有一次用线框图和负责开发的同事讲解产品的交互流程，当时我以为对方理解线框图的含义，就没有另外做解释。结果，开完会以后心急的开发人员就七手八脚地按照线框图上呈现的视觉样式，把产品的界面给直接做出来了。

用正确的方式证明自己是对的
      在沟通的过程中，其他部门的同事往往会对设计提出很多意见。如何更有效地开展讨论呢？
首先，由于其他同事并不是专业设计人员，其言语表达可能并不能准确地反映他们的真实想法，设计师首先要试图找出其背后的真实含义。
      再者，要引导大家尽量运用事实来作为讨论的论据。听见像“我觉得……”这样的句子，就往往意味着这是一个主观判断——A“觉得”按钮放在右边好，B “觉得”按钮放在左边好，这些都是价值判断；如果没有一些事实作为判断的依据，讨论很难继续下去。“事实”可以有很多种表现形式，例如，可以是业界公认的的界面设计基本原则，可以是以往类似情境下我们做出的决定和最后的效果好坏，可以是产品界面设计规范中的相关规定，可以是之前做的可用性测试中用户的反馈，甚至在必要的时候可以设计一个A/B测试的方案，用测试的数据来证明设计是否达到了预期的目的等。没有事实论据辅助的决策，也就是大家坐在一起拍脑袋而已。
      有一种批评意见认为在设计中过多地强调了如数据这样的理性“证据”，会扼杀设计师们的用创造性方式解决问题的能力。直觉和感性认识当然可以用来提出新的解决方案，但这个解决方案是否最后行得通，尤其是在商业环境中，还是需要有一定的理性根据作为支撑的。胡适先生曾提出，治学一定要“大胆假设，小心求证”，做用户体验设计也如此。
      最后，要提醒讨论的参与者分清楚自己和用户之间的界限。虽然团队成员也是产品的用户，甚至可能恰好是产品的目标用户群，但团队成员们和产品相处的时间要比一般用户多得多，对产品的认知早就和一般用户相去甚远了。在这种情况下，自己模拟用户的角度做出的判断，往往和真实用户的想法是有差距的。所以，如果你听见有人说“用户会……”，就一定多长个心眼，问问这是真的用户行为，还是发言者想像的用户。
做为设计师，可以带领产品团队隔一段时间进行一次用户测试，请同事们前往观摩，往往能看到许多其他团队成员感到吃惊和开眼界的情景。此外，做为设计师，首先应该抱着虚心的态度听取别的同事的意见——他们确实不是专业的设计人员，但他们反而能从一个不一样的角度看待同样的事情，发现一些设计师自己发现不了的问题。
      每次会议讨论的最终决定和这个决定的理由务必详尽记录下来，这样将来可以避免对同一个问题反复的讨论。有时候外部环境发生了一些变化，有时候是产品团队人员的变更，难免会有人在将来提出同样的问题，这时候如果能找到上次讨论同个问题时的结论和理由，就可以很快地看看当时考虑的理由现在是否还成立，有没有新的理由可以支持或反对这个观点，这样一来协作效率就可以提高很多了。

思维方式和知识鸿沟的互补
      用户体验设计师们往往对细节和他人的感受有着敏锐的注意力，而且善于用每当新产品启动，或老的产品准备进行改进或者开发新功能的时候，我们总是会邀请来自包括工程部门、产品部门、运营部门和用户体验部门等各个不同部门的同事坐在一起，召开头脑风暴会议，希望能从大家思想的碰撞中获得一些创新的想法。这样的会议开得多了以后，就能发现一个有趣的现象：设计师们总是倾向于从“用户有可能需要什么”的角度出发考虑问题，而开发人员们总是倾向于从“我们的技术有可能实现什么”的角度出发考虑问题。
      而成功的用户体验，往往是在用户需求、技术能力和商业利益这三者之间达到的平衡，这也是为什么我们的头脑风暴会议一定要有各个部门成员的共同参与。为了进一步让不同的思维方式混合，我们一般还会在初步的头脑风暴过后请大家挑选几个听起来比较靠谱的主意，再混搭不同部门的同事分成多个小组，进一步发展完善这些想法。设计师和开发人员在这个过程中可以互相学习对方的思考过程，形成互补，甚至迸发出新的火花。
      当然知识结构的差异也会给沟通造成障碍。例如，如果设计师不清楚目前产品背后的拥有的技术能做什么事情，做出来的设计要么就会太过于超前于技术的发展以至于完全无法实现，要么就是没有充分发挥出技术的潜在可能性。对于Web产品的设计师来说，不了解Web界面的实现原理，也有可能做出一些在 PhotoShop里面画起来很容易但在Web上实现非常复杂，而且并不能带来许多好处的设计。
      对于非设计领域的同事来说，对用户体验领域的知识有一定了解，既可以令你更容易与设计团队的同事展开沟通，又可以培养自己对产品领域、对用户感受的敏锐注意力，也算锦上添花、一举两得。

产品经理在跨部门沟通中常见问题和解决办法

意外吧 — 2009-02-10 19:16:00

毫不夸张的说，产品经理在工作过程中，60％的时间用于沟通。所以沟通效率决定着工作效率。那么这个话题就很有必要拿出来讨论一番。最近一年多的时间几乎都是在跨部门沟通，而这种沟通模式将成为产品经理自身能力提升的一个关键。

好了，进入正题。跨部门沟通过程中我经常会遇到这些问题：

1、对方不知道我在说什么，哪怕我已经觉得自己说得很明白了，但是他们还是一脸疑惑。
2、我一遍一遍的强调需求。告诉他们我需要的是电视，但是最后却给我一台微波炉。
3、他们的工作效率太低了，还不如我自己来做。
4、他们总是不重视，我一次一次强调的问题，错误一再出现。
5、文档里面说的很清楚了，他们根本就没有仔细看。
……

嘿嘿！好像沟通失效都是别人的问题。怎么办呢？要解决还得从自身开始！

一、分析为什么沟通过程中会有那么多的问题。

1、人性是自利的

不同的部门，必然导致工作目标不同、看问题的视角也不同。人随着处世的时间增长，会更强烈的保护自己。也许开发部的工作就是把你的功能做出来，能超越你的需求从他的专业角度添加个人意见的很少，从经营的角度去考虑是否为将来的运营留一个技术接口的更少。都说语多必失，做的越多也可能错得越多，所以严格按照你的需求来做才是最保险的，这看起来是个很悲哀，但却非常现实。了解人性的这个问题，就能发现，其实沟通中，很多问题不是错在对方，而是我们自身，因为我们往往把自己对事物的看法和认识强加给对方，并那样去要求他们。

反思：当别人在与我们沟通的时候，除了听和记是否也应该思考？把我们的想法现场说出来，也许只是一个字的建议却能给对方打开一个新的思路。现场确认目标，然后才着手实施。期间有好的想法也马上找到负责人，让他来确认，才去实施。

2、信息传递的失真

大家一定做过这类游戏，排头的举重动作，到最后一个人模仿的时候已经成跳水了。出现这种状况，排头的不能说排尾的笨，因为这种不能说话只能肢体的单一沟通方式很容易失真。工作过程中因为沟通方式的单一也往往出现这样的状况，所以会议之后经常要求做会议纪要发给参会者。无论正式还是非正式的都应该考虑到如何避免信息传递失真，对方也许当时明白了你的意思，脑子里面记下了一二三四，但是难保一根烟烧完就只剩二了。

反思：别人在和我们沟通的时候，应该记录下来，如果身边没有笔和纸，一段时间之后又不确认自己是不是100％记得，就再去确认一次。

3、出现问题没有及时反馈

这问题很好理解，但是却也是最容易犯的，人都有惰性，还怕被人批评，所以抱着侥幸心理，即使出现问题也不反馈。

反思：一年多来，我有个感受，做产品经理脸皮要厚，这个职位有个无奈，上级基本都是很忙的、上级的语言基本都是很简练的、上级的思路基本都是很难琢磨的。咱脸皮不厚点，屁股的茧就该厚了。多问、多反馈，这是保证产品良性发展的良药。

分析这些问题，希望在沟通过程中能够重视，否则下次问题还是会出现。

二、出现问题，分析问题，如何解决？

沟通是一门艺术，而我却还是一名山村野夫！就把本夫长期学习和实践的心得整理一下贡大家参考！
牢记四点，做到有效沟通。

在工作的8个小时里，追求的是有效沟通，否则一个讨论会也许会成为抱怨集散地，与同事协调工作最终的结果是你知道最近市场上的猪肉多少钱一斤。如何才能保证有效呢？

（1）明确目标

没有结果的会，干脆不要开！要找谁沟通，最好可以先发个邮件或者打个招呼，告之这次沟通的大概情况，要有不达目的不罢休的精神。

（2）换位思考

一名专业互联网博士去和60多岁深山里的老农沟通，想告诉农夫什么是电子商务，博士满口的B2C、B2B，讲得手舞足蹈、天花乱坠，虽然言表不亚于奥巴马，但是效果却鸡同鸭讲。如果能换位思考，多用一些对方的语言，多了解对方的工作方式，多了解一些对方的性格，沟通的效果就皆大欢喜了。

（3）选择合适的时间、地点、方式

有些同仁，的确鲁莽，逮到对象就上，最后招来一句：“没看到我现在忙么？”灰头土脸的走了。

沟通的方式包括说话语气/肢体动作、书面/非书面、正式/非正式。

记得有专门的研究机构提供过数据，在表达同一层意思时，你的文字、语气、肢体语言对你意思表达的影响各占比重分别为7％、38％、55％，所以如果各位之前没有意识到这点，今后试着刻意观察一下自己沟通过程中的语气和动作，加以改进。假设把小沈阳固定在墙上，除了嘴，其他部位都动不了，观众早睡着了，他还一个劲的在墙上：“我就拎着我这包，走在街上，Pia Pia地！”

关于正式和非正式的问题，值得注意的是，在跨部门沟通中，存在很多敏感的问题，特别是第一次沟通，最好采用正式沟通，例如发邮件给对方，抄送给对方和自己的直接上级，或者直接联系该部门的负责人，得到他的支持等等。

（4）检省与致谢

沟通过程中，发现自己不对或者失职的地方，不要急于解释，应该首先承认自己的错误，发自内心的，然后找补救的办法。要学会接受别人的意见，多说：“恩！你说的有道理。”

对方也有自己的事情，特意的花时间来参与你的讨论，这就应该给予感谢！长久以往，至少你的公司中给人的感觉就会提升，沟通的障碍也会减少。

其实以上四点和生活中的泡妞大法是一样样儿地。眼睛一睁，一动脑，一个飞吻过来了；眼睛一睁，不动脑，一个巴掌过来了，HO~!?

好了，今天先说到这里，本野夫造诣有限，还希望广大同仁多多支招，多多探讨。

设计师不能不知道的10个沟通秘诀

刘亚平 — 2009-09-27 21:11:07

原来做标题党是这种感觉，哈哈哈。

这期的话题是设计和沟通，这个话题实在是太大了，大概6个人坐在一起聊上三天三夜也还有说不完的吧。为此，我们打算把话题约束下，变成“PM（产品经理）和设计师的沟通”。

考虑到不同的人之间的沟通的方式会差异很大（也正是因为有这种差异，我们才把沟通叫做一种艺术），我们先研究下沟通的主体，PM 和设计师，而在座的都是设计师，互相研究也不是太好，我们就重点研究PM吧，反正他们不在场，说他们坏话他们也不知道

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第六期靠近门口那一组同学共同贡献，请恕我不一一署名，非著名设计师刘亚平记录整理。

相关话题：设计与沟通源地址：http://www.justkiddings.com/?p=244

驳亚平同学《设计师不能不知道的10个沟通秘诀》

xiaoxiao — 2009-09-27 21:11:38

刘亚平同学终于开始认真写博客了，不过我觉得他真的是个标题党党员，他自己也承认了。那顺便我也标题党一下，看了十个沟通秘诀，对其中一些观点有另外的一些想法，不是完全否定10个秘诀，这里也来谈谈。

原文链接：《设计师不能不知道的10个沟通秘诀》

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沟通的时候，他认为规范不应变的太快，我想有一定的道理，但前提是规范要足够的丰满和完善才可以达到。

想哪儿写哪儿，纯个人看法，欢迎亚平同学继续PK。