导读：一个好的设计师并不只是具有优秀的设计能力，对于沟通来说也是许多设计师必须掌握的技巧，不管是网页设计还是用户体验，沟通是我们与客户传达思想和设计理念的次要途径。无论怎样的设计，如果由于客户最后无法理解而被否定的话，那么将会是十分蹩脚的结果。

对许多在大型企业中任务的用户体验设计师来说，经常感到郁闷的一件事情就是，本人拿着辛辛劳苦熬夜做出来的设计稿去给产品项目组中其他职责的同事一同过目，结果莫明其妙挨了一通不靠谱的板砖——小学学过画画的产品经理小A说，蓝色不好看。客户支持部门的交际花小B说，左边空白挺多，要不放个聊天室窗口让用户能在这聊天吧？名牌大学计算机专业博士毕业的小C问，这个注册按钮为什么放在左边不放在左边，这么放有什么科学依据？专司前端开发的实习生小D这会儿也忍不住发了个言，这个半通明的圆角暗影我们做不了呀，你得换个效果……

到这里你曾经有撞墙的冲动。最后会议不欢而散，每团体都愤愤不平地走出会议室，你不明白为什么这帮家伙会提这么多不靠谱的问题，而你的同事们当然也想不通，这个顽固的家伙怎样就这么听不进别人的意见呢？

无论你是上面情境中的设计师，还是参与的其他人员，你一定都希望这样的情况少发生。设计沟通如何能够更顺畅？设计师如何更容易地把本人的想法推销给项目组中的其他同事？设计师之外的其他团队成员，又如何更无效地表达本人关于用户体验的看法和意见？

沟通是设计师的本职任务

沟通和团队协作是一名用户体验设计师最基本的能力，也是他的本职任务。虽然许多企业的组织架构中设立了专门的用户体验职位或部门，但理想上用户体验并不是某团体或某个部门的事情。产品团队中的每一团体，都会影响到产品最终呈现给用户的体验。所以，纵然设计师有天才的想法和设计，如果不能把这些想法和设计传递给团队的其他成员并获得认同，那么其价值都大打折扣。

“用户体验”的另一个特点是：团队每个成员都可以轻而易举地对这个话题发表本人的见解，由于每团体都是用户，都可以很容易从本人的使用经验出发，推断出 “用户会……”。因此，相比起开发人员等其他岗位的团队成员来说，设计师可能需求更多地“忍耐”同事的“说三道四”。如何既能在讨论的过程中引导别的同事不断奉献有建设性的意见，又能博得其他团队成员在用户体验这个领域上的尊重，并在这个本人的“一亩三分地”里面保持一定的决定权，也需求设计师在不断的沟通协作中逐渐实现。

明确了这一点，或许任务中的困扰也能少一点。许多设计师常抱怨：“同事完全没有设计的sense”，“设计环境不好，老板不理解我的看法”等，这反而说明了这位设计师的任务没有做好。反过来说，如果大家都有sense、如果公司上下都曾经有很好的设计环境，你做为设计师能发挥的作用也会小很多。

对于设计师以外的其他团队成员，若在合作的时候能更清楚对方的特长、职责和定位，也能让双方的协作进行得愈加顺畅。许多人至今还狭义地认为用户体验就是担任画画图标的、在产品成型当前做做界面修饰的美工。若仍抱有这样的认识，就很难期望在合作过程中让设计师对整个团队奉献最大化的价值。

确保共识一直存在

设计归根结底是为了处理问题。不管整个产品设计的流程被分为了几个阶段，不同的阶段实际上都是为了处理不同层面、不同规模的问题。产品团队中的其他同事未必熟悉设计的流程，也未必清楚目前要处理的到底是什么问题。因此，设计师在和不同职责的同事开展讨论之前，都需求确保对方明白整个设计流程是如何规划的、 如今进行到哪个部分、今天要讨论的是什么问题、下一步是什么等。先确保了大家都站在同一条船上，才能保证大家力气使到一块。

另外，在从一个阶段进行到下一个阶段的时候也要确保大家在上个阶段中达成了共识，再往前推进。否则如到了视觉设计的阶段突然发现大家对非常底层的产品定位问题都还没有共识，一切都推倒重来的话损失将非常惨重。

