设计的协作与沟通 - UCD大社区

设计师的“通天塔”—浅谈设计沟通

珊珊 — 2012-10-09 19:49:49

前听过这样一个故事，南方的孩子没见过雪，所以不知道雪是什么东西。老师说雪是纯白的，儿童就将雪想像成盐；老师说雪是冷的，儿童将雪想像成了冰淇淋；老师说雪是细细的，儿童就将雪想像成了沙子。最后，儿童在考试的时候，这样描述雪：雪是淡黄色，味道又冷又咸的沙。从这个故事，是否可以联想到设计师和产品经理或营销专员之间的那点儿事？这里聊聊我对于设计时存在的沟通问题的理解，和总结的一些沟通方法，希望能给刚入行或正为此事伤脑经的你一点帮助。

在工作中，设计师是否经常遇到类似这样的问题：

需求方指着设计稿说，按钮应该更大点儿。颜色改个红色的会更好。不够大气！#￥%&*）（…。再或者，因为沟通不顺畅、不透彻，导致设计师对产品或对需求理解有误，后期花了大量的时间去再讨论，去修改或优化。

诸如此类的问题的确让设计师苦不堪言，我们经常抱怨产品经理没有眼光，或者表达力有问题，浪费大家的时间。殊不知，这是双方沟通出了问题。

在我看来，设计之初的沟通是至关重要的，设计作品是团队共同的结晶，一起捏的小人儿。需求没有描述清楚，出来的儿子产品经理怎么看都不像是亲生的，当然不悦。当前期就商量好这鼻子嘴巴耳朵长什么样了，捏的过程中再不断商榷细化，那么结果就自然是皆大欢喜的，儿子再丑也是咱亲生的，在双方共同努力下诞生的，这样也就避免了后期不必要的纷争，降低了后期沟通成本。所以，及时有效的沟通是很重要的。

什么是沟通？

沟通是一门博大精深的学问，在任何领域，任何分工，都避免不了沟通。无论是上下级汇报，或同事间协作。设计师也毫不例外，当接到需求或介入需求的时候，我们需要与需求方沟通，做用户调研则需要与用户沟通。前言中雪的故事，归其原因，是因为沟通不畅，或信息传达不对称不完整所导致。所谓沟通，是人与人之间的思想和信息的交换，是将信息由一个人传达给另一个人，逐渐广泛传播的过程。这是百度百科对“沟通”一词做的解释。没错，简而言之，沟通就是信息的传达。

需求方与设计师之间的关系

在一个项目里，产品经理职责是对整个产品负责，他决定了产品的整个命运，也就是整个项目的需求方，设计师是需要满足产品经理对产品的任何需求，但也并不是他说什么都算。有时候产品策略，或营销方案与用户体验相冲突时，设计师有义务有权利对需求提出自己的见解和更好的设计方案。有不同意见可以讨论，相互协调，而非有既生瑜何生亮的感叹，学会多角度换位思考，不应有谁一定对一定错的定论，但是最终决定权，应该依然属于产品经理或营销专员。往往一个好的产品经理一定是半个好的设计师，好的设计师也是半个好的产品经理。两者你中有我，我中有你。

双方存在的沟通障碍

A专业层面上，需求方过多干预（视觉、交互、用户体验）

对于专业层面上的问题，例如色彩、质感、样式等此类问题。诸如此类问题大多存在于营销推广设计上，建议可以在设计之初，与需求方沟通，明确以下几点问题，可以大幅度的降低后期返工的几率。

设计主题是什么
目的是什么
根据搜集的信息，与需求方明确大致风格（最好能明确到色彩、质感、主要的设计元素、布局等，前期达成意见一致后，可以避免后期返工）

B 信息传达上不一致，对产品理解不一致

此类问题，基本存在在产品设计上，在产品设计上，大方向由产品经理把控，包括产品的决策，产品的发展和前途，在此前提下，设计师把控用户体验。建议设计师提前介入项目，越早越好，了解项目背景，及发起这个项目的原因，现存的问题及要优化的点，取消信息不对等情况。避免产品经理说一点做一点，到最后在不了解项目背景、整体规划的情况下，跟完整个项目，这势必会出现前言中，学生描述雪一样的问题。

