为什么你的设计方案没问题，但开发就是不想做？
扫一扫 
扫一扫 
扫一扫 
扫一扫
本期《设计师如何自我评价和规划？KASH能力图谱来帮你》系列为你分享的是 Skill（技能篇）里的第一项底层技能：沟通。 因为最近有几位读者和我交流了工作上的沟通问题和困惑，那我就借此机会为大家分享一些个人在提升沟通方面的经验和心得。 当然，沟通是个很大的话题，一篇文章是不可能讲完的。那么本文重点分享：提升沟通能力的两个步骤，也是笔者从工作中总结出的一套基础版的沟通方法论：
在详细介绍步骤之前，我们首先简单了解一下沟通能力的重要性和本质，以便更好地理解和运用后面提到的具体步骤。 沟通能力有多重要腾讯和 IXDC 联合出品的《2018年用户体验行业调查报告》指出：为保持核心竞争力，用户体验设计行业的从业者，需要具备的前 5 项能力：用户体验、沟通能力、逻辑分析能力、设计表达、产品理解。
笔者为此特别关注了前几年的《用户体验行业调查报告》，沟通能力的重要性一直排在前 3。 此外，根据 2019 年全美大学与雇主协会（NACE）的数据分析，在全球包括中国在内的很多企业招聘要求越来越挑剔了，也更加关注应聘者的软技能：第一是沟通能力，第二是解决问题的能力。 设计师，作为产品研发流程中的可视化环节，需要沟通的场景和时间丝毫不少于产品经理。甚至，在很多行业流传一个段子：做得好的不如说得好的。从某种意义上讲，优秀的沟通表达能力会为我们的工作成果和价值锦上添花。 沟通的本质是什么在回答这个问题前，我们先来思考这个问题：为什么要沟通？ 因为每个人的大脑信息储备和处理能力不同，导致不同专业背景、不同职位，甚至不同成长环境的人，在知识储备、理解能力、思维方式上是有差异的。 简单点说，因为合作的双方或多方因信息不对称，所以需要通过沟通的手段传递信息，从而达成共同的目标。 因此，沟通的本质是：解决信息不对称的问题，并达成共同目标。 提升沟通能力的两个步骤要想找到有效训练沟通能力的方法，那首先需要找到「不擅长沟通」这个问题的本质。 下面我们一步步拆解这个问题，从中找到答案。 首先，我们可以将「不擅长沟通」这个问题，拆解成这两个子问题：
「不知道说什么」的背后是认知、思维、知识储备的问题，也就是平时没有「输入」；而「不知道怎么说」的背后是语言和文字表达方式的问题，也就是不知道如何「输出」。 下面我们从「有意识地输入、有方法地输出」这两个步骤，来看如何有效训练沟通能力。 1. 有意识地输入这里说的输入主要是指我们需要有意识地长期输入和积累设计专业领域的思维方式、知识储备、项目设计经验，比如基本的设计法则、主流平台的设计规范、用户心智、竞品分析等等，这些都可以形成我们自己的知识储备，为设计方案和设计表达提供理论和经验支持。 比如，笔者的《设计师如何自我评价和规划？KASH能力图谱来帮你》、木子设计网、设计公众号等等，都可以作为我们思维和知识的来源。 木子设计网设计法则系列：
2. 有方法地输出这里给大家分享一个比较基础的沟通设计方案的思路，也是我自己经常使用的沟通方法：QHB，先讲我们需要解决什么问题（Question），再讲如何解决/解决方案（How），最后讲这个方案会给 ta 带来哪些好处/利益（Benefit）。
Question（问题） 对于交互设计方案来说，多数情况是为了解决一个具体问题，然后在用户、产品、技术之间找到平衡后，产出设计方案。笔者始终认为：设计是一定要解决问题的，而且这个问题对用户、对公司、对产品来说都很重要，否则很难有说服力。 所以，当我们和上下游同事沟通设计方案时，首先必须明确眼下我们共同需要解决什么问题，可能这个问题产品经理比较熟悉和认同，但工程师不一定知道方案背景。 在与开发同事沟通方案时，建议大家首先将问题的重要性和影响，传达给开发同事。在我接触的开发同事里，80% 以上的开发是可以讲道理的。 小结一下，在第一步 Quesiton 阶段，我们要知道上下游是紧密的协作关系，大家需要解决同一个问题，而不是工作流里的对立面。特别对于开发同事来说，要让他们意识到这个方案的意义是为用户、为公司解决一个难题，而不是又多了几百行代码甚至更多。 How（方案） 说完问题之后，就可以直接讲清楚我们的设计方案了，可以描述交互文档，讲清楚交互场景和细节，以及异常的处理方式等等。必要时，可以制作并演示交互 Demo，让上下游同事看到我们的态度和专业。一些设计师朋友和我抱怨过，他们在团队里没有话语权。从我个人来看，话语权从来都是自己争取来的，越不说话就越没有话语权。 所以，我们设计师要把握好每次和上下游沟通设计方案的机会，态度、同理心、专业水平是获得话语权的关键。 Benefit（收益） 最后一步是表达这个设计方案对 ta 的价值/收益，也就是给ta带来哪些好处。 可能有读者觉得这一步是多余的，讲了问题，又讲了设计方案，我的工作已经做完了，别人做不做是别人的事，我哪管的了。 事实上，我们在很多文章里会看到设计师需要有同理心的说法，而笔者这里谈到的 Benefit 就是同理心的表现，而做到了这一点，你将很快成为职场里受欢迎的设计师。 比如，在研发进度可控范围内，我们需要开发实现一个新的交互控件。 这时候，我们需要站在对方的角度，首先表达对开发工作量的理解，其次就要说出如果实现了这个新交互控件的好处/价值：这个交互控件不仅现在可以很好地解决用户提出的问题，在未来还可以复用在其他业务场景里，以后其他同事都可以来引用你今天实现的这套方法。 好的，信息量比较大，我们回到最初的那个案例，用 QHB 的沟通方法，模拟一下和开发如何沟通：
一般情况下，成熟的前端工程师是可以在短时间内评估出常见交互的可行性的。如果他拒绝帮我们评估，那可能就不是沟通的问题，基本是职场关系的问题，那这又是另一个大话题，这里不展开。 Question 之后，给他讲交互 Demo：
说完这些，如果顺利的话，我们表达一下谢谢就可以了。如果他始终表达自己的难处，那我们继续换位思考，然后讲出 Benefit：
事实上，实际工作中的场景要比上述要复杂得多，QHB 方法不可能适用所有场景，笔者举这个例子只是希望能把 QHB 解释清楚。 但是，我相信，只要我们认真准备好每次设计方案沟通，并且提前将可能被反问的问题想好，沟通能力是可以提升的。 与不同角色沟通时的关键点下面，为大家从角色的角度，分享一点沟通时的关键点，基本的思路是：对方最关心的是什么，我们就聚焦对方关心的点，尝试表达设计方案的意义和价值。 1. 产品经理 产品目标、用户目标、KPI、产品迭代、上级指示、运营反馈的问题…... 2. 项目经理 交付、成本、进度、甲方意见…... 3. 工程师 成本、技术难度、有无开源组件可以直接用、复用性、统一性…... 4. 老板/领导 有没有商业价值…... 5. 与客户沟通时的注意点 设计方案能满足客户的需求吗？ 如果客户的想法特别不合理，说服他时不能让他觉得没面子。 客户的满意度，背后其实是客户上级的满意度，我们的设计方案要让客户顺利地「交差」…... 当然，现实工作中的场景要复杂和多变，上述的 Tips 不能算是行动指南。欢迎大家通过留言和私聊的方式与我一起交流沟通方面的问题和困惑。 总结
欢迎关注作者的微信公众号：「设计意志」
手机扫一扫，阅读下载更方便˃ʍ˂ |
@版权声明
1、本网站文章、帖子等仅代表作者本人的观点，与本站立场无关。
2、转载或引用本网版权所有之内容须注明“转自(或引自)网”字样，并标明本网网址。
3、本站所有图片和资源来源于用户上传和网络，仅用作展示，如有侵权请联系站长！QQ: 13671295。
最新评论
