您的位置：
设计师的思维整理术：四个思维可视化模型
作者：佚名
　　人的思考过程，是一个奇妙的过程，思维在脑海里流窜，横冲直撞又反复纠缠，最后扭成一团麻。所以常常会有人抱怨，脑袋里很乱，想不出头绪。这是因为，大部分人的思考过程都是杂乱无序的，没有逻辑的，最后也没法形成有效的沉淀，更无法找到清晰的结论。那么本文要讲述的，就是怎样把思维进行可视化的规整，最终系统化的沉淀下来，找到其中有价值的方向。其实这种可视化的规则，不止可以用工作中，用在生活中也一样。
　　大部分人脑力最活跃的时候，往往是睡觉前、蹲厕所时，这时候你的脑袋里就像纪录片一样闪回各种生活片段，也会自我探讨很多人生问题，但是当别人问你，刚才你都想了些什么?你会发现你突然脑袋一片空白，我刚才在想什么?好像想了很多，却又都不记得了。除非在这漫无目的的脑力激荡中，你产生了让自己信服的idea，否则你很难记住自己都想了什么，所以大部分人这种碎片化的时间，都是毫无价值的浪费了。
　　逻辑好的人，往往善于归纳总结，把复杂包裹起来，把整理后的闪光点暴露出来，就像集线器，把各种线索都收纳到盒子里，把重要的插头暴露出来。
　　领导讲话，都喜欢讲3点。这并不是信手拈来那么简单，这需要提前做好充沛的准备。很多说3点的人，都是提前思考过的，有备而来的。当然也不排除有些人天赋秉异，可以在极端的时间内，快速的思考并总结，提练出有价值的3点来。这是很难的事情，我也极少这么做，但是为了体现我自己很有逻辑，有时候我会这么说，这件事情，可以总结成如下几点，第一点，第二点，第三点&&能说几点说几点，但是随时可以见好就收。
　　我这里有一个面试的时候，我会问的比较有代表性的逻辑问题，请说出你的三个优点，每个优点说三个例子，每个例子不超过一句话。这要求应聘者在极短的时间内总结并提炼，是非常考验逻辑的。
　　设计中的思维可视化，是从无序到有序的思考过程。不是所有的人都是天生就有很好的逻辑的，但是好在，逻辑是可以训练的，只要你懂的把自己的思维进行可视化的展示、分析和整理。
　　漫思维模型是大部分人大部分时间的思维模型，从一个想法漫入进来，思绪进过各种游弋，然后再散漫的发散，如果有幸从中间找到一些价值点，那也只能说是幸运。不过像头脑风暴(Branstorming)这种依赖脑力激荡的思考方式，倒是也适用于这种漫思维模型，因为头脑风暴确实是需要从无限可能性中去寻找方向。所以这种思维模型也不是一无是处，只是适用的场景不同，也不需要可视化出来。
　　聚思维模型是少量善于逻辑分析的人的思维模型，他们善于先自我发散，再筛选可能，然后聚合成靠谱方向，再具体细化。思维是一个漏斗，最后沉淀下来的想法，是经层层筛选的。而能控制自己从发散中提炼的人，是善于控制思维的人，这种人完全可以不依赖思维可视化，就想清楚很多事情。
　　但是事实是大部分是无法做到发散后合理提炼和归纳的，所以这种情况下，还是依赖于方法来进行思维可视化，可视化之后，就方便归纳、整理、提炼、细化了。
　　下面是思维可视化的4类模型&&1.放射状规整(思维导图、鱼骨图) 2.层次化规则(架构图、组织结构图) 3.线性化规整(路径图、时间线) 4.矩阵式规则(SWOT分析、商业模式画布)
　　1. 放射状规整
　　让思维从一个点出发，形成放射状的发散。这种规则方式，主要是用来整理多种可能性，便于发散思维，并可以对每种可能性进行深入挖掘。
　　思维导图(MindMap)是一种将放射性思考具体化的方法，是最简单又最有效的思维整理方式，也是世界范围内应用最广的思维工具。我们知道放射性思考是人类大脑的自然思考方式，每一种进入大脑的资料，不论是感觉、记忆或是想法&&包括文字、数字、符码、香气、食物、线条、颜色、意象、节奏、音符等，都可以成为一个思考中心，并由此中心向外发散出成千上万的关节点，每一个关节点代表与中心主题的一个连结，而每一个连结又可以成为另一个中心主题，再向外发散出成千上万的关节点，呈现出放射性立体结构。
　　鱼骨图(Cause and Effect Diagrams)，又名因果图，是一种发现问题&根本原因&的分析方法。是由日本管理大师石川馨先生所发明出来的，故又名石川图。其特点是简捷实用，深入直观。它看上去有些象鱼骨，问题或缺陷(即后果)标在&鱼头&外。在鱼骨上长出鱼刺，上面按出现机会多寡列出产生生产问题的可能原因，有助于说明各个原因之间如何相互影响。
　　2. 层次化规整
　　层次化规则，是用来挖掘结构关系，并层层深入审视事物的状况。
　　架构图(Org Charts)是一个思维可视化工具，它通过树状图的方式对一个事物的结构进行逐层分解，一般是从父级向子集深挖。虽然拓扑的方式与思维导图类似，但是架构图不是为了发散思维而存在的，而是为了探讨组织结构关系而存在的，所以层级的重要性不容小视，一般都是自上而下去严谨的拓扑，不做无价值的拓展。
　　这种层次结构图是用来展示清晰的分组信息，表达清晰的组织结构关系的。
　　3.线性化规整
　　线性化的规则方式，一般都有一条清晰的主线，这条主线可以串起整个思考过程。比如是时间为轴，比如设定好起点和终点后中间所能发生的所有的事情，比如围绕某个用户目标而产生的任务流等。
　　路径图(Roadmap)是一种任务走查方法，设定好用户目标，起点和终点，排查中间会发声的所有的事情，为每个重要的关键结点进行设计。这种思维可视化方式一般用在目标导向的事情中，确定达成目标的多种可能路径，并选择其中最短路径。
　　时间线(Timelines)是用来描述在一个时间段里面，发生的所有里程碑性质的事情的，也可以用来基于时间线制定项目计划。过去放在时间线横轴左边，未来放在时间线右边，所有基于时间结点发声的事情和计划发生的事情要进行特别标注。这种方式很用来做里程碑图或者项目计划。
　　4. 矩阵式规整
　　另外一种结构化的思考方式就是矩阵式规则，先想清楚需要思考的事情的几大纬度，然后把纬度沉淀成矩阵，再往矩阵里去补充具体内容，这种方式很使用用来做突显内容的探讨。
　　SWOT分析是一种常用的战略分析工具，SWOT分析代表分析企业优势(strength)、劣势(weakness)、机会(opportunity)和威胁(threats)。因此，SWOT分析实际上是将对企业内外部条件各方面内容进行综合和概括，进而分析组织的优劣势、面临的机会和威胁的一种方法。 可以通过分析帮助企业把资源和行动Focus在自己的强项和有最多机会的地方。
　　商业模式画布包含9个构成模块，重要伙伴、关键业务、核心资源、价值主张、客户关系、渠道通路、客户细分、成本构成、收入来源。按照这9模块来思考内容，就可以很方便的绘制出你的项目的商业模式，帮助投资人理解你的项目全景。商业模式计划书也适合用在个人身上，只是9各构成模块做了一些调整而已，我也在百度MUX内部带领小伙伴们一起做个个人商业模式的设定，帮助小伙伴们找到自己的优势和劣势，学习型项目和主导型项目。
　　最后想说，最高级的思维方式是，所有的发散、总结、沉淀都在脑海内部形成，但是大部分都达不到这种牛逼的程度，所以我们不得不利用可视化的方式，训练自己的思维方式。另外即使你思考方式很牛，如果你不能可视化的给他人呈现出来，也很难保证普通人能很好的理解你。所以不管是思维牛人还是思维普通人，都需要知道怎么把自己的思维可视化出来。
　　再总结一下思维可视化的4类模型&&1.放射状规整(思维导图、鱼骨图) 2.层次化规则(架构图、组织结构图) 3.线性化规整(路径图、时间线) 4.矩阵式规则(SWOT分析、商业模式画布)。其实模型还有千千万，具体情况具体采用不同模型，或者发明创造新的思维模型，全靠悟性了。
(转载请保留)
互联网的一些事，已超50万小伙伴关注！掌握这5招，使你的思路更加清晰有逻辑 - 简书
掌握这5招，使你的思路更加清晰有逻辑
跟你的上司汇报工作时，却不知道如何清晰地表达你的观点，让上司一目了然在职场中，会遇到同事说了半天，却不知道同事具体说了哪些内容写文章时，想了半天却不知道如何下手遇到上面这些困惑，都是不知怎么清晰有逻辑地表达你的观点
1.想清楚才能说明白
4个步骤搞定议论文写作：
结论先行 “论”
以上统下 “证”
归类分组 “类”
逻辑递进 “比”
人为什么要写作？（论）1.可以拓宽视野（证）2.可以提高能力（沟通能力、逻辑能力、思维能力）(类）3.可以树立个人品牌意识
2.结论先行，消灭你上司的不耐烦
表明你的观点
依次阐述支持你的观点 ，阐述理由的事实和依据
再一次总结你的观点
3.一句话说清你的中心思想
在_的基础上，从,, ,几个方面，说明了。
在对比了别人是如何管理时间的基础上，我决定从用好手机软件，跟踪自己的清单项目，反馈及总结几个方面着手，说明了时间管理是要追踪清单，反馈及思考总结才能管理好时间
4.玩转SCQA序言讲故事
序言讲故事结构包括这四个方面S(背景）C（冲突）Q（疑问）A （回答）还可以观点-案例-建议
现象-原因-方法
这周想去杭州西湖游玩，可是正好碰上G20国际峰会，那怎么办？我们改天去吧
5.确定目标，让目标有得放矢
确定目标，让我们的表达有得放矢，你的表达，希望对方有哪行为？设定好场景，了解对方是谁，然后在这个场景下你希望达到什么目的？
场景：向客户讲解方案设计：了解客户的需求，通过明确的方案阐述，达到我们希望的效果
源自《结构思考力》 《金字塔原理》&本文是对我在知乎一个回答的整理，其中的内容大多是对我平时的阅读和实践的总结，希望对Android的开发者有所帮助。但毕竟是个人的一些思考，难免有疏漏，也欢迎对本文的内容提出建议。
1. 架构设计的目的
& & & & 对程序进行架构设计的原因，归根到底是为了提高生产力。通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率，并且更容易进行后续的测试以及定位问题。但设计不能违背目的，对于不同量级的工程，具体架构的实现方式必然是不同的，切忌犯为了设计而设计，为了架构而架构的毛病。举个简单的例子，一个Android App如果只有3个Java文件，那只需要做点模块和层次的划分就可以，引入框架或者架构反而提高了工作量，降低了生产力。但我当前开发的App最终代码量应该在10W行以上，本地需要进行复杂操作，同时也需要考虑到与其余的Android开发者以及后台开发人员之间的同步配合，那就需要在架构上进行一些思考。
2. 基于MVP的架构设计思路
& & & &&在App开发过程中，经常出现的问题就是某一部分的代码量过大，虽然做了模块划分和接口隔离，但也很难完全避免。从实践中看到，这更多的出现在UI部分，也就是Activity里。我曾见过2000+行以上基本不带注释的Activity，那时我的第一反应就是想吐。Activity内容过多的原因其实很好解释，因为Activity本身需要担负与用户之间的操作交互，再加上现在大部分的Activity还对整个App起到控制器的作用，这又带入了大量的逻辑代码，造成Activity的臃肿。为了解决这个问题，我们引入了MVP框架思路。
2.1 什么是MVP?
& & & & MVP是一种使用广泛的基础架构模式，使用基于事件驱动的应用框架。MVP从更早的MVC框架演变过来的一种框架，与MVC有一定的相似性。MVP框架由3部分组成：View负责显示，Presenter负责逻辑处理，Model提供数据。MVP与MVC之间最主要的区别在控制层上，在MVP框架中，View与Model并不直接交互，所有的交互放在Presenter中；而在MVC里，View与Model会直接产生一定的交互。MVP的Presenter是框架的控制者，承担了大量的逻辑操作，而MVC的Controller更多时候承担一种转发的作用。因此在App中引入MVP的原因，是为了将此前在Activty中包含的大量逻辑操作放到控制层中，避免Activity的臃肿。MVP的变种有很多，其中使用最广泛的是Passive
View模式，即被动视图。在这种模式下，整个框架内部模块之间的逻辑操作均由Presenter控制，View仅仅是整个操作的汇报者和结果接收者，Model根据Presenter的单向调用返回数据(图片来自网络)。并且MVP模式使得View与Model的耦合性更低，降低了Presenter对View的依赖，实现了关注点分离的初衷，方便开发人员的编码和测试工作。
& & & & & & & & & & & & & & & & & & & &&
& & & & 具体到Android App中，我一般将App根据程序的结构进行纵向划分，对应MVP分别为模型层，UI层和逻辑层。UI层一般包括Activity，Fragment，Adapter等直接和UI相关的类，UI层的Activity在启动之后实例化相应的Presenter，App的控制权后移，由UI转移到Presenter，两者之间的通信通过BroadCast、Handler或者接口完成，只传递事件和结果。举个简单的例子，UI层通知逻辑层（Presenter）用户点击了一个Button，逻辑层（Presenter）自己决定应该用什么行为进行响应，该找哪个模型（Model）去做这件事，最后逻辑层（Presenter）将完成的结果更新到UI层。
2.2 MVP架构存在的问题
& & & & 转移逻辑操作之后可能部分较为复杂的Activity内代码量还是不少，于是在分层的基础上再加入模板方法（Template Method）。具体做法是在Activity内部分层。其中最顶层为BaseActivity，不做具体显示，而是提供一些基础样式，Dialog，ActionBar在内的内容，展现给用户的Activity继承BaseActivity，重写BaseActivity预留的方法。如有必要再进行二次继承，App中Activity之间的继承次数最多不超过3次。
& & & & 模型层（Model）中的整体代码量是最大的，一般由大量的Package组成，针对这部分需要做的就是在程序设计的过程中，做好模块的划分，进行接口隔离，在内部进行分层。
& & & & 强化Presenter的作用，将所有逻辑操作都放在Presenter内也容易造成Presenter内的代码量过大，对于这点，我的方法是在UI层和Presenter之间设置中介者Mediator，将例如数据校验、组装在内的轻量级逻辑操作放在Mediator中；在Presenter和Model之间使用代理Proxy；通过上述两者分担一部分Presenter的逻辑操作，但整体框架的控制权还是在Presenter手中。Mediator和Proxy不是必须的，只在Presenter负担过大时才建议使用。最终的架构如下图所示：
& & & & & & & & & & & & & & & & & & & & & & & &
知乎上我的回答链接：
接上文：&，本文主要介绍AOP以及一些快速开发框架。
3 基于AOP的框架设计
& & & &&AOP(Aspect-Oriented Programming, 面向切面编程)，诞生于上个世纪90年代，是对OOP(Object-Oriented Programming, 面向对象编程)的补充和完善。OOP引入封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合。当我们需要为分散的对象引入公共行为的时候，OOP则显得无能为力。也就是说，OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系。例如日志功能。日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。对于其他类型的代码，如安全性、异常处理和透明的持续性也是如此。这种散布在各处的无关的代码被称为横切（Cross-Cutting）代码，在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。而AOP技术则恰恰相反，它利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其名为“Aspect”，即方面。所谓“方面”，简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。
& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &&
3.1 AOP在Android中的使用
& & & &&AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似。AOP的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。在Android App中，哪些是我们需要的横切关注点？个人认为主要包括以下几个方面：Http, SharedPreferences, Json, Xml, File, Device,
System, Log, 格式转换等。Android App的需求差别很大，不同的需求横切关注点必然是不一样的。一般的App工程中应该有一个Util Package来存放相关的切面操作，在项目多了之后可以将其中使用较多的Util封装为一个Jar包供工程调用。
& & & &&在使用MVP和AOP对App进行纵向和横向的切割之后，能够使得App整体的结构更清晰合理，避免局部的代码臃肿，方便开发、测试以及后续的维护。目前很多尚停留在实践和思想，今年上半年会抽时间写一个基于MVP、AOP和IOC的Android框架。
5 快速开发框架
& & & &&目前网络上也有一些针对Android的快速开发框架，下面介绍3个主要的快速开发框架。针对这些快速开发框架，个人认为可以参考，但并不推荐使用，因为App整体依赖一个个人维护的框架风险实在太大，框架存在一些学习成本，本身也不一定完全符合App的需求，使用后的收益并没有想象中大。
5.1 Afinal
& & & &&Afinal是一个Android的IOC，ORM框架，内置了四大模块功能：FinalAcitivity, FinalBitmap, FinalDb, FinalHttp。通过FinalActivity，可以通过注解的方式进行绑定UI和事件。通过FinalBitmap，可以方便的加载Bitmap图片，而无需考虑OOM等问题。通过FinalDB模块，通过一行代码就可以对Android的SQlite数据库进行增删改查。通过FinalHttp模块，可以以Ajax形式请求Http数据。
GitHub项目地址：
5.2 xUtils
& & & &&xUtils目前主要包括4大模块：DbUtils, ViewUtils, HttpUtils, BitmapUtils。包含了很多实用的Android工具；支持大文件上传，更全面的Http请求协议支持，拥有更加灵活的ORM，更多的事件注解支持且不受混淆影响；最低兼容Android 2.2 (Api Level 8)。
GitHub项目地址：
5.3 ThinkAndroid
& & & &&ThinkAndroid是一个免费的开源的、简易的、遵循Apache2开源协议发布的Android开发框架，其开发宗旨是简单、快速的进行&Android应用程序的开发，包含Android MVC、简易SQlite ORM、IOC模块、封装Android HttpClitent的Http模块, 具有快速构建文件缓存功能，无需考虑缓存文件的格式，都可以非常轻松的实现缓存，它还基于文件缓存模块实现了图片缓存功能，
在Android中加载的图片的时候，对OOM的问题，和对加载图片错位的问题都轻易解决。他还包括了一个手机开发中经常应用的实用工具类， 如日志管理，配置文件管理，Android下载器模块，网络切换检测等等工具。
GitHub项目地址：
参考目录：&
& & & & & & & & & &
& & & & & & & & & &
& & & & & & & & & &GOF等。
本文已收录于以下专栏：
相关文章推荐
移动APP架构模式
Native app的开发相比传统的项目迭代周期要短很多, 需求的变化也频繁一些, 在开发的不同生命周期里采用不同的架构模式可以有效的节约开发时间, 提高开发效率, 这篇文章先介...
Android源码大放送（实战开发必备）文件夹 PATH 列表│ &#文件列表生成工具.bat│  使用说明.txt│  免费下载更多源码.url│  目录列表.txt│  ├─a...
目前在软件行业有很多小公司在项目开发规划期由于没有做很好的整体规划、需求也没有很明确也考虑开发人员的架构能力不足、项目开发赶时间或其他原因就急急忙忙地着手进行代码工作，这就给以后的开发维护带来了很多问...
Android App的设计架构：MVC,MVP,MVVM与架构经验谈
周鸿博 发布于
3 个月前 0评论 1798浏览转载地址：/tutori...
我结合以前的工作和现在的工作，整理了下目前能想到的最好的Android App架构设计，在这里记录一下，以便以后用。
如图所示，为什么需要这样的架构？
现在的公司有的能同时进行好几个App的开发，那么...
技术发展日新月异，业界各种Android客户端架构设计，五花八门，但我们不能简单地说哪种架构更好，因为脱离业务谈架构是没有任何意义的，适合业务的才是好架构。而架构也不是一成不变的，随着业务的发展，也许...
1. 架构设计的目的
        对程序进行架构设计的原因，归根到底是为了提高生产力。通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中，开发人员只...
在做一个互联网应用时， 要考虑技术选型和架构搭建。 先说说技术选型，   以丁丁租房为例在开发时会面对如下问题：
1、图片处理， imageloader或者fresco， 推荐使用fresco，因为它...
Android 4.4(KitKat)窗口管理分系统 - 体系框架
转载地址：
窗口管理系统是Android中的主要子系统之一，它涉及到App中组件的管理，系统和应用窗口的管理和绘制等工...
他的最新文章
讲师：吴岸城
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)}