为什么大厂高手都说「设计推理」是B端设计师的核心能力？

前言

几年前从 ToC 转到 ToB 时，请教了几位前辈 “什么是 B 端设计师的核心能力”，得到回答最多的是设计推理能力。但有时花了很长一段时间，把方案背景、设计推理过程打磨得“天衣无缝”，结果方案一拿出来，就被劈头盖脸的问题问到怀疑人生。我开始思考，通过逻辑自洽的推理，究竟能不能做出好设计？如果不能，怎么做才能更好？

拓展阅读

设计推理是什么

设计之所以需要推理，是为了让我们在面临复杂的情况时能更好地决策，推理本身是从已知的命题得出新命题的思维过程 ，已知命题是前提，新命题是结论。推理最常见的方法是三段论，举个例子：所有的植物都需要阳光，所有的向日葵都是植物，所以，所有的向日葵都需要阳光。

在工作中，我也经常用上述的三段论推理，比如，在为腾讯云金融远程风控平台定位设计关键词时，推理的逻辑是：所有和金融类产品的体验关键词都是安全，远程风控类产品是金融产品，所以，远程风控平台需要安全感的设计。再比如，我们在手机银行适老化设计中，给了客户更大字体+切换入口的方案。推演逻辑也同样是三段论：大字号能帮助老人识别信息，手机银行需要服务老年群体，所以，手机银行适老版应该采用大字号的设计。

自洽的设计关键词推理

1. 自洽的推理未必合理

上面两个案例的逻辑看上去没有问题，但结合实际场景，远程风控平台是给坐席端和尽调员使用的，尽调工作由原先两人一同前往客户现场变成了一人坐镇后台指挥另一人在客户现场用手机取材，这样的转变对产品 1.0 阶段体验要求应当是“低门槛好上手，方便客户工作习惯的迁移”。而手机银行适老版同样，如果我们在信息架构已经非常复杂的手机银行中，做了切换版本的设计，老年人能否找得到，找到了是否愿意用，都是问题。

银行适老化设计案例：

逻辑自洽的结论，问题出在哪儿。我之前听到一门课上，老师讲到“逻辑自洽的设计并不一定是好的设计”，如果我们仔细推敲由这些逻辑推导出的结论，其实就会发现有问题。

究其原因，本质是一种复杂问题谬误。即在一个推理的前提中，悄悄地置入自己的倾向，甚至结论，这本身就是一种逻辑谬误。比如当问起“你为什么不喜欢张三？”，就包含了不喜欢张三的前提。

同样，“金融类的产品要为用户营造安全感”，这里已经包含了“金融产品必须为用户营造安全感”的结论，但为什么是安全感？并没有做出解答。 这就导致了后续的推理过程，实际上是在一个错误的前提下进行的。

2. 三个思维为你的推理加持

怎么做可以让推理变得更严谨？我们可以尝试跳出现有的思维方式，用另一个视角对推理的合理性进行思考。这就涉及到三个思维方式：批判性思维、结构化思维和故事化思维。

从另一个角度看待推理的合理性

• 批判性思维让推理更严谨
• 结构化思维让推理更系统
• 故事化思维让推理容易接受

我们用这三种思维重新审视前文提到的“远程风控”和“适老版”的设计方案，在远程风控项目中，我们用批判性思维推导出一期的发力点应当在线下尽调习惯的迁移，方便前后端尽调员更容易配合，从这个目标，最终提供了打标记和尽调 SOP 的体验：

尽调 SOP 体验

在适老化虚拟营业厅项目中，我们通过结构化思维，对手机银行的项目进行反思，跳出来加入了普适性设计原则，从而最终为老人用户做了无感的版本切换，并在办理中提供了家人帮忙办和直观的验证指引体验：

适老化的虚拟营业厅

用批判性思维让推理方式更严谨

1. 批判性思维是什么

首先我们要先明确一个概念，批判性思维与逻辑推理的关系。

