为什么要懂这个逻辑？
在设计工作中、甚至生活中遇到问题的时候，可以弄清楚：
1.问题-要解决的问题是什么
2.症结-导致问题的原因是什么
3.解法-用什么方式解决问题
4.表达-怎么把成果告诉别人

比如：
1.问题-上班老是迟到被罚款，不想这样了
2.症结-出门前要弄头发花时间
3.解法-戴帽子（还能变成自己的形象符号）
4.表达-偷偷在这里用文章告诉大家

1.问题-app内的购买转化低，想提升
2.症结-原来是引导设计看不懂啊
3.解法-改成用户看得懂的语言
4.表达-沉淀成汇报材料发给老大

这就带出了文章的大架子，接下来我按两篇文章四个章节解释一下，每一步是如何做到的。
Part1 界定问题（本文）
Part2 诊断症结（本文）
Part3 找到解法
Part4 表达解法

另外，本文的底层原理来源于《金字塔原理》这本书及若干麦肯锡公开的方法论。而我尝试结合UX行业的经验，用更好理解的结构和文字，让同行朋友们能读懂。把偶尔假装高高在上的方法论翻译简单，是我的愿望。

Part1 界定问题

为什么要界定问题

为了知道问题究竟是什么，也可以说成：“为什么要做？/ 目标是什么？”，因为是第一步，往小说它决定了后面的动作，往大说它决定了生意赛道。

怎么界定问题

Step1-列出框架

用来界定问题的框架包括5个要素，为了方便记忆，姑且叫「胖次模型」，如下图：

要素1-旧解法
指现在用来达成目标的手段，可能是一个产品、结构、流程等，比如用来查天气的app、用来运作企业的组织结构、用来产出设计的设计流程、用来达成注册的用户注册流程、用来检查是否感染的验核酸流程。
如果我们是从1到N优化产品A，「旧解法」是产品A的当前版本。
如果是从0到1创造产品A呢，「旧解法」是被使用中的其他产品B/C/D。

先讲「旧解法」，就像故事里的“从前”，比如：从前我们都用QQ来聊天。

要素2-症结
指让「旧解法」失灵的原因。它可能是外部原因，比如对手出现了、技术更迭了、政策改变了、用户变心了、设计趋势变了、企业战略改变了、业务逻辑改变了。也可能是内部原因，比如性能差、某个环节没设计好、某条渠道导入的用户不对劲。在这个阶段，原因可能只是一种粗略的认知，要到第二阶段「诊断症结」的时候，才被真正定义下来。
在故事里，「症结」对应的就是“突然有一天”的情节。从前我们都用QQ来聊天，有一天，微信出现了。

要素3-现实结果
或者叫痛点，打不到车、好难用、转化低、门铃不响、测核酸很麻烦、人太胖、太无聊。某些「症结」让「旧解法」失灵，进而导致了不好的「现实结果」出现。因为高峰期打车人多而的士少，让沿路拦的士的「旧解法」不好使，进而导致了打不到车的「现实结果」出现。

要素4-理想结果
或者叫目标，打得到车、好易用、高转化、门铃响了、测核酸很方便、人苗条、太有趣。
关于目标，有这么些特性：
1.往往可以层层拆解。上层就是下层的目标，后面章节要细说的症结、解法本身也是一种要去达到的目标。比如企业目标-业务线目标-项目目标-设计目标-设计策略-设计执行-画一颗按钮，全都是相对下一级而言的-目标。
2.尽量地清楚。因为越清楚，越好衡量是否达成，相关的知识点是SMART原则，暂不展开。
3.不是关于“价值”，就是关于“成本”。变成更多、更高、更快、更强、更好啦，要不就是更省钱、更省时间、更力气啦。