心理预期

所谓术业有专攻，设计师必须明白，产品经理，或营销的专业度，如对产品的理解、文案的把控、营销手段的拿捏等专业技能。产品经理或营销专员也必须清楚自己的产品或营销目的，他们有必要完善自己的方案后再与设计师沟通。而设计师必须相信自己的专业能力，有对于用户体验独到的理解和判断。

沟通的最终目的是在目标一致的情况下，达成共识。但我们必须清楚一点，就是并非每个上线产品或专题页面都是最优方案，所有的产品、设计，都是在不断迭代更新中不断完善优化的。所以，设计师应该学会适当的妥协和欣赏残缺美，退一步海更阔天亦空。

我们该如何有效沟通？

当我们要向对方索取认同，或避免后期意见不合时，首先要了解对方需求和也许隐藏着的真正目的，抓住沟通的问题本质，知其然知其所以然，才是制胜法宝，无论是设计之初的讨论阶段，中期对产品对设计优化，还是后期对需求和产品设计方案的意见纷争上；其次，通过有效的对话机制，传递专业精神和观点见解，以设计师的身份传递专业精神和观点见解，以达到设计师和需求方双方共识共赢为目标。最后，有效沟通要讲究策略和方法。

前阵子，读了一本《佐藤可士和的超整理术》，他的观点与我的看法，不谋而合，综合了他的一些看法和我的观点，兴许会对设计师与需求方的沟通有帮助。

1.倾听——了解现况

倾听是为了收集信息，掌握现有情况，收集需求方的想法。一些需求方的个人想法，例如对产品的认识规划及对产品的期望、背景、对于现有方案的意见等，这些都是存在在需求方的脑海中，设计师应该努力将这些信息都可视化，这些因素对你的设计将会有很大的启发和灵感激发。此外，倾听还是种美德。

2.问诊——抓住问题本质

问诊，这是佐藤可士和提出的说法。设计师=医生问的本质是通过问诊，找问题关键因素，帮对方整理思绪。通过多次的讨论，思想的碰撞，舍弃其余含糊不清的多余信息，理清问题本质，这是最关键的一步。

3.分析——导入观点

对问题本质的分析解读，以各种角度检视信息，根据关键因素，给出设计师专业看法和见解。

4.解决——给出方案

通过与需求方的探讨，给出最终的相应解决方案。

“按钮”案例分析：

倾听需求方说：我希望按钮更大点!

问诊设计师说：为什么要放大？按钮放大真的很不美观！

需求方说：我希望用户去点击，让用户觉得这个按钮能够让用户更有点击欲望，更明显一点。（原来是这样，关键因素是：希望通过对按钮的优化增加用户的行动力）

分析设计师给出专业意见。按钮变的更大一点儿，是唯一可以实行的方法吗？答案是否定的，站在用户的角度考虑，按钮太大会让人产生不舒服不协调的感觉，影响视觉表现效果。或许按钮可以变成使人更有点击冲动的颜色，或许可以增加一些质感，或者按钮变一种形状，这些方案都可以达到按钮更醒目，更有点击欲望，而非仅仅使它变大。

解决和需求方沟通后，得出结论，只要按钮变个颜色，再增加一些质感就可以达到预期效果。于是给出方案，原本蓝色的单色按钮变成橙色带渐变的微质感按钮。皆大欢喜。

总而言之，沟通是成为一个优秀的设计师的必修课之一。明确设计师和需求方之间的交融关系，并能够明白两者之间沟通障碍的原因，摆正好心态的前提下，找出解决方法的本质，抓住问题的关键因素，给出正确的观点，给出完美的方案，就能进行顺畅的沟通。这篇博文，并不是针对某个特定的问题去展开说明的，只是针对设计过程中沟通本身的一些浅薄的想法，希望各位受用。

寻找属于你的角色与位置（UCD书友会第17期总结）

胡晓 — 2010-03-28 13:12:24