前文在金融项目中的举例，是以演绎的思维方式，推导出设计发力点，我们可以尝试从他人视角来关注这种思维的局限。当我们向他人呈现出这种方法时，你会发现对方会关注：你的思路是否充分，是否具备了足够的前提和背景，是否定位到了真实的用户并精准抓住了体验需求，在竞品的总结上是否有普适性。对方更关注的是逻辑推导本身的充分性。

但批判性思维不同，批判思维不是逻辑推导，而是 argument，就是跳出来看怎样进行论证是有意义的，怎样推理是更合理的。如果说逻辑推演是过程，那批判性思维更像是一个筛子，帮助我们筛掉一些糟糕的论证。换句话说，批判性思维就是一种针对思考过程的思考。

之所以设计师需要用批判性思维来看待推理过程，本质上是通过完整的思考，让方案更加健壮，因此完整的思考=论题+论证+结论。如果我们希望进一步加强推理能力，就需要能够找到思考过程本身的争议之处，也就是重新定义论题所在，然后通过更多元的论证，找到真正的结论。

批判性思维

2. 使用批判性思维让推理更严谨

重新定义论题

前文提到了三个关键词，论题、论证和结论。我们要先搞清楚各自的定义，首先是论题，尼尔布朗的《学会提问》里，将论题总结成了以下两种：

• 描述型论题。这类论题是在描述一种存在方式，比较客观，不受主观情绪影响。例如：减少转账流程中的点击次数是不是有助于提高用户的使用效率？
• 规定型论题。这类论题提出了什么是对的，什么是错的，受主观情绪影响。例如：在用户使用金融开发工具完成一项任务后，是不是应该有个庆祝的反馈来提升用户体验？

在与同事的合作中，当你直接问：“这样设计究竟想解决什么问题”试图找到论题时，多数情况对方的答案并不能说服你，或者对方无法给你准确的答案。因为在现实生活中，无论是哪种论题，往往无法点明，需要自己寻找。此时，需要设计师自己重新定义论题。有一些方法，例如了解对方的背景，对方所处的组织架构，了解组织对他提出了什么要求。以及你的产品当下面临的阶段萌芽期、成长期、发展期还是平缓期等等。这些方法中，比较常用的是拔高一层找论题。

举个例子，当设计师抛出方案后，经常会面临这样的问题：“这里的细节 xxx，你这样设计的目的是什么？”如果不去重新定义论题，就会陷入直接拿结论讨论的过程，即：我使用了某某专业方法做了这样的设计。讨论到最后，就会演变成，设计师说：“我认为这里没必要。”对方回：“我认为这里有必要。” 这种无意义的争执中。核心的原因就是你没有定位到对方真正想要与你讨论的论题，不在正确的方向上，就会导致无疾而终。

找到论题后再讨论

实际上，无论是客户还是老板提出这个问题时，更多的是需要我们拔高一层去找到真正的论题：

1. 这样设计有没有提升商业目标、产品目标 -商业目标型论题
2. 是否定位到了真正的用户以及他们的诉求 - 用户需求型论题
3. 研发实现成本如何/当下人力是否能实现这个设计 - ROI 型论题
4. 执行层面是否优化一下能有更好的方案 - 方案优化型论题

通常来说，内部的合作团队例如产品、研发更关注的是 1、3、4，外部客户更关注的是 1、2。展开来讲，比如 1，论题就是这样设计的，本质上是为了提升用户转化、DAU，还是你单纯觉得有趣才这样设计的。再比如 2，指的是你这样设计是从满足你自己的需求出发的，还会有真正了解过目标群体，为他们的痛点设计的。

找到论题之后，就有了有效讨论的前提。下一步就是去寻求更多元的论证，关于论证层面所使用的到的思维，会在下面即将提到的结构化思维部分中，我们稍后来讨论。假设我们找到了论题，并且拥有了合理的论证，下一步就是要找到对方真正的结论。

寻找真正的结论

要找到结论是什么，要先明确对方抛出来的是结论还是观点。结论是推理出来的，需要一个个观点支撑，如果对方断言某件事是真实的，却没有提供相应的陈述来支撑，可以说这个是观点，反之则可以是结论。

观点和结论

按照结论做设计，会比按照观点做设计更加精准。

