产品经理如何优雅地与设计师沟通？

作者：Chris Vander Mey

来源：UI中国

本文摘自《谷歌和亚马逊如何做产品》，人民邮电出版社，2014年6月1日。本书当当、京东和亚马逊均有销售。

▍如何优雅地与设计师沟通？

设计师的工作很不容易，因为每个人对设计都有自己的观点。也正因这个原因，设计师很少会被当做专家来对待。然而要是把他们当做专家来对待，并专注于问一些得体的问题，你就能驱动他们交付一份极高质量的设计并帮助他们建立工作的主人翁意识。不过每个人都有不同的工作方式，设计师也一样。有些设计师会比旁人更敏感一些，有些设计师则要宽容许多。有些设计师也许乐于听到“感觉有点挤”这类评价，有些设计师要是听到你这样说会恨不得重击你一拳。所以请听取下方的沟通建议并做些变通，以迎合每一位独一无二的设计师。

▍以用户的口吻说话

反馈意见时使用“作为【某种用户类型】我想……”这样的开头非常有效，Scrum项目管理方法就是使用这套句式来创建“用户故事”以指导开发者编码。

▍以提问的方式建立公式

例如，你可能问：“iOS中后退按钮有什么惯例吗？这个惯例是一致的吗？”你的目的不是让他们详细地讲述这个体验，而是通过问这个问题来使双方建立对设计原理的共识，你的团队将根据这个共识来形成具体的设计。

▍不断强调目标优先级

帮助设计师了解他必须解决的问题是什么。设计师们每天要做出上千个决策，他们根据自身丰富的经验来优化产品。你能够帮得上忙的便是确保他们能理解你的目标。为此，要将目标具象化。例如：“不应该要求大部分用户去滚动页面。因此，我们应该把输入框放在折线上方，对吗？”

避免设置主观目标也能帮助你的团队。像“用户需要在应用中体验到家的感觉”或“它需要让人感觉更友好一些”这类目标会让我感到不安。你怎么知道你已经达成目标了呢？是在可用性测试的参与者表露出了这种感觉并还小憩了一会的时候吗？不要提这样的目标，你应该寻找导致这类设计问题的根本原因。例如：“我们正在要求用户在没看到任何价值之前就得在首页支付10美元。我们得想出一个替代目前体验的方案来，让用户先了解我们会提供给他们什么价值，而不是先填写信用卡信息。”

▍用数据说话

统计用户点击数、浏览屏幕的数量和页面加载时间可使交流更为具象。应积极开展可用性测试。同上条一样，不要说些主观的东西，比如以“这感觉……”或“我喜欢……”开头的句子。

▍提供一些竞品的优秀案例

与设计师分析竞争对手的体验将帮助你创建一套集大成的设计语言。你也可以让用户体验研究者去考察其他竞争产品，并分析行业内的最佳实践。

▍如果发生冲突了该如何化解？

你需要借以达成卓越共识的工具是冲突管理。我们从一开始就可断言一定会有大量的讨厌鬼存在，他们会制造冲突。你甚至可以认为和你一起工作的是一群独一无二的讨厌鬼、白痴和只顾自己的傻瓜。不过由于你是在软件行业，所以出现这种情况的可能性相当之小。更可能的是和你一起工作的都是拥有超低沟通能力和极高专业能力的人们。

“但是等等，”你可能说，“我和产品经理、工程副总裁以及设计师们一起工作，他们的沟通能力肯定不差！”所以他们必定是讨厌鬼（只是玩笑）。你可能是对的。更可能的是，这些人已经非常习惯和工程师以及你这样的家伙打交道，所以他们非常缺乏信心，担心你们会打乱他们的意图。这些人也会关心交付。也许他们关心的程度不如你，但他们的关心程度足以让他们害怕你会更改其设计、目标或质疑他们的决策以至于他们不得不进行调整。