非常感谢金山公司的邀请，非常谢谢lulu，UCD广州一群fans能够到金山公司参观与交流。总的感觉，金山公司是一家非常专业，有着非常靠谱、敬业、活跃、等优秀员工的企业，公司非常有文化和内涵，在办公室各个区域都体现了员工作为主人翁的精彩之笔，譬如自己设计壁画、自己设计雕塑、自己设计酒楼、自己设计办公装饰等等。这次活动美女也很多，哈哈。！查看更多图片

这次活动安排了四个环节：

1、上午：游戏交互设计界面的发展展望（20人讨论、林健、蒋维、晓宁主持）；
2、下午：UCD书友会介绍（胡晓介绍、130人）
3、下午：Twitter的传播及SMM案例（光耀分享、130人）；
4、下午：设计的协作与沟通（童跃美主持、130人）

《游戏交互设计界面的发展展望》这个课题因时间的局限性，未讨论到尽兴。做游戏的同学都畅所欲言，未来还可以再安排一个时间再讨论，我个人亦非常感兴趣。比如微软2019，以故事的叙述方式来向大家展示未来科技可以实现的功能。先看看这段视频：

Popout

前两天焱红把Institute for the Future的Lyn Jeffery请过来，她们正在做一些研究，通过将人们的行为动作、习惯等数据、进行分析，并与各类科学家进行沟通与交流，最终得出一些10年预测的报告。当然，她们也接受一些大公司的业务委托，比如诺基亚。挺有意思的，有兴趣的话可以多多沟通和交流。

非常感谢光耀能够在仓促的时间赶来和大家分享“Twitter的传播及SMM案例”，光耀站着讲了一个小时，现场提问的不少，还有人追问，佩服。来，大家认识一下，非常平实的照片，哈哈。

沉思

Twitter的传播及SMM案例

View more presentations from top idea.

《设计的协作与沟通》环节我们首先做了一个传递数字的游戏，临时组成3个小组，每个小组10个人左右，在10分钟内自行协商挑选leader，数字输出入输出人员。通过3次任务的传递情况，发现打破常规者有（直接通过短信传递数字或者直接将纸条传上来），很有趣，这是调整规则的，因为规则原本就没有制定很详细。稳打稳扎的、速度出奇高的、拍在身上噼里啪啦的等等都有。活动其实就是通过3次短时间的任务，测试短时间的小团队通过充分协作和沟通实现共同目标。

标题中提到，找准属于你的角色与位置，其实是我对沟通与协作的一个总括。个人觉得首先应该充分认识到自己在团队、任务中所处的位置与角色，然后在合适的环境、合适的时间、采用合适的方法与对方协作与沟通，当然这其中有许多方法与技巧。看看别的同学写的总结：

对于沟通部分，彭毅也写了一篇blog给我们分享：“设计的沟通与协作，这个话题一抛出来，就让我很头大。需求方、产品经理、UIUE、程序、测试之间的烂事儿一大堆。涉及到第三方甚至是几个公司之间而非一个公司内部，那沟通的困难更是雪上加霜。再如果涉及到跟政府部门的协作，那简直就是一场灾难，2012。”点击查看全文

本文未完待续，欢迎朋友们就《设计的协作与沟通》做补充。

相关话题：设计的协作与沟通源地址：http://hx.okvi.com/?p=1151

闲言碎语：沟通三级跳

Lytous — 2010-03-25 22:58:54

第二部分如约而至，继上篇中提到的协同的问题，虽然构架稍微清晰，流程也有针对性的调整，但是在做事的过程中，人和人之间如何打交道还是成败的决定因素。好的事情由于坏的沟通会变得很坏，导致方向的偏差，而坏的事情由于坏的沟通也许会变得很“好”，隐藏了真相与风险，导致问题最终不可收拾。

外面大部分卖的专业书籍中，对于人和人沟通的技巧讲了不少，主要偏重于市井生活的欲拒还迎、官场上的溜须拍马、或者商场上的尔虞我诈，厚黑的概念从一而终不曾改变。但是在我们的设计行业中，沟通的方式多少有点技术化，甚至我可以讲大部分设计师是讨厌勾心斗角，并且嫉恶如仇的，如果沟通一直处于一种灰色的地带，那么潜规则将越演越烈，最终形成对行业和个人的伤害。

