编辑导语：我们在平常工作中跟别人交流，怎么样能让对方准确快速的get到你的点呢？特别是设计师在表达自己的想法时，怎么样能让对方快速理解；本文作者分享了几个让别人一下就能明白你的设计的方法，我们一起来看一下。

一、前言

身为设计师，我们日常工作中经常会遇到各式各样的挑战，业务方的、老板的……我们也会经常地有疑问啊，有没有什么套路可以让别人更快地明白自己设计方案的要点，并且满足他的预期呢？

那今天就想分享一下，一些设计的套路儿，目的是设计师如何让别人快速明白你的设计心思。

不过呢，虽然说今天分享的是套路，但还是要说一句，套路不等于真理，因为真理是终极奥义。

所谓套路只是提供一种思路，所以套路不是万试万灵的，但是多数情况下不会出错。

我们最终的目标，是希望这些套路，最后能帮助大家做到设计的每个环节都“完美无缺”，做到自己明明白白，别人也明明白白。

设计从环节上来说，包括“想”、“做”、“说”，希望今天分享最终达到的结果是：我们想出来、做出来、说出来的东西，自己明白，别人明白，老板也明白且满意。

而不会出现经典明学的认知分歧：“我不要你觉得，我只要我觉得”。

二、怎么做

具体要怎么做呢？这里引入一个东西，叫思维框架。

它的意思是每个人都基于不同的认知框架来认知事物，这个认知框架就是思维框架。如果两个人的思维框架一致，那他们就可以快速地理解对方，在同一个频道说话。

含义是比较抽象的，具体来说：也可以理解为我们常说的共识，但是共识是经过讨论而达成的，思维框架有的时候是不需要讨论，它是我们约定俗成的思维模式。

思维框架最早来源于认知心理学，认知心理学的主要代表人物有美国科学家纽厄尔、西蒙。

他们的核心理论输出是认知模型，它的含义是说：人脑其实是一个类似于计算机的信息加工系统，它会对外界信息进行处理和加工，最终输出；这个处理过的信息，表现出来，就是思维框架。

首先我们会接收外界刺激，这个信息输入到了我们脑子里面，我们大脑对这个信息进行加工处理后，就会形成一个范式（它就是思维框架），并且固化了下来。

它代表的是我们怎么组织和理解一个事物，而当外部有一个刺激，比如处理某件事情的时候，我们就会调用已有的框架；在调用的过程中，如果大家的框架是一致的，那对事情的看法就可以很快达成一致。

举一些例子，我们很多思维框架是从接受九年义务教育就开始的，比如如果我和你讨论“三角形”，我们都形成过统一的思维框架，那就很高效地沟通了，都知道是锐角、直角、钝角三角形等等。

我们甚至有的时候还人为设定思维框架，把大家的认知放在同一水平。

比如我们的企业文化的价值观，就是思维框架的一种表现，我们做的事情，都不能跳出这个框架之中。

很多时候我们和别人的分歧，多数都在于思维框架的不同而导致。

我们今天分享的套路，就是希望总结我们常用的思维框架，别人一下子就能get到你的内容。

我们要做的，就是在每个设计环节，快速调取思维框架，特别是老板认识的思维框架，来达到大家同在一个频道的目的。

这也是为什么身为设计师，要掌握产品思维，因为我们的老板就是产品思维，它就是建立在产品思维框架下；而调取的这些框架，能够快速让老板明白你的心思，这些框架就是我们常说的套路。

1. 想的框架：问题与解决

那我们先来套路一，第一个框架。

在想的这一步，思维框架就是问题解决的框架，发现问题、分析问题、解决问题、验证问题；这是大家约定俗成的规则。

这个思维框架最原始的来源，其实是科学研究基本逻辑。

我们大学时候讲授科学研究的通识课，都会优先讲授这个方法论，它是学科的基础。

这个框架基本上影响了我们工作生活方方面面，从我们学习解数学题开始，到我们现在工作，这个框架都伴随我们，基本上无从挑战。

现在整个互联网行业建立的规则，都是基于科学角度解决问题；可以有99.9%信心地说，我们用这个框架可以和老板，甚至其他任何同事沟通，都能达成共识。

这个框架在某些商业领域被调整过，比如麦肯锡，他就在原有基础上，有过调整，产生了解决问题的7大步骤。

To C领域大部分产品经理、老板都是经过MBA培训的，这个框架也可以99.9%的信心说，他在大家脑海里形成思维框架。

所以说，我们很多时候就老老实实把“发现问题、分析问题、解决问题”这个框架用来思考，就能很好地让大家达成一致共识。

然而我们工作中，就有不少同学，他这个思考过程都没有好好理顺，就开始讨论方法论，只会让大家觉得你逻辑不严谨、业务能力不足。

举一个例子，它是我们在做vivo钱包APP的一个需求，它的目的是让用户生成桌面图标。

最开始的时候，它的问题和解决描述是这样的：

其实我们仔细读多几次，就能发现其中的逻辑问题。

首先问题本身没有问题，现在生成了桌面图标占比很低，意思没多少人生成，或者是没达到预期。

但是原因这里就有问题了，它其实是讲了另外一个问题；下面这个可以算作原因，能形成因果关系，因为入口深嘛，所以用户不知道去生成。

最后措施这里又对应不上了，它讲的是措施C了。

我们原因是设置入口太深，那措施是不是应该描述成让它更浅一点。