管理专家托尼·施瓦茨曾写道，在这种情况下，你需要脑补出一个不一样的背景情况。这里的背景情况是指你脑补出来的用以解释某些人奇怪行为的理由。但它终究只是一个臆想，一个建立在假设上的臆想。不要假设这场冲突的另外一方一定就是一个讨厌鬼，考虑另外一些可能的背景情况。

举个例子。刚加入谷歌地图团队时，我被设计团队搞得真心恼火。他们看起来聪明而友好，但我不断被他们气得想撞墙。当我问一些常规问题时，如“你要解决的用户问题是什么”，他们会回答说：“我们设计的目标是‘地图即用户界面’。你还是多花点时间去和其他产品经理聊吧。”

于是我倾向于认为地图的设计师们都是白痴，因为“地图即用户界面”不是一个设计目标，它对用户没有任何帮助。直到有次我一边喝着白葡萄酒一边吐槽时，我的一个设计师朋友给我讲述了一个不一样的背景情况。“他们没有业务目标，”他说，“就因为这个，他们被人随意抱怨了好多年，于是他们不得不凭借自己的力量来设法完成那些本该由你完成的工作。他们发明了一套组织原则来承受这些来自任意副总裁的任意微不足道的抱怨。而且他们可能把你当成又一个要抱怨的副总裁了。”

我知道不是天天都有朋友给你提供非凡的洞见，但你还是有办法来得到同样的结果并省下买葡萄酒的钱。你只要这样说：“的确我脑补出来的背景情况是他们都是白痴，但我实际没有IQ分数来支持这一点。也许真正的背景情况是上一个副总裁给了他们一个极不靠谱的目标，然后他们设法实现它，在这种情况下，他们捍卫这个目标是说得通的。”

如果你脑补出另一些可能的背景情况，你就能以更积极的心态来应对冲突。等到你相信你所面对的家伙不一定是个讨厌鬼时，你就能找到问题的根源。90%的情况下冲突的根源都是沟通不畅。另外10%中有1%是因为你面对的的确是个讨厌鬼，剩下9%是因为目标的方向错了。

▍必须问清楚对方究竟想要什么

你真正需要了解的只是那90%的情况，你和对方在“各说各的”。换句话说，你们对重要的事情达成了共识但却纠缠在一些细节或措词问题上。我发现当工程师和工程经理真的关心某件较大的事情时，他们会经常把焦点放在细节上，如不要写重复的代码等，毕竟细节更容易被具象化。由于你知道这时你们有很大可能在各说各的，你便可以回到上一步并问问自己其他人真正想说的是什么。这是第一步。

一旦确定你们正在各说各的，你便可以借此机会建立一个通用的术语表，这样你们在讨论中就不会因为措词问题而导致沟通不畅。为了做这件事，你需要知道工程师和他们的团队经常会给同一个单词赋予不同的意思。在一个团队中“hack”可能是指一件可怕、危险的事情，在另一个团队“hack”却可能指一个不错的捷径。再比如我在谷歌地图团队时发现“地标”这个常见单词可能指的是一整类事物（酒店、旅馆和埃菲尔铁塔），而不单指埃菲尔铁塔这种事物，他们把埃菲尔铁塔这种事物单独称作“游览胜地”。这种概括和命名的惯例在软件行业合情合理，它就是软件的工作方式——以抽象的对象为基础并为这些对象添加属性以使之具体。因此，团队开发他们自己的专用语言是非常常见并完全合理的。

不过值得庆幸的是解决分类问题并不难。你可以说：“不好意思，为了确保我们在同一个频道上，我想问下你所说的‘地标’指的是什么？”工程团队将非常高兴地解释它们，因为他们喜欢定义东西。这也是他们从事编程的原因之一。

▍说人话

即使你们使用了同样的单词来代表同样的意思，也可能因为其中一方并不完全了解交流的背景而“各说各的”。与你共事的非工程师同事大多都在同时操心多个项目。 他们并非一定要知道你为什么讨论这个话题，你也并非一定要知道为什么他们正变成一个蠢货。回到上一步，说：“我觉得我们可能在各说各的。”然后接收或者提供背景信息。例如：