以助农网点项目中遇到的问题举例，当时我们接到一个反馈是：“小程序里每个模块跳转不要太多，最好不要超过 3 层，否则会让页面显得很复杂。”这就是一个明显的观点，因为其没有相关的支撑。经过讨论，我们重新组织了这个需求，找到了真正的结论：“小程序里每个模块跳转不要太多，最好不要超过 3 层，因为客户经理每天需要并行的业务较多，加上小程序已有的功能超过了 30 项，所以希望体验上能更加轻量。” 这样的结论让我们在最终的设计上，提供了数据导向的框架+穿梭窗的设计，确保客户经理打开小程序时以及使用功能中，能够不被复杂的信息架构和流程所扰。

从观点出发的思路

从结论出发的思路

从结论出发给出解决方案

设计师在平时推导结论的过程中，可以关注以下关键词：因此、表明、由此可知、由此得出、因此可以判定、显示出、证明、告诉我们、问题的实质是等，这些关键词更加贴近结论。

当然，也要注意避免一些常见错误，例如

• “我之前的经验看客户经理应该这么想”- 偏概全谬误
• “抖音设计了沉浸式上下滑动的体验非常成功，所以这种极简的体验是能帮助产品成功的” - 典型案例谬误
• “很多设计大师都讲少即是多，所以这种设计理念也应该被应用在产品中” - 当事人证言谬误

谨防数据的谬误

有一个谬误值得大家关注，就是数据谬误，我在工作中也经常会犯这样的错误，当你希望通过数据来佐证设计是否合理时，就可能被数据绕进去，总结起来有以下几种：

批判性思维-数据的谬误

不明来历的数据

例如：40%的用户打开银行 App 时，只使用了转账和查明细 2 项功能。

在设计手机银行的信息架构时，坚定地相信了这项数据。但如果仔细思考，你会怀疑：给出数据的人是如何得出这个数据的？这里的样本量是多少？统计的用户画像是什么？多少人是高频用户？等等。不明来历的数字也会容易将我们带跑偏。

平均值与中位数的混淆

例如：使用我们产品用户平均年收入在 200 万以上，所以品牌调性可以尽量往高端定位。

这里使用到了平均这个词，但实际上却有三种不同的方法来测定平均值。

• 第一种方法就是把所有数值相加，然后用总数去除，得出的结果就是平均数。
• 第二种方法是将所有的数值排序，找到位于最中间的数值，这个中间数值就是中位数。
• 第三种方法是统计每个不同数值（或一个数值范围）出现的频次，出现频率最高的叫众数。

上面的案例采用了平均数的计算方法，将高端用户一并算入其中，这样会拉高平均数，而对于我们真正希望抓住的目标用户，也就是占比较多众数而言，影响却不大。

用 A 的结论证明 B

举个我们在远程风控产品调研中遇到的例子：作为尽调员，需要判断借款公司的资质是否与其提供的一致，当现场尽调时，十有八九拿到的报告数据都与实际有偏差。我们之前统计过，因为数据偏差导致最终额度批准过高的概率是 n%。无论这个数据多高，都只证明了一件事，即多数尽调员首次现场收集的数据都不准确。但不能推导出额度批准过高，是由数据偏差导致的。要回答这个问题，可以问：“批准额度的整体流程是什么，除了报告数据，是否还有其他的因素导致这个结果？”进而找到 B 真正的结论。

绝对数值的欺骗

例如：之前问朋友对老家郑州这几年变化的印象，经常得到的一个答案是越来越像文化荒漠了。我继续问为什么？有位朋友的答案很有意思：“比如啊，城市不断有新公司出现，把市区里的那种人文气息赶跑了。就在去年，城里的公司数目增长了 75%。”75%很吸引眼球，但是这里缺少了一些东西：百分比所依据的绝对数值。假如我们知道这种增长是从 4 家到 7 家，而不是 12 家到 21 家，就会对结果有所改观。

以上就是我对批判性思维的理解，借助它可以让我们已有的推理逻辑变得更强。

用结构化思维让推理方式更系统

1. 为什么要用结构化思维

