|
对许多在大型企业中工作的用户体验设计师来说，经常感到郁闷的一件事情就是，自己拿着辛辛苦苦熬夜做出来的设计稿去给产品项目组中其他职责的同事一起过目，结果莫名其妙挨了一通不靠谱的板砖——小学学过画画的产品经理小A说，蓝色不好看。客户支持部门的交际花小B说，右边空白挺多，要不放个聊天室窗口让用户能在这聊天吧？名牌大学计算机专业博士毕业的小C问，这个注册按钮为什么放在右边不放在左边，这么放有什么科学根据？专司前端开发的实习生小D这会儿也忍不住发了个言，这个半透明的圆角阴影咱们做不了呀，你得换个效果……
到这里你已经有撞墙的冲动。最后会议不欢而散，每个人都愤愤不平地走出会议室，你不明白为什么这帮家伙会提这么多不靠谱的问题，而你的同事们当然也想不通，这个顽固的家伙怎么就这么听不进别人的意见呢？
无论你是上面情境中的设计师，还是参与的其他人员，你一定都希望这样的情况少发生。设计沟通如何能够更顺畅？设计师如何更容易地把自己的想法推销给项目组中的其他同事？设计师之外的其他团队成员，又如何更有效地表达自己关于用户体验的看法和意见？
沟通是设计师的本职工作
沟通和团队协作是一名用户体验设计师最基本的能力，也是他的本职工作。虽然许多企业的组织架构中设立了专门的用户体验职位或部门，但事实上用户体验并不是某个人或某个部门的事情。产品团队中的每一个人，都会影响到产品最终呈现给用户的体验。所以，纵然设计师有天才的想法和设计，如果不能把这些想法和设计传递给团队的其他成员并获得认同，那么其价值都大打折扣。
“用户体验”的另一个特点是：团队每个成员都可以轻而易举地对这个话题发表自己的见解，因为每个人都是用户，都可以很容易从自己的使用经验出发，推断出“用户会……”。因此，相比起开发人员等其他岗位的团队成员来说，设计师可能需要更多地“忍受”同事的“说三道四”。如何既能在讨论的过程中引导别的同事不断贡献有建设性的意见，又能赢得其他团队成员在用户体验这个领域上的尊重，并在这个自己的“一亩三分地”里面保持一定的决定权，也需要设计师在不断的沟通协作中逐渐实现。
明确了这一点，或许工作中的困扰也能少一点。许多设计师常抱怨：“同事完全没有设计的sense”，“设计环境不好，老板不理解我的看法”等，这反而说明了这位设计师的工作没有做好。反过来说，如果大家都有sense、如果公司上下都已经有很好的设计环境，你做为设计师能发挥的作用也会小很多。
对于设计师以外的其他团队成员，若在合作的时候能更清楚对方的专长、职责和定位，也能让双方的协作进行得更加顺畅。许多人至今还狭义地认为用户体验就是负责画画图标的、在产品成型以后做做界面修饰的美工。若仍抱有这样的认识，就很难期望在合作过程中让设计师对整个团队贡献最大化的价值。
确保共识始终存在
设计归根结底是为了解决问题。不管整个产品设计的流程被分为了几个阶段，不同的阶段实际上都是为了解决不同层面、不同规模的问题。产品团队中的其他同事未必熟悉设计的流程，也未必清楚目前要解决的到底是什么问题。因此，设计师在和不同职责的同事开展讨论之前，都需要确保对方明白整个设计流程是如何规划的、现在进行到哪个部分、今天要讨论的是什么问题、下一步是什么等。先确保了大家都站在同一条船上，才能保证大家力气使到一块。
另外，在从一个阶段进行到下一个阶段的时候也要确保大家在上个阶段中达成了共识，再往前推进。否则如到了视觉设计的阶段突然发现大家对非常底层的产品定位问题都还没有共识，一切都推倒重来的话损失将非常惨重。
为保证沟通的有的放矢，设计师在流程的不同阶段也应注意用不同的呈现形式来向同事展示自己的工作。例如，在早期呈现内容规划时，简单粗糙的线框图就要比高保真设计稿更易引发高效的讨论和获取有价值的反馈；而到了后期进行视觉设计确立的阶段，则需要采用高保真的原型来尽可能地模拟真实的产品形态。初入行的设计师可能会觉得始终用较高保真度的设计稿会显得自己的工作做得比较细致，实则不然——其他同事在审阅设计方案时的注意力可能会被许多如按钮阴影、用色等视觉细节所转移，而你本来只是想给大家看一个交互设计的方案。
如果合作的同事并没有太多和用户体验部门打交道的经验，那务必要花一些时间来对正在使用的呈现形式或方法做一些解释说明。我自己有一次用线框图和负责开发的同事讲解产品的交互流程，当时我以为对方理解线框图的含义，就没有另外做解释。结果，开完会以后心急的开发人员就七手八脚地按照线框图上呈现的视觉样式，把产品的界面给直接做出来了。
用正确的方式证明自己是对的
在沟通的过程中，其他部门的同事往往会对设计提出很多意见。如何更有效地开展讨论呢？首先，由于其他同事并不是专业设计人员，其言语表达可能并不能准确地反映他们的真实想法，设计师首先要试图找出其背后的真实含义。
再者，要引导大家尽量运用事实来作为讨论的论据。听见像“我觉得……”这样的句子，就往往意味着这是一个主观判断——A“觉得”按钮放在右边好，B“觉得”按钮放在左边好，这些都是价值判断；如果没有一些事实作为判断的依据，讨论很难继续下去。“事实”可以有很多种表现形式，例如，可以是业界公认的的界面设计基本原则，可以是以往类似情境下我们做出的决定和最后的效果好坏，可以是产品界面设计规范中的相关规定，可以是之前做的可用性测试中用户的反馈，甚至在必要的时候可以设计一个A/B测试的方案，用测试的数据来证明设计是否达到了预期的目的等。没有事实论据辅助的决策，也就是大家坐在一起拍脑袋而已。
有一种批评意见认为在设计中过多地强调了如数据这样的理性“证据”，会扼杀设计师们的用创造性方式解决问题的能力。直觉和感性认识当然可以用来提出新的解决方案，但这个解决方案是否最后行得通，尤其是在商业环境中，还是需要有一定的理性根据作为支撑的。胡适先生曾提出，治学一定要“大胆假设，小心求证”，做用户体验设计也如此。
最后，要提醒讨论的参与者分清楚自己和用户之间的界限。虽然团队成员也是产品的用户，甚至可能恰好是产品的目标用户群，但团队成员们和产品相处的时间要比一般用户多得多，对产品的认知早就和一般用户相去甚远了。在这种情况下，自己模拟用户的角度做出的判断，往往和真实用户的想法是有差距的。所以，如果你听见有人说“用户会……”，就一定多长个心眼，问问这是真的用户行为，还是发言者想像的用户。做为设计师，可以带领产品团队隔一段时间进行一次用户测试，请同事们前往观摩，往往能看到许多其他团队成员感到吃惊和开眼界的情景。此外，做为设计师，首先应该抱着虚心的态度听取别的同事的意见——他们确实不是专业的设计人员，但他们反而能从一个不一样的角度看待同样的事情，发现一些设计师自己发现不了的问题。
每次会议讨论的最终决定和这个决定的理由务必详尽记录下来，这样将来可以避免对同一个问题反复的讨论。有时候外部环境发生了一些变化，有时候是产品团队人员的变更，难免会有人在将来提出同样的问题，这时候如果能找到上次讨论同个问题时的结论和理由，就可以很快地看看当时考虑的理由现在是否还成立，有没有新的理由可以支持或反对这个观点，这样一来协作效率就可以提高很多了。
思维方式和知识鸿沟的互补
用户体验设计师们往往对细节和他人的感受有着敏锐的注意力，而且善于用每当新产品启动，或老的产品准备进行改进或者开发新功能的时候，我们总是会邀请来自包括工程部门、产品部门、运营部门和用户体验部门等各个不同部门的同事坐在一起，召开头脑风暴会议，希望能从大家思想的碰撞中获得一些创新的想法。这样的会议开得多了以后，就能发现一个有趣的现象：设计师们总是倾向于从“用户有可能需要什么”的角度出发考虑问题，而开发人员们总是倾向于从“我们的技术有可能实现什么”的角度出发考虑问题。
而成功的用户体验，往往是在用户需求、技术能力和商业利益这三者之间达到的平衡，这也是为什么我们的头脑风暴会议一定要有各个部门成员的共同参与。为了进一步让不同的思维方式混合，我们一般还会在初步的头脑风暴过后请大家挑选几个听起来比较靠谱的主意，再混搭不同部门的同事分成多个小组，进一步发展完善这些想法。设计师和开发人员在这个过程中可以互相学习对方的思考过程，形成互补，甚至迸发出新的火花。
当然知识结构的差异也会给沟通造成障碍。例如，如果设计师不清楚目前产品背后的拥有的技术能做什么事情，做出来的设计要么就会太过于超前于技术的发展以至于完全无法实现，要么就是没有充分发挥出技术的潜在可能性。对于Web产品的设计师来说，不了解Web界面的实现原理，也有可能做出一些在PhotoShop里面画起来很容易但在Web上实现非常复杂，而且并不能带来许多好处的设计。
对于非设计领域的同事来说，对用户体验领域的知识有一定了解，既可以令你更容易与设计团队的同事展开沟通，又可以培养自己对产品领域、对用户感受的敏锐注意力，也算锦上添花、一举两得。
|