同一个设计稿，为什么别人就能说服甲方？

一直想跟大家分享我所理解的设计中的逻辑学。为什么想讲这个？一来是因为在日常与同事交流工作的过程中经常收到类似「真佩服你能把屁大点事扯出这么多道理」、「评审时你解释的条理可真是清晰」的评价，可能大家觉得我在论述方面确实有所擅长；二来要把人们感情化处理事情、做出决定的感性思维用文字表达，难度实在太大，我只能试着先给大家谈一谈如何运用简单的逻辑思维在设计中思考、辨析和表达。

先给大家讲个生活中的故事。

前段时间我搬新房的时候家里仍有很多设施不全，我就考虑需要准备些什么。首先新房需要空气净化器、炭包，客厅还得买个电视。要是周末做个饭，厨房的油盐酱醋也得备上。卫生间的洁厕灵、马桶刷以及浴室窗帘也是缺的，布艺沙发时间一长会被弄脏不易清洗，得提前准备沙发套。家变大后原来 2 个垃圾桶不满足需求，需要再买 2 个。天气热了会有蚊虫飞进来，纱窗和灭蚊虫的喷雾也得有，还有电扇。入门毯子、浴室毯子也要有…...

这样一来我需要准备的设备已经超过 10 个，大家应该熟识神奇数字 7±2 法则，根据美国心理学家米勒的《神秘的七加减二》的研究成果表明，人们一般能记住7以内的事物，超出后便很难记住。如果我们要尽可能全的记清楚以上要准备的东西，就得把刚刚的生活场景再无遗漏的反复想象，确认哪些已有哪些待准备。所以我试着将它们做了分类：

下面我基于金字塔结构的三个基础原理细述设计师如何进行逻辑思考。

纵向结构组织产出结构

1. 自下而上的思考：提炼文章或报告目录，分析和验证需求、推演原型结构

闲暇时为了阶段性的沉淀一些设计思考，喜欢写点文章总结自我。现在想来，每次编写目录时用的都是类似的套路。我会把所有的笔记、课件、相关资料中要表达的核心思想形成观点库，然后根据内容之间的逻辑关系选择一个维度，可能是时间顺序（活动前、活动中、活动后），课题分类（交互趋势、体验驱动、数据分析、前端技术），又或是论点支持，最终得出能概括所有思想的一个主题，通常也是这篇文章的标题。

除了写文章，设计师平时承接的产品需求的验证和分析过程也是自下而上的思考方式。

譬如产品经理过来跟设计师说，数据分析平台要做一个管理者可以自定义并发布的榜单的功能。这句话是结论，如果不经过分析就不清楚这个需求到底是否合理，设计的方案是否能解决用户的痛点。

这个时候我们可以收集该数据分析平台的所有问题反馈（含用户、项目组、领导的），分析问题的时候发现用户对各类型榜单模型诉求高、前端开发资源紧缺、产品经理承担该平台的权限管理职责，这样一来不难得出需要自定义榜单的功能，以满足用户需求和解决资源紧张的问题。

确认需求的合理性后就是将功能转化成页面元素，再将元素组合成页面。

如若现在要做一个文档下载功能，用户需要看到的是文档类型、大小、预览效果、浏览人数、收藏人数、下载人数、评论、下载按钮等，这些元素最终呈现的其实是一个文档详情页面，再根据元素类型和优先级进行布局，形成页面原型。

通过以上几种思考场景，可以把自下而上的纵向思维方法总结为：

• 罗列出所有想要表达或表现的要点；
• 寻找出各要点之间的逻辑关系；
• 得出结论，确认主题或目标。

2. 自上而下的表达：确认汇报文档结构、陈述设计方案

自下而上其实是在头脑输入信息后的整合过程，而输出方式则用自上而下的形式更适宜。

设计师在使用数据分析、竞品调研、用户研究等探索方法后会形成相应的汇报文档，如何让观者或听者第一时间获得重点并耐心地聆听你的分析？读者的思维能力是有限的，接收到的信息既要识别和理解，又要思考它们之间的逻辑关系，不如在详述之前就告知研究的结论，再从不同角度论证结论提供依据，并适时的列举一些例子或讲述一些故事，也就是使用总—分结构，再借助形象直观的案例，更能减少读者思考的时间和理解的难度。

业务沟通、提案表达时也同样如此。

试想你的同事过来突然跟你说：「昨天我们发布了一个用户反馈的新功能。这个是领导吩咐一定要做的，我们调研了几个其他的类似产品都是用的新增入口，让用户点击填写提交的方法，目前已经有过百的用户通过这个功能反馈建议……」