此时可以留意两点：
1.「旧解法」有效时，「现实」和「理想」是同一个东西。反之，「现实」和「理想」就分开、出现距离了。
2.「现实结果」之所以成痛点，是因为有「理想结果」的对比。身高180cm是不是痛点？对社畜来说不是，对篮球员来说是，因为他们的理想是更高。转化低是不是痛点？理想是高转化的时候，就是痛点，理想是把流量转化到新业务去，就不是。
日剧台词：在生物的环境中，会对生活产生影响的东西是什么？-别人。

要素5-新解法
消除「症结」，把「现实结果」导向「理想结果」的新方法（产品/结构/流程）。它约等于界定问题这一Part，最终界定出来的问题，即“新解法是什么”。为什么是约等于呢，往下看。

Step2-确定问题

5个要素列出来了，要解决的问题就产生在5个要素里。
情况1.前4个要素都是已知，由要素5「新解法」产生的问题，包括：
-新解法是什么？（最常见，记这个就行了，后面的问题都是由此衍生的）
-新解法也已知，是否对？
-新解法也已知，并且有多个，哪个好？
-新解法也已知，接下来具体怎么做？
情况2.由其他要素产生的问题，包括：
-「症结」是什么？比如数据莫名暴跌，得先确定症结。确定后才到解法，如果症结是服务器宕机，都不需要产生新解法，把旧解法修复就行了。
-「理想结果」是什么？比如⽬前正是从不景⽓⾏业脱身进⼊成⻓性⾏业的机会，但不知道进⼊后会到达什么样的理想结果。确定理想后才到「新解法」是什么。
-「现实结果」会不会出问题？竞争对手推出新解法，是不是意味着现实有问题。

好的，尾声做个胖次表格用来总结一下，也算是一个界定问题的工具。

Part2 诊断症结

为什么要诊断症结

无论上一Part最后确定的问题是哪一类，这一Part都要进一步具体明确「旧解法」身上的「症结」。这个过程也可以叫找原因、找切入点、定义机会、确定问题的具体位置。之后，才能推导消除「症结」的「新解法」，从而到达「理想结果」。

怎么诊断症结

Step1-列出框架

1.把「理想结果」摆出来，尽可能列出指向结果的要素并结构化，能分组的分组，能分层的分层。要素们等同于嫌疑人，元凶「症结」藏在其中。

2.如果你预计「症结」来自解法内部，那么列出来的要素均来自「旧解法」。比如影响app营业额的要素等于购物流程的每个步骤，症结可能是某个步骤。
3.如果你预计「症结」还可能来自外部，那么还需列出「旧解法」之外的影响要素。比如「理想结果」是解决用户的中午饭，而你的「旧解法」是其中一家可选的午饭餐馆，那么影响要素还包括其他的餐馆，症结可能是其他某家新开的餐馆。
延展一下：
如果我们的问题不是回答新解法是什么，而是判断某个已知的新解法好不好呢？那么我们就把这个已知新解法也给拆了。

Step2-确定症结

因为每个要素都指向结果，所以要素都应该是相对积极的。于是，审视每个要素，消极的、对结果不利的、拖后腿的要素，就是元凶「症结」。
因为诊断的过程像破案，为了好记，画了一个模型，姑且叫「柯南模型」吧。

下面举一些例子。
1.流程类框架
比如会员注册流程，结果摆出来先，是“成功注册会员”。再列出指向结果的框架，注册会员的流程，每个步骤是一个元素。最后找出消极的元素，原来是“了解权益”这一步没有展示权益的吸引力，用户没动力；以及“了解规则”这一步，规则交代得不清楚，于是锁定症结。

2.结构类框架
比如头痛了，理想结果是头不痛，那么影响因素可能来自身体也可能来自精神，两者可以再拆细。最后确定症结是压力大。

比如我们要评估一个界面的视觉效果，同样是把框架（也就是评价指标）列出来，然后逐个元素看看，把症结找出来。

好了，诊断症结的内容就这么多，记得先列出框架元素（把嫌疑人圈出来），然后评估每个元素，确定症结（元凶）。


下一次，介绍怎么推导消除症结的解法，及怎么表达解法。谢谢看到这里的朋友，感恩。