那么，严肃而合理的沟通究竟有没有呢？从我自己的经验来看是有的：

1. 沟通的情境

我们经常说的一个词，叫察言观色，这个技术在用户测试与可用性研究中是非常重要的手段，强调研究过程中的观察与分析的要素，而既然我们都是用户体验的从业人员，为何在情境转变以后，又不善于利用这种技术呢？其实在项目管理的过程中，设计师与程序开发工程师、产品经理、市场人员、老板的沟通上都需要“不同的情境不同的沟通方式”。

向上沟通，提供价值 — 和上级领导沟通的时候，如果你希望提出一些需求的话，最好先准备好证明自己价值的材料或工作成绩，作为管理层最不愿意参与的事情莫过于员工的自我管理，如果一个沟通过程（绝大多数情况是某些会议）显得缺乏准备，没有预期效果，那么我建议你最好不要先通知领导参加，否则他只能看到你处理事情上的不成熟。

优秀的技术型领导多半关注真实的数据和行业发展趋势，沟通的基础是你解决了某些问题，发现了某些更好的方案，而这些价值要得以体现必须得到领导的支持，那么他会非常有兴趣。最没有效果的沟通方式是，两个技术人员在领导面前吵架，如果你经历过，你可以回想这样的场面是否给你带来了正面的评价。

平行沟通，注重成效 — 项目UI设计师和软件工程师、WEB设计师与前端开发人员、各部门内部成员之间，这种叫做职能平行关系，这种沟通之间，最重要的就是沟通的成效。缺乏成效的结果是造成信息的衰减，最后影响到不同人员之间的工作量。比如：一个需求的变更，如果没有在第一时间让项目组成员完全了解，就会导致最后一个工作部分的成员积压大量未知的修改和不确定工作内容。

在平行沟通中，为了节约时间和提高效率，大部分人不喜欢使用文档，而这正是沟通失败的主要原因，越是联系紧密，工作成果传递迅速的平行关系成员，越应该建立有效快速的文档迭代体系。这样才能保证在任何一次小的需求变更上都有明确的记录，这个好处一是不能赖账，二是有脉络可循，三是工作量评定很直观。

向下沟通，履行职权 — 工作向下传递的过程中，遇到的阻力往往来自于时间压力还有项目人手的压力，我之前说过的部门墙会在这个时候发挥巨大威力，如果碰上不太踏实的团队和流程，你大可以看到同仇敌忾的场面。这个问题的最简单解决办法就是在项目开展初期，即明确各个部门的职权与关键点的评审责任，比如：页面实现一定要遵守页面设计效果图，代码效率一定不能低于某款产品的标准，软件开发一定要满足交互设计的预研效果…… 确定一个配合的主次关系，再辅以资源支持的范围，利用好话语权决定沟通以外的事情。

2. 沟通的阀值

沟通的阀值是指沟通的心理底线，每个沟通的过程总是会有目的，达到这个目的会影响每个参与沟通的人的心理价位，一般来说，如果你要确定沟通中的有价值的部分，你需要回答四个问题：你的意见或者批评 — “有用的是什么”、“没用的是什么”、“如果这么做，得到什么”、“如果不这么做，失去什么”

如果沟通过程中，你说的话没有解决以上4个问题中的任何一个，那么你说的话基本是废话，没有沟通的必要。

沟通中有句真理：角度决定程度。我们一直提倡换位思考，但有时候换位是没有必要的，也不是非常客观的，换位的本质是希望找到共同的战略目标和利益链，如果你们之间的战略目标有较大的不同，那么换位显得有点假惺惺的多余，这时评价的唯一标准不是妥协，而是找到正确的沟通切入点，以及在做事上的程度。比如：关于设计时间和设计品质之间的取舍，过分追求时间和过分追求品质都是有问题的，切入角度在于品质引起危机，还是时间引起危机，如果客户说1个月不交付就不签单了，那么你还能追求品质最大化么？如果客户支付的成本足够你利用2个月来完成设计，那么就应该投入足够的精力去面对它。