先搞清楚结构化思维的定义。回到文章开头的案例：所有的老人随着年龄增长，都会出现视力下降的症状，所有的产品都做了放大字体切换版本的设计，所以，所有的适老版设计都是放大的设计。

在这个案例中我发现，当我开始设计前，会习惯性地使用演绎法，来定位设计机会点，似乎有一个思维定式让我不由自主地想去使用它，这是为什么？

我在加里·梅哈尔的猴子定律中找到了原因，将 5 只猴子放在 1 个笼子里，并在笼子中间吊上一串香蕉，只要有猴子伸手去拿，就拿高压水枪教训所有的猴子，直到没有猴子敢动手。此时，当实验人员用一只新猴子来替换笼里的猴子时，这只猴子就想伸手去拿香蕉，结果被其他 4 只一顿 K。实验人员替换了几次，猴子发现不去拿香蕉就不会被喷，感受到了这个规矩的好处，于是这里形成了一种”不许拿香蕉“的思维方式。

我们起初参加工作时，脑子里带着一堆的思维方式进入职场，在多次的摔打后，形成了一种有效的思维方式，然后会不断用这种方式处理大部分信息，将这种思维方式本身带来的红利最大化。这也就是为什么，当我开展设计时，通常都会习惯用演绎法来推理设计目标。这个过程看似是一种推理，实际上也是一种固化的思维方式，如果我们希望在推理中变得更强，就需要掌握多种思维方式，在不同的情境中灵活运用。

2. 怎么使用结构化思维丰富推理方式

如果进一步定义，结构化思维=多种思考有序地搭配或排列组合，所形成的一套推理系统。

之前我在做手机银行项目时请教过一位用研大咖：可用性测试的样本有限，如何确保结论的可靠性？他的回答是：不要只把目标聚焦在手机银行用户，可以扩大样本到业务经理。其实这个就是结构化思维，通过扩大样本量对结果做交叉验证，确保结论的有效性。不只单一固定的某种推理方式，而是将多种思考推理系统地搭配使用。

结构化思维

我们曾参与过一款项目金融开发平台，主要是帮助银行等金融机构开发移动 App。按照推理，我们将设计目标定位在了如何带给用户安全感。除了用演绎推导之外，我们还尝试了工单分析进行交叉验证，来重新定位客户所关注的是不是安全。分析过去 1 年的工单，将工单类型做归类，就会发现功能数据报表的全面性、帮助文档的易用性、功能说明的简单性，这些都是客户关注的问题，并非简单的安全感，为此我们提供了相应的设计方案。

产品的易用性设计

除了工单分析之外，有很多种方法例如第一性原理、客户体验地图、客户转化地图、SWOT 等，这里就不展开细讲。重点是当我们在推理时，要使用结构化思维让推理结论变得更加健壮。

但到了这里，仍然有一个困扰我的问题，要用更多的方法来佐证推理，那么方法有很多，像演绎、归纳、体验地图等，但这些方法在真正的实战中，更像是一个个零散的点，他们之间的关系是什么？怎么形成一种结构？

3. 结构化思维的结构

其实总结来看，归纳和演绎是认识事物的方法，当你认识事物后，金字塔模型就是你思考问题的思维结构，但光有了结构还不行，需要结合不同的场景运用，这些具体的运用，就是我们经常提到的客户转化地图、流程思维、故事思维等。就是说，当我们掌握了归纳和演绎以及金字塔模型后，可以自己生长出很多上层思维运用。

思维结构

关于这几个思维模型在设计项目中的运用，后续也会单独开一篇《用推理为设计加持-思维模型运用》来和大家讨论。确保思维的完整性可以用 MECE 法检查，即各个要素之间不能有交叉，也不能有遗漏，相互独立，完全穷尽。

产品思维介绍：

例如：用户不使用，可以拆解为外部原因、内部原因，外部原因可以接续拆解为环境、手机、App 性能；内部原因可以继续拆解为需求未满足、觉得产品 low。

这样去拆解，你就可以从一个更加全面的维度去审视推理过程。

用故事化思维让推理容易接受