为保证沟通的有的放矢，设计师在流程的不同阶段也应留意用不同的呈现方式来向同事展现本人的任务。例如，在晚期呈现内容规划时，简单粗糙的线框图就要比高保真设计稿更易引发高效的讨论和获取有价值的反馈；而到了后期进行视觉设计确立的阶段，则需求采用高保真的原型来尽可能地模仿真实的产品形状。初入行的设计师可能会觉得一直用较高保真度的设计稿会显得本人的任务做得比较细致，实则不然——其他同事在审阅设计方案时的留意力可能会被许多如按钮暗影、用色等视觉细节所转移，而你本来只是想给大家看一个交互设计的方案。

如果合作的同事并没有太多和用户体验部门打交道的经验，那务必要花一些时间来对正在使用的呈现方式或方法做一些解释说明。我本人有一次用线框图和担任开发的同事讲解产品的交互流程，当时我以为对方理解线框图的含义，就没有另外做解释。结果，开完会当前心急的开发人员就七手八脚地按照线框图上呈现的视觉款式，把产品的界面给直接做出来了。

用正确的方式证明本人是对的

在沟通的过程中，其他部门的同事往往会对设计提出很多意见。如何更无效地开展讨论呢？

首先，由于其他同事并不是专业设计人员，其言语表达可能并不能精确地反映他们的真实想法，设计师首先要试图找出其背后的真实含义。

再者，要引导大家尽量运用理想来作为讨论的论据。听见像“我觉得……”这样的句子，就往往意味着这是一个客观判断——A“觉得”按钮放在左边好，B “觉得”按钮放在左边好，这些都是价值判断；如果没有一些理想作为判断的依据，讨论很难继续下去。“理想”可以有很多种表现方式，例如，可以是业界公认的的界面设计基本准绳，可以是以往类似情境下我们做出的决定和最后的效果好坏，可以是产品界面设计规范中的相关规定，可以是之前做的可用性测试中用户的反馈，甚至在必要的时候可以设计一个A/B测试的方案，用测试的数据来证明设计能否达到了预期的目的等。没有理想论据辅助的决策， 也就是大家坐在一同拍脑袋而已。

有一种批评意见认为在设计中过多地强调了如数据这样的理性“证据”，会扼杀设计师们的用创造性方式处理问题的能力。直觉和感性认识当然可以用来提出新的处理方案，但这个处理方案能否最后行得通，尤其是在商业环境中，还是需求有一定的理性依据作为支撑的。胡适先生曾提出，治学一定要“大胆假设，小心求证”，做用户体验设计也如此。

最后，要提示讨论的参与者分清楚本人和用户之间的界限。虽然团队成员也是产品的用户，甚至可能恰好是产品的目标用户群，但团队成员们和产品相处的时间要比普通用户多得多，对产品的认知早就和普通用户相去甚远了。在这种情况下，本人模仿用户的角度做出的判断，往往和真实用户的想法是有差距的。所以，如果你听见有人说“用户会……”，就一定多长个心眼，问问这是真的用户行为，还是发言者想像的用户。

做为设计师，可以带领产品团队隔一段时间进行一次用户测试，请同事们前往观摩，往往能看到许多其他团队成员感到吃惊和开眼界的情景。此外，做为设计师，首先应该抱着谦虚的态度听取别的同事的意见——他们确实不是专业的设计人员，但他们反而能从一个不一样的角度看待同样的事情，发现一些设计师本人发现不了的问题。

每次会议讨论的最终决定和这个决定的理由务必详尽记录下来，这样将来可以避免对同一个问题反复的讨论。有时候外部环境发生了一些变化，有时候是产品团队人员的变更，难免会有人在将来提出同样的问题，这时候如果能找到上次讨论同个问题时的结论和理由，就可以很快地看看当时考虑的理由如今能否还成立，有没有新的理由可以支持或反对这个观点，这样一来协作效率就可以提高很多了。

思维方式和知识鸿沟的互补

用户体验设计师们往往对细节和他人的感受有着敏锐的留意力，而且善于用每当新产品启动，或老的产品预备进行改进或者开发新功用的时候，我们总是会约请来自包括工程部门、产品部门、运营部门和用户体验部门等各个不同部门的同事坐在一同，召开头脑风暴会议，希望能从大家思想的碰撞中获得一些创新的想法。这样的会议开得多了当前，就能发现一个风趣的景象：设计师们总是倾向于从“用户有可能需求什么”的角度出发考虑问题，而开发人员们总是倾向于从“我们的技术有可能实现什么”的角度出发考虑问题。

而成功的用户体验，往往是在用户需求、技术能力和商业利益这三者之间达到的平衡，这也是为什么我们的头脑风暴会议一定要有各个部门成员的共同参与。为了进一步让不同的思维方式混合，我们普通还会在初步的头脑风暴过后请大家挑选几个听起来比较靠谱