3. 沟通的门槛

减少沟通次数 — 这里说的是减少无意义沟通的次数，有部分产品经理喜欢这么干，确定责任前开会，安排项目前开会，交付周期前开会，质量评审前开会，反正一切都是大家说了算的，出了问题也不能怪到我产品经理的头上 — 这种二百五的作风说好听点是群策群力，说难听点就是为自己的无能找一堆垫背的。请问所有的事情都是大家做的，那么你个人的价值在哪里？

所以，不处在关键节点的会议是不必开的，超过关键节点关注以外的话题是不用讨论的，关于品质和评审的标准是客观的，不需要沟通的。

降低问题难度 — 沟通的基础是沟通的双方（或者多方）都能准确理解对方的意图，因此沟通的过程就是一个稀释问题，解决问题的过程，最好的方式是降低难度，一个关于开发周期确定的问题，可以降低到开发人员配置与项目周期的问题，而开发人员配置可以降低到人员数量和工作时间计算的问题，人员数量的问题可以降低到是不是有资源提供加班补助的问题。

大部分项目推进困难，主要问题就是出在钱的问题还有 成就感 的问题，但是很多佯装高贵的设计师，开发人员，产品经理，就是不愿谈这个直接的话题，反复谈什么企业文化，奉献精神，流程完善、人员经验等。

我不得不告诉你，如果你的成员说这个东西没时间做，潜台词就是“你没有给加班工资”，如果你的成员说这个东西有风险，潜台词就是“你给的钱和职位不足以让我承担这个风险”，如果你的成员说这个东西很简单，可以稍后考虑，潜台词就是“这玩意做得没意思，杀鸡不能用牛刀”，如果你的成员说我们慢慢来，心急吃不了热豆腐，GOOD，他可能准备跳槽了。

提出问题而不是现象 — 大部分沟通峰会，如果你注意观察的话，多数人都乐于提出现象，而不是问题本身，比如: 你们市场部不能老这样提出修改，产品都没做完，为什么要改呢？ — 这个话根本没有说出问题的关键，问题出在为什么市场部可以提频繁的修改需求？谁给的权利？客户的要求由谁过滤的？修改的成本谁来承担？修改不好谁又来负责？是输入问题还是输出问题？

沟通要保证效率，就得在沟通之前准备好真正的问题，围绕问题，提供解决方法，否则沟通就像领导发言一样“李总，你带人把这些问题研究一下，尽快给我结果”，官僚思维带来沟通效率降低。

业界标竿·设计师的悲哀

波希米亚 — 2010-03-25 22:44:28

一个月前，一次需求评审中的争吵，让我开始对这个问题产生了兴趣。到底是什么束缚了设计师的创新？是做一个好的服从者？还是把自己独到的想法应用到产品设计中？

这个问题绝对不是单选！在大公司中体现的尤为突出。来自各方面的制约——各种规范、各部门间的利益、各产品间互通，甚至个人喜好，都对最终产品的诞生起着潜移默化的影响。

在中国，没有几家互联网公司能给设计师很长时间去研究、创造……在这种环境下，我们听到最多的话就是：“某某是这么做的，你就照他那样做……”，“这个功能要加上，某某已经有这个功能了……” 一时间，随着某个产品、功能风起云涌，引得众人纷纷效仿，不久之后的市场上一定百花齐放，个别经典功能随之成了业界公认的标配，成了标竿。在它之后出现的产品，一定要具备前者身上所有特点。

这些需求给设计师提出了新的挑战：如果从一开始就模仿前人，这些设计师是幸运的，要做的就是继续模仿下去；而开始就倔强着，要为自己创造的，对不起，你必须继续艰难地创造下去。这，正是设计师的悲哀。但我坚信后者成功，在独立思考下结合自身特点，量身打造的产品，一定会成为有竞争力的产品，只有这样，才能整合起公司资源。

就拿风头正盛的微博来说，新浪微博的成功并非偶然，它代表了自己的特色和需求。去效仿新浪的微博不会成功，因为他的需求和你的未必一样，所拥有的资源也不尽相同。一定要有自己的特色，不能被标竿累住，今天在老板面前倔强，是为了让你的团队、你的产品在明天的市场上倔强。