对于 B 端设计师来说，设计的对象由 C 变成 B，由内部产品团队变为外部客户，外部客户在对方领域是专家，但由于工作经历、行业的差异，大多数客户很难坐下来，像内部团队一样开需求评审会，花时间听你的分析逻辑，我们可以通过故事化思维，把你的逻辑更有效地让对方接受。

1. 故事化的思维是什么

要向不同知识背景的客户阐述你的设计推理，就需要将枯燥、理性的推理转变成对方可以接受的形式 ，也就是我们经常说到的“提案”。

2. 怎么使用故事化思维让推理更易接受

什么才是客户能接受的方式？首先，我们的大脑都是亲近清晰而疏远含糊的。故事，就是把复杂的信息安排地井然有序，从而让大脑更好地接受。那具体应该怎么做，ToC 和 ToB 的环境差异较大，这里以 ToB 面对客户的场景举例。基础逻辑可以分为以下几步：

故事化思维框架

1. 立一个主人公；
2. 主人公遭遇了一个问题；
3. 此时向导出现了；
4. 为主人公提供一套方案；
5. 帮他避免失败；
6. 最终获得成功；
7. 召唤他采取行动；

例如我们在和几个客户的提案中，从开始即定位成客户为本次的故事的主人公（1），在 PPT 的第 2 页就直接亮出问题（2），随即就讲在解决这个问题中，腾讯能带来什么，扮演的角色是什么（3），接下来就是方案（4），方案讲解完毕后，另起了一趴去讲在过程中可能会遇到的风险以及我们如何规避（5），在结束前，将最终合作后所带来的效益与客户同步（6），最后，引导客户采取下一步行动（7）。最终的效果都很不错，成功地拿到了合作。

这里在过程中要注意几个问题：

• 精准定位客户遭遇的问题。说服的有效性取决于（2），主人公遭遇的问题其实要在一开始就定位清楚。设想一下，如果你对一个客户提案，前 5 分钟连对方的问题是什么都没有精准定位，那剩下的时间基本就是灾难了。作为设计师，我们可以通过售前反馈、市场报告、用户问卷/访谈、竞品分析等方法，确保我们定位的问题是精准的。
• 我们扮演的角色是向导而非主人公。主人公式的表述会导致客户缺少参与感，从而最终导致合作失败。所以要注意我们的定位是向导，而非主人公。
• 在结尾要引导客户采取行动。阐述方案后要有明确的下一步计划，抛一个合作的方式，引导客户采取行动而不是仅仅是停留在方案交流。

总结

批判性思维、结构化思维、故事化思维，这三者在设计推理过程中必不可少，在有限的时间里，设计师可以关注故事化思维，确保推理过程能有效地传递。在平时项目之余，可以多关注结构化思维，搭建自己的思维弹药库，项目紧张时可以拿出来使用。在项目进程中，当你推理出一个设计发力点时，也可以尝试使用批判性思维，跳出来对思考过程进行思考。

本文没有触及推理本身，而是希望能换一个视角，对推理过程进行思考。设计推理是一个长期的命题，也是构成设计师核心价值的底层能力之一，里面的课题还有很多，本篇作为一个开端，后续也希望能继续完成这一系列

• 《用推理为设计加持》（本文）
• 《思维模型运用》
• 《故事化的迷人之处》

以上内容仅为我作为 ToB 交互设计师这几年的思考，如有谬误欢迎指正探讨，也希望能和更多同学共同探索，一并前行。

参考资料

1. M Neil Browne and Keeley, S.M. (1981). Asking the right questions. Englewood Cliffs, N.J.: Prentice-Hall.
2. Miller, D. (2017). Building a storybrand : clarify your message so customers will listen. New York: Harpercollins Leadership, An Imprint Of Harpercollins.
3. 叶修(2020). 学习的逻辑 . 中信出版社
4. Page, S.E. (2018). The model thinker : what you need to know to make data work for you. New York: Basic Books.
5. Sherwin, D. (2012). Success by design : the essential business reference for designers. Cincinnati, Ohio: How Design ; Newton Abbot.7
6. 张建军, 2014. 逻辑学导论 , 中国人民大学出版社.

欢迎关注作者微信公众号：「腾讯设计族」