深浅是反义词嘛，符合我们单命题的逻辑。

那要怎么改呢？这里改动后的描述，我们再仔细看看，这里的逻辑对应关系就清晰了很多。

问题是，我们现在生成率好低。

为什么啊？因为本身入口很深，又没有引导用户去生成。

那要怎么做啊？那就增加引导好了。

有无就是一对反义词。

我们看看它内在逻辑的示意，就比原来清晰了很多。

2. 做的框架：金字塔结构与逻辑图表

想完了就要做出来，这里要介绍的套路就是逻辑呈现，它锁定在两个套路：一个是写作套路，金字塔原理、一个是逻辑图表，信息可视化表达。

而这一整套套路的来源就是麦肯锡的书籍，同样的这套是MBA框架，To C领域大部分产品经理、老板都是经过MBA培训的，这个框架也可以99.9%的信心说，他在大家脑海里形成思维框架。

我们日常工作中需要经常遇到需要书面呈现的场景，比如设计提案、设计的竞品分析报告、设计规划、设计总结……这些都是和其他人静态交流的场景。

而我们需要想的就是，怎么做出来，让别人一下子就明白你的要点。

比如提案类，所谓逻辑呈现，更多时候其实我们老老实实把发现问题、分析问题、解决问题的整个逻辑表达出来，就已经足够了。

举一个例子，这是某次vivo钱包APP首页改版，如果用“发现问题、分析问题、解决问题”的逻辑老老实实地呈现，它的思路是这样的：

这样已经符合大部分人的思维框架。

除此以外，我们可以用更可视化的方式，让整个呈现更加直接。

而这种方式，如果引申的话，额可以扩展很久，我们以后再详细展开。

3. 说的框架：演讲与表达

那我们开始第三个套路，说的套路。

“说”的思维框架，事实上就是讲故事的框架，说这一部分还真的不好传授，因为它和沟通一样，它是一门艺术，需要不断地实践。

我今天只分享一些技巧：怎么说好你的方案，给别人说出你的设计观点。

前面两个套路都是在内容层面的，说的部分就更多在技术和形式层面了。

面向不同人群、面对不同场合、针对不同目标，说的套路也有所不同。

但是无非两个：重内容的场景，那我们更多时候老老实实地表达即可；重表达的场景，那我们需要更多情绪进来，以及要想办法营造别人的情绪。

我们工作中重内容的场景，比如和业务方进行设计提案，它的目的是阐述观点和方案，收集大家的意见。

那就老老实实进行观点阐述即可，把你前面“发现问题、分析问题、解决问题”的思路向别人老实地阐述；语气、感情……这些形式都不是重点，保证声音足够、表达清晰即可。

而我们工作中有些是重表达的场合，比如设计总结和汇报的场合（当然每个团队、每个老板的口味不一样，具体情况具体分析），它就是要阐述你的成绩，那就要在内容保证的情况下，也要学会加入一些形式，让听众被感染。

它的核心是怎么讲好一个故事，渲染观众情绪。

哈佛大学人工智能实验室，通过机器学习的方式，把哈佛大学里面的所有藏品进行分析，对人类古今中外所有的故事进行过总结，发现主流的故事情绪渲染有四种类型：辛德瑞拉式、振荡式、罗密欧朱丽叶式、欧亨利式。

• 辛德瑞拉式：就是典型的喜剧，情绪上扬，有的故事过程中有一些波折，但是整体是向上；比如周星驰的各类电影，现在看过的各种喜剧，或者是大团圆结局的故事。
• 罗密欧朱丽叶式：就是典型的悲剧，过程中可能有起伏，但是整体情绪是向下的。我们看过的所有悲剧，基本上都来自于这个框架；比如这个电影飞越疯人院。
• 振荡式：是高潮迭起的故事，他不一定是喜剧或者悲剧，但是过程是不断高潮迭起的，由多个情绪组组成的；典型的就是权力的游戏、甄嬛传啊等等，有不断的起伏。
• 欧亨利式：也不一定是喜剧悲剧，它就是铺陈很久的情绪，然后最终来个出乎意料的结局；比如我们看过的电影七宗罪、第六感等等，大家在Google和百度上搜“出人意料结局的电影”作为关键词，都能看到很多类似的电影。

在我们具体说设计的时候，主流一般会用前面两个。

悲剧式的情绪负面，我们一般不会演讲时候说；欧亨利式需要很长的铺垫，前面铺垫太久大家都累了，都不想听你BB了，很少用。

所以，我们在阐述的时候：从内容上来说，要铺排几个高潮点，渲染情绪；从形式上，要学会适度地通过声音、语气、肢体语言，在需要情绪爆发的时候，把我们需要渲染的情绪重点凸显出来。

三、总结

最后总结一下，身为设计师，我们的套路是：我们要做的，就是在每个设计环节，快速调取思维框架，特别是老板认识的思维框架，来达到大家同在一个频道的目的。

想的环节，用解决问题的框架；做的环节，用逻辑呈现的框架；说的环节，用讲故事的框架。

这就是今天分享的内容，通过这样的“套路”，能够快速让别人理解你的设计重点。

当然最最最最重要的还是，虽然我们说套路，但是，真诚比套路更重要。

作者：陈正熙，公众号：VMIC UED

本文由 @VMIC UED 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自unsplash，基于 CC0 协议