踏着别人的脚步前进，超越就无从谈起！

悲哀来源于对产品认识不足、自信心不够，所以总被需求方用业界标竿打压。在基础架构上创新，制造差异化，做有灵魂的产品。团队信心的培养非常重要，让每位成员在自己岗位上都有创新，收获自信，团队才能更有凝聚力。同时，在说服对方之前，先尊重对方，倾听从他的角度出发得出的结论，不要急于否定。

设计的沟通与协作

彭毅 — 2010-03-24 12:13:01

设计的沟通与协作，这个话题一抛出来，就让我很头大。

需求方、产品经理、UIUE、程序、测试之间的烂事儿一大堆。涉及到第三方甚至是几个公司之间而非一个公司内部，那沟通的困难更是雪上加霜。再如果涉及到跟政府部门的协作，那简直就是一场灾难，2012。

即便是内部沟通，考虑到内部利益集团博弈，互相拆台这样的事儿发生，那基本上就完全是无法沟通，只能靠手段去制衡。

所以，真要讨论涉及的沟通与协作，必定要设定一个相对理想的环境，即：大家都是对事不对人，才有可能讨论下去。否则，就要用辩证的具体问题具体分析了。而我下面写的关于沟通的问题，也是基于理想化环境的，因为我是一个产品经理，所以我是站在产品经理角色去理解和处理这些问题的。

沟通、协作是个盘古开天地时就遗留下来的问题，同样，也遗留下来了五件必杀神器：

1：你们有我懂设计吗？
2：这个问题不是现阶段考虑的；
3：这个不一定是问题，是个别人的意见；
4：这个没法实现；
5：这个我们的底层不支持；

这五神器分别被美术、产品、技术捡到。神器一出，秒杀，你郁闷到缩阳也没用了。在UCD珠海书友会上，金山同学第一个问题就是技术使出必杀：这个我们没法实现。

对于五大神器，我实在碰到过很多次，其实必杀可破，只看你愿不愿意。破必杀之法，我归纳为五点：

1、平等对话
美术、技术、测试是我们最重要的工作拍档。对于他们工作所用到的知识，我们要有所涉猎，不用成为行家，但一定要有所了解，最好有自己动手的能力。这样，才能与他们建立平等对话，说出来的话才不会被人轻视，不会被人背地里骂做SB。

如果作为一个产品经理，却不知道自己业务的底层是怎样，基本代码、数据原理是怎样，被人丢必杀技是活该。

引用某前端一句话：“我绝对拒绝与连HTML都不懂的产品经理合作，这是底线。”

2、自己是否想清楚，是否真有必要；

向别人提出需求的时候，一定要想清楚，是否真的要这样，有没有必要。想办法说服别人时，最好能有数据说明你的需求是确有必要的，能缩短用户查询时间、提高装机率、降低卸载率，提高在线时间等。产品经理做好事前分析工作，是对自己工作的尊重，也是对合作拍档的尊重。

拍拍脑袋的决定，最好不要搞。毕竟我们轻描淡写几句话，技术、美术可能就要为你这几句话忙活几天甚至是数周。

3、别人拒绝时，弄清为什么；

关于这一点金山的剑三总监唐洪亮打得比方很好：厕所地上有水，为什么有水？因为笼头滴水，为什么滴水？因为人没关紧，为什么没关紧？因为笼头不是很好关，为什么不好关？因为笼头的设计问题，那为什么要采购这种笼头……

碰到问题，不能退缩，要较真，要去问，要打破砂锅问到底。

程序员有一个信念，这个世界上，没有代码实现不了的事情。如果他说无法实现，一定是他不想。为什么不想，要么是修改成本太高，要么是你的需求他认为根本没必要，要么是他压根看你不爽，八字不合。找出问题根源，然后对症下药，总能解决的。

4、确认别人理解的，是你想说的；

你想的是A,讲出来的是B,别人听成了C，理解后变成D，最后再加工做出来个E,网友一看，说：这傻×公司，做出来个F，就是Fuck的意思。