在听这段话的时候你一定会通过接收到的信息下意识的推测他到底要跟我表达什么，然后一脸茫然，到底是这个功能非常重要，还是流程方法有待优化，或者求助如何分析收集到的问题？

但如果他在详细说明前告知你只是希望你在用户反馈页面的UI设计提出建议，你就不会分散掉大部分精力去猜测对方到底想表达什么了。

自上而下的表达方法可总结为：

• 表达主要结论或中心思想；
• 设想受众的疑问并形成分论点；
• 借助相关案例论证观点。

横向结构连接内容信息

1. 规避演绎推理中的逻辑陷阱

演绎推理就是下一论点与上一论点存在因果关系，通常有三个要素：大前提、小前提、结论。

比如，所有互联网产品都重视用户体验，苏宁易购 APP 是一款互联网产品，所以苏宁易购 APP 重视用户体验。

为了避免被似是而非的观点忽悠和带偏，跟大家介绍 2 个演绎推理里常见的逻辑误区。

滑坡谬误

之前用研去跟踪用户反馈问题时，连续几周通报：较多用户反馈不知道如何取消自动续费。有个项目组小伙伴用统计数据发声：「每周有 2000 左右用户开通自动续费，但平均仅有 8 个用户反馈不知道怎么取消，说明这并不是什么大问题。」

人的思维是趋向于惰性的，甚至会有本能的秩序偏好，如果不仔细思考，好像觉得这样的推演结论并没什么问题，其实她使用了滑坡谬误的逻辑陷阱，并不是所有不清楚如何取消自动续费的用户都会把问题反馈出来，也就是这 2000 个人里并不是只有 8 个人遇到了这个问题。

因果倒置

有些人会这样认为，事业上有所成就的人都会佩戴一只名贵的手表，因此如果你想事业有成就得先买一只 OMEGA。

但其实真实的因果关系却是：由于这些人事业有成收入颇丰，才有能力购买佩戴名贵的手表。这种观点其实就是视结果为原因，视原因为结果引发的错误。

再说工作中，产品设计者曾提出过这样的需求：以丰富产品玩法为重点工作以获得更多新用户，原因是市面上用户量较高的竞品都是两周迭代一个玩法的。

其实仔细想一下，是不是因为这些竞品本身用户量较高，为了留存所以高频迭代玩法呢。同样这也是一个因果倒置的案例，只有时刻保持理性思考，才不会陷入此类推理陷阱中。

2. 归纳推理法推断结论与规律

归纳推理需要更具创造力，比演绎推理更难，归纳的过程中同组信息一般具有相同的论述对象。

我们通常分析现象最终得出结论的过程都会用到归纳推理。

再举一个数据分析的例子：

• 未开通自动续费的用户中有 67% 咨询如何取消自动续费。
• 82% 的用户会在收到自动续费已开通短信后去取消自动续费。

由以上 2 点我们会发现这两类用户，一类未开通的，大部分不知道自己未开通；另一类已开通的，在知道自己开通后选择取消。基本可以得出结论：开通自动续费的页面和流程没有让用户明确的知道是否已开通。当然这属于一种不完全归纳法，仅是大概率推测。

MECE分析法穷尽用户及场景

MECE 是麦肯锡思维过程中的一条极为重要的准则，我也是看到这条准则后才发现它与处理交互场景和研究用户角色时的思路很契合。

如何预知项目组成员的疑问提前思考对策？如何预测用户行为实现更佳的操作体验？这些都是在完成产品设计过程中相对棘手的问题。尝试练习「相互独立，完全穷尽」的思路也许可以让说服事半功倍。

在三年前的新人项目中我曾列举典型用户和使用场景，当时我把能看到新人频道的用户分成 3 类，分别是未注册用户、已注册用户但三端未购用户和未登录的老用户。

但其实这 3 类用户并没有独立和穷尽，已注册但三端未购的用户也有已登录未登录之分、老用户退出登录后就看到新人弹窗也有所不妥。因此我又用 MECE 分析法重新分类了用户，先分成已登录和未登录，已登录中有三端未购的新用户和老用户，未登录中分曾在该设备上登录过和未曾登录过两种，调整后的分类方式涵盖了所有用户类型，以便全场景分析使用场景。

以上就是今天分享的设计逻辑方法，希望对大家有帮助。

欢迎关注作者的微信公众号：「Zoeyux」