为了确保我们在同一个频道上，我在这里先讲一点背景。我们正试着构建一个针对盲人用户的文本转语音的应用程序。不幸的是，我们想在消费电子展上发布，这意味着有一个硬性时限。而且我们的目标用户是盲人，所以我们不得不做些艰难的决策和优化。这样说你能理解吗？

这个例子披露了两个关键且常见的背景元素。第一，时间总是一个挑战，清晰地说明时间上的限制有助于其他人了解什么是可能做到的。不相信时间会成为一个问题？让一个朋友打两个中等复杂的结，然后你和另一个朋友蒙着眼睛去解开这两个结，整个过程不准说话。再重新这项任务，不过要在1分钟内完成。你会深刻感受到这两次过程的不同之处，第二次你很可能遭遇一些令人心烦的、非语言的冲突，因此挑战虽然一样，但时限上的压力会让一切会变得更为糟糕。

第二，常常有一些别人并不知道的假设或者别人自己做出的假设。在这个例子中，设计的目标群体是盲人用户，这类用户的需求和一个典型的文本转语音的用户是不同的。当你给团队成员介绍背景时确保梳理出这些假设，因为它们常常会导致沟通不畅。

再补充一点，请设法确保你的项目名称在产品的整个生命周期中是一致的，否则你会让那些不知情的人们感到迷惑。如果你在一家小公司改名字可能无所谓，但在大公司就有问题。重新命名项目带来的收益很少能超过由此带来的沟通不畅所增加的成本。你还会因此而买更多的止头痛药埃克塞德林。

有时候别人听不懂你说的话，而你企图通过分类法和背景介绍来澄清它们也遭遇抵制或让人丧气时，请转向白板。因为这个原因，我总是把一面大的白板放在桌子旁。我发现图画和列表能使事物变得清晰。通过写下你所讲述的内容，别人就能把注意力集中在白板的图画或文字上，而不是随风逝去的音节。这个技巧虽然简单，但极其实用。

然而有时冲突并非由明显的沟通不畅或根本的观点分歧导致的。当有人戳中你不想被别人戳中的地方时冲突也会产生。你之所以知道你被戳中是因为你产生了打这个家伙一拳或逃离现场的冲动。这是一个经典的战斗或逃跑的反应。当有人戳中你时，请花整整一分钟的时间来想清楚刚刚发生了什么。然后停下来，说：“哼。”60秒后你分泌出来的肾上腺素才会开始被身体吸收，20分钟后才会被完全吸收。因此，不做任何事情并静止60秒将使你有时间避免从房间逃离或者采取报复行动。

如果想要更好地控制每个人都会有的强烈的情绪反应，你需要先识别出是什么引发了这样一个反应。是人们叫你孩童时期的小名来激怒你，还是工程师对你专业判断的质疑让你着实恼火？不管具体导火索是什么，请暗示自己当被戳中敏感点时，你将得到了一个控制自己反应的机会，你需要努力让自己的反应恢复原状。这样下去久而久之你就不会那么敏感了。

虽然你可以管理自己的情绪反应，但因为软件工作强度很高所以偶尔发发脾气是很正常的。大部分人们为自己的产品加班加点地工作，因而对于他们的心血结晶都格外维护。所以无须惊讶他们的情绪会很强烈，你最好马上接受这个现实：惹恼他们是不可避免的，尤其在你设法交付的时候。但如果你能客观地进行交流，也许可以减少惹恼他们的次数。

客观地交流是指只围绕软件、用户或问题进行讨论，而不把人牵扯进来。日常你可以使用一些有效的方法来帮助确保你交流的客观性并增加拿到一个没有压力的结果的可能性。我最钟爱的三个客观化的方法是：

• 不说“你”或“我”。

• 聚焦在角色模型上，而不是人上。

• 使用客观指标。

欢迎给馒头商学院投稿

投稿邮箱

tougao@mtedu.com