沟通变成鸡同鸭讲，世界将会怎样？要避免这种情况，所以在沟通之前一定要保证信息对称，需求背景、调研资料、用户数据等，免得你突然说出来一个决定，别人莫名其妙的，怎么沟通？

说完以后，还要确认对方接受了你的信息，并且理解的也是跟你一样。所以需要让他复述给你一遍，就像集结号里面谷子地给团长复述命令，信息发出与接收需要Match一次，确认无误后，这次沟通才算结束。

5、他性格怎样、情绪怎样，你跟他关系好嘛？

一般来讲，解决上面四个问题，报障基本沟通是没有问题的。但比较我们是人，不是机器，所有流程执行完毕，Match一次，确认无误就OK的。人，是会有情绪，会有关系的。所以当需求被拒绝时，还需要考虑人的因素，比如说：股票亏了，老婆跑了，情人吹了，别人发了……等等，这些时候你热着脸去找别人沟通，别人只会给你屁股。

无论你们公司体制怎样完善，找技术、美术等拍档多吃吃饭，一起出去远足什么的，交换一些私人空间，成为朋友，这样有事儿的时候，你能理解我，我能理解我，共建和谐新社会。

至于沟通的泛技巧比如倾听、表达、平等、等，就不在此说了，其实，很多时候碰到的问题，都是制度上的存在问题，如果大家的利益捆绑在一起了，可以解决很多的沟通问题。

以上所列都是平级或跨部门沟通的问题，除此之外，还有与上司沟通的问题，与下属沟通的问题。这就不算设计的沟通与协作范畴了，不过我看到一篇文章，觉得说得不错，简单归纳一下，就是三点：

一、向上沟通没胆：下属向上级沟通时没有胆量，缺乏积极主动性。
二、水平沟通没肺：部门和平级之间沟通缺乏真心，没有肺腑之言。
三、向下沟通没心：上级对下属没有过多的心情或时间进行沟通，不能对下属的移位及时的指导和修正，已造成现在的企业的管理者花去一个月的时间去招聘新人员，不愿抽出2天的时间与下属进行沟通。

说了这么多，再自省一句：任何事情，懂得再多理论，都要注意知行合一。

闲言碎语：协同须有爱

Lytous — 2010-03-22 21:34:08

3月书友会聊了下“设计的协同与沟通”的问题，这算2009年以“互联网产品设计”为主题的活动以后，第一次以开放的设计类话题作为主题的尝试。这次由腾讯的熊松和金蝶的光耀同学进行联合分享，获得了很好的效果，现场解答与讨论了很多设计工作中常见的问题。

对于协同和沟通的事情，我准备分为两篇闲言碎语来说，一是不容易混乱，二是分清楚概念和实施步骤，说到协同这是做的具体方式，说到沟通那是说的高级表现，而两者往往又密不可分，互为因果。所以在具体的操作层面，关于孰轻孰重一直是没有定论的。我今天先聊聊“协同”的问题。

协同工作，我相信任何公司与团队都经常听到，不过一般的理解仅限于“搭膀子干活”或者成立一个什么什么部门，彷佛已经建立了一个协同的环境，有的公司还利用IT工具RUN一些OA系统来帮助协同工作的开展 — 但是呢，其实除了发布一些不痛不痒的公司新闻，流转一些邮件，发布一些会议通知和企业内刊，基本也没对“协同”起到什么作用，该延误的项目一样延误，该吵架的会议一样吵架。

所以说，协同并不是一个系统化的硬件或软件可以解决的，还是要靠人和适合人的制度，它不单是要建立一种协同的精神基础，还有对协同价值的共有认识。其实，协同学早就已经是一门物理学上经过验证的科学方法，我们可以从它的多维应用中找到很多皮毛嫁接到团队合作的模式中。

请客吃饭，按摩捏脚可以建立感情基础，但无法建立价值基础，让一个团队或者跨部门之间拥有共同的价值基础，其根本还是在于提出合理的计划与目标。

