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