公司的大部分活动是以项目方式来驱动的，既然一个项目有其存在的必要，那么一定有它的计划和目标，如果没有目标的东西那么公司不可能投入资源去做，协同工作的第一个要素就是要让参与其中的所有人明确了解什么是这个项目的目标，比如：在3个月内使该产品达到量产标准，在7个工作日内使新首页（完成测试的）上线，在两周内策划完一个新人的中档婚礼（预算3-5万人民币）– 这些都是量化的，准确的目标。如果你发现你们的项目往往不知道什么原因导致项目人员无心恋战，先从项目的目标出发，也许你们根本没有一个准确的目标，才会让项目成员像无头苍蝇般猜测项目的意图。

计划是在目标提出之后的更详细的需求信息，一个完整的需求包含：项目目标、项目时间、参与人员（包含各自职责）、项目周期、项目风险评估、焦点会议、交付物清单、支持资源清单、项目评审方式、流程要点、突发情况预估。我相信有大部分产品经理是无法在项目初期判断出这么多内容的，这取决于从业经验以及个人能力，但是一份简单的PRD，是远远不够的，对于产品的控制与策划，是产品经理需要第一步输出给设计等技术支持部门的内容。

其次，一个协同合作的项目中面对的棘手问题就是部门墙，部门与部门之间有自我圈地意识和保护意识，这是人的本性，所以部门之间的墙越高，则协同的难度越大，效率越低。产品经理或者项目经理在这其中扮演的角色就是打破部门墙的隔阂，通过控制协同节点来调动部门间的积极性，还有交付物的高效传递。现在已有设计过程流转的“成熟的”控制方法，但那种串行的方式目前已不适合大多数追求速度与效率的团队，甚至在其中产生的踢皮球的现象已然成为一种风景。

最有效的节点处理时间出现在上一个部门的交付物已完成，传递到下一个部门之前的时候，如果没有节点的控制和评审，下一个部门为了减低自己的风险和品质压力，会将当前产品出现的所有问题踢回给上一个部门，简单来说，就是“下一个环节部门永远会找上一个环节部门的茬”，比如：结构设计一直会说“你们这个ID怎么设计的，导致我们结构设计的风险很大啊，成本要提高啊”，软件开发会说“你们这个UI设计怎么弄啊，会让我们的工作时间增加啊，项目周期延后了不要怪我们啊”。

在中国的企业中，完全通过流程与制度控制人是不现实的，且不说我们的职业素养还有待提高，就是出于人性和面子，我也不相信那种绝对的理性环境的存在。而协同工作中，对于人性的考虑也是很重要的，这牵涉到组织的文化的力量，项目经理在项目的某些重要阶段或目标达成后，可以向公司申请合理的项目奖金，用于项目组成员的奖励和招待，比如组织活动，旅游，娱乐等，形成一些人际交流的机会，有很多问题确实是可以在饭桌上解决的。另外协同组织的结构也会影响到组织的文化，一个层级式的结构（经理-主管-设计师，并且只能平级沟通）容易造成官僚主义的蔓延，而一个聚合式的结构（项目成员为中心，各部门派出人员组成war group的方式）更容易提高效率和沟通的价值。

是的，一个协同的环境中，也许难免出现极个别滥竽充数的货色，而隐藏在流程的背后，这样的降低效率分子不会这么快的被暴露出来，此时最为担心的往往是项目组的成员，他们在日常工作中深知某些问题人物的存在，却碍于不敢举报的潜规则睁一只眼闭一只眼，那么项目经理这时候需要避免的就是发挥领导力的慈悲，对于个人合作来说，偶尔的一些工作态度问题可以慢慢解决和引导，而在协同工作中这将是一颗定时炸弹，项目经理不仅仅是对项目负责，也要对公司的企业环境与人力资源负责，因为这最终会影响到项目，影响到集体的发展。按照KPI原则和项目中的检验标准为每一个成员设立工作重点，并明确奖惩方式，虽然没有绝对的公平，但我们至少可以做到透明。

最后，息事宁人的软弱作风绝对不适合协同工作的高节奏要求，我们要清楚的是，对于协同有负面影响的人最终会把失败的烙印喷我们一脸……

相关话题：设计的协作与沟通源地址：http://www.ucdchina.com/lytous/?p=2300