用设计,艰巨,强烈,朦胧造句

往前半步

“谁也没有见过的东西” 与 “谁也不需要的东西” 之间往往只有一线之隔. 

设计不是要创造出子虚乌有的东西, 而是要好好审视现有物品与物品之间的“空隙”, 找出还有什么用户需求/冲突未被满足, 找出A和B之间还存在多少空白, 还有多少发挥的空间, 用户和产品之间还有怎样的空隙.

当一个空间内没有光时一片黑暗, 然而实际上, 并非真的什么都不存在, 只是光还未进入而已. 人的眼睛看到的并不是光本身, 只有当光线照射到物体之上时, 人才真正感觉到光的存在.

设计的工作并不是单纯只是创造那道光, 而是要寻找到黑暗中依然存在的东西, 然后把光照射上去.

串联构思法

遇到一些“特别”的食物, 不做任何处理放入脑海, 当许多因素连成一串时, 再去寻找其中有用的点. 

那些连城线的食物, 就成了构思创意的关键.

一闪而逝的灵感, 要及时说出来, 才有可能有机会帮助它发酵, 成型. 若身边没有听众, 那么, 就写下来, 这是使灵感固定显现化的方式.

人类的大脑首先“感知”到事物(1), 然后对这其中“理解”(2)到的东西进行“判断和思考”(3), 接着将那些对自己有意义的部分“记住”(4).

读第一遍, 整个1-3的过程将和以前的记忆(4.1)进行对照和记忆(4.2), 而读第二遍, 则是结合4.2的记忆, 让2-3的过程发挥得更好, 从而产生新的4.3记忆.

设计也是如此, 若设计由于太过新颖以至于普通用户无法理解(2), 那么, 在判断(3)之前, 就被大脑忘掉了. 为了避免这种情况, 在设计时应注重去理解并关联曾经的记忆(4).

最好的设计是给用户一种好像从没见过, 又好像在哪里曾经见到过的感觉.

** 人类天生就是矛盾的物种. 我们总期待着与众不同, 但又太害怕与众不同. 我们既渴望着引人注目, 又无法舍弃想要和大家保持一致的安全感. 我们一边期待着新事物, 一边又害怕绝对陌生的未知事物.

二次审视的重点之一, 是“不忘初心”: 我们是如何一步一步走到这里的? 就想喝啤酒, 初时感受到的“清爽”和细品时散发开的苦味-“醇郁”吧. 无论是认识事物, 还是构思创意, 都应灵活运动这两种感觉.

这种冲突, 可以很好地被设计所利用: 打给你设计一款全新的产品时, 最好能不动声色地加入一些令人怀念的, 似曾相识等能给用户带来安全感的元素.

越是新的产品, 越需要给用户似曾相识的感觉. 问问自己: 这玩意儿在目标用户中, 是有95%, 还是5%的人见过? 然后根据人群的比例,来调整“即视感”的契合度. 面向大众的用户, 越应该应用普遍而明显的模拟小众的产品, 也应深入挖掘这一人群的个性, 去寻找能打动他们的点 - 去了解每个人心中已经存在的光怪陆离的各种模式.

学习的乐趣 ->发现与已知模式可关联, grows more on the tree的乐趣 ->推翻/更新树上节点的乐趣?

如何让一个创意在人们心中留下印象呢? - 人们记住的, 往往是创意中看似不完美的那一部分.

当人们接触到一个事物时, 只有同时看到了它的完美和不完美, 才会给人留下更完整/更真实的印象.

你需要做的, 只是比别人思考得多, 比别人更有热情. 不停得锻炼大脑, 使偶然变成启示.

去尝试“麻烦”吧, 它能助你找到机会, 又能发现问题.

“中心视觉” vs “周边视觉”

不停地去发展“周边视觉” , 训练“模糊扫视”的能力 - 无论看到什么, 总是不自觉地想: 那个物体好像这个东西啊”, 第一时间将它和另外一个事物连在一起观察. 

不停地埋下一个一个点, 就会在不经意间, 连成一条线.

每天抱着游戏的心态进行这样的练习: 发现隐藏于日常生活中细微的“违和感”, 发现那些大多时候都觉得“理所当然”“本该如此”的事情之中的违和感, 每日分出一点心思稍作思考.

要留出更多精力进行“创意性素质”的锻炼, 第一步是从“减少变化以减少选择浪费心智带宽”开始, 譬如总是穿同一款衬衫, 减少各种无谓的精力浪费.

若我们足够专注在一个方向, 长期保持不变的步骤, 步调, 反复做同样的事情, 将有不可思议的事情发生.

反转“地”与“图”

- 想让椅子变白, 墙面涂黑

- 想让产品“降价”, 不一定需要降低产品的品质, 我们还可以提高其它产品的价格和档次

- 需要一个坑, 不一定要往下挖, 堆高周边的土, 一样可以得到一个坑

世间万物都是二元对立, 有了好才有坏, 有了美才有丑, 有了留白才有图形, 相互依存, 因此, 既可以作用于地, 也可以作用与图. 空就是满,满就是空.

设计中最有效的, 就是着眼于那些大家都不太放在眼里的, 看似无关紧要的事物.

利用虚拟头脑风暴, 训练“附身力” : 若我是用户, 会想要什么? 若我是老板, 会想要什么?

不断转换身份视角的思考能力, 就是拥有新的不同视角的途径.

如何混搭但避免食物中毒? - 寻找具有双重共用的“食材”.

用小卡片写下每一次的想法. 利用各种碎片化时间进行“虚拟头脑风暴”的游戏.

定期回顾小卡片, 分类/关联或丢弃. 当纸条扔掉之后, 还牢牢留存在我们脑海中的,就是实际操作过程中可以信手拈来的好东西了. 

每一个创意, 刚开始出现时都是“柔软的”, 灵活的, 多变的, 蕴含无数可能的, 但随着时间的推移, 会渐渐凝固.

“脑海中的画面 ->平面草图 ->二次元画面 ->立体物”, 这是一个创意渐渐演变的过程, 越靠后, “硬度”越大.

漫画比小说具体, 动漫又比漫画具体, 越具体, 越容易被理解, 同时可想象空间也随之变少.

创意亦是如此. 当它以柔软的状态存在与脑海时, 具有发酵空间, 更容易与其它灵感发生化学反应.

这和仁波切讲的: 保持一颗柔软的心, 是一样的意思. 但你的心保持柔软, 也就是它具有开放性, 更容易接纳各种信息和可能性.

如何让创意保持在柔软的状态, 并在最合适的时机将它固定成型, 是重点.

另一种相反的做法, 则是把“固定的存在”, 进行抽象化, “软化”并简化到能感知这个形象的最底线, 可能性就变得更广了. 如把维尼熊这个固有形象直接应用在家具上, 未免太显孩子气, 而把这个形象的曲线和色调抽取出来, 也就是“退一步”来看待这个事物, 你就会发现你还有别的选择, 更广阔的选择, 柔软的创意随之而来.

对待一件事物, 不持有正面的眼光, 与不带有负面的眼光. 用灰色的中立态度去理解事物的各个层面 (在说非二元?), 那么, 结果可能完全不同. 养成这种不分黑白的“灰色思考”, 非常有益.

快速“以往”上一件工作, 才能更好专注于下一个任务.

当创意久久没有进展, 立即抽身, 不必死耗, 在对其产生厌倦感前及时抽身离开, 是保有热情的不二法门.

培养果断的决断力: 就算是错的, 也要尽快推进. 迟来的判断比错误的判断更可怕.

在诸多选项中进行检索, 选出两个“完全背离”的两个选项, 积极的/消极的, 有风险的/无风险的, 然后从他们之间的最短距离中寻找问题. 

“如果这不是一直烟斗, 又是什么呢?”  当抱着这个疑问, 脑海中就有了新的空间.

“它可能是烟斗之外的任何事物” - 意味着我们的思路获得了极大的自由, 更广阔的发散空间.

所谓玛格里特的“背叛”, 就是要让人学会在看到一支钢笔时去思考: “如果不是钢笔, 它会是什么呢?”

要是有人告诉你“这不是一支钢笔”, 你就会诧异: “诶?”

对设计师来说, 重要的就是反复练习“诶?”的这个过程 - 质疑的过程, 去经常练习把一件事物看成完全不同的另一件事物 - 尽可能地悖离, 这种风马牛不相及的事物碰撞才最有效.

这类练习的基本前提是: 要让自己随时相信, 世界上本就没有什么东西是“本该如此”或“正常的“. 要拥有质疑常规的能力.

譬如想想: 筷子为什么无论什么时候都得是一双呢?

案例: 一双筷子变成一只筷子, 一只筷子可分离成一双(1/2的筷子).

「重复抑制效应」

也就是见惯不怪的效应: 大脑会对平常见得多的事物习以为常.

比如成人看到天上的星星, 觉得漂亮的星空灿烂漂亮而已. 而小朋友心中会想: 这些星空都是从哪来的呢?

爱因斯坦说: 我只不过是把一个人童年时候的好奇心保持到了现在而已.

「突显网络」帮助我们时时刻刻“重新”审察现在的生活, 减少重复抑制效应, 这就是创造力一个非常重要的来源.

注意力创造: 当我们发现了有趣的东西, 前扣带大脑皮层会关闭默认模式网络, 打开注意力自信网络, 以此开始思考的过程.

从本质上讲, 设计是一种“表达”手段. 设计的本质是研究如何化繁为简, 将复杂的事物更直接清晰地表达出来,  让事物隐藏的部分被看见.

匠人型: 把客户的要求分毫不差地交付出来

创意型: 在了解用户需求的基础上, 深挖背后的根本问题, 提出创新的概念方案

将看不见的可视化, 诉诸五感的联想. 人们天然有一种能力, 能够通过颜色来辨别味道. 对设计师而言, 就是把这个看不见的味道, 转换成看得见的颜色, 将信息视觉化后唤起人们头脑中的感觉, 以完成特定的传达.

俯瞰过去, 立足现在, 展望未来.

市场, 即过去对现在的影响而设计, 则是立足于对当前市场的了解, 去展望未来.

设计, 就是不断回顾的过程,. 不断回顾当初是如何造就了现在的市场, 然后假设: “持续这样的市场, 三年之后会变得如何, 为了不如此, 现在最好如何如何”.

品牌即信赖. 找到企业/产品的“长处” 并准确地向目标群体传达这个信息.

长处/差异点/理念.

去发掘那些“社内禁区“, “未开垦的领域”, “被遗忘的角落”, “不成文的禁区”, “习惯的沉默”吧.

缺点也可以宣扬, 以获取最质朴的信任. 比起只看“最后作品”的好与坏, 越来越重视达成最终结果的“过程”.

让失败/纠结的过程可见, 让企业形象变得笨拙可爱的灵活灵现, 

所以迪信家装设计的采用开放式西厨和多功能生活区，客厅面积等于厨房+餐厅，餐厅座位数与客厅沙发座位数一致，家居用品但求使用便捷、美观大方，合理的解决了诸多生活细节问题。总而言之，迪信讲究的是“美学、力学、实用、耐用”四项基本原则，设计没有夸张的装饰，也没有奢靡的精雕细琢，而是站在户主的角度思考生活的本质。

前面两个我们先不展开，说说作品二次变现，作品变现一般就两种方式：网络平台出售个人作品+给素材网站供图

这两点都离不开一个靠谱的平台，

今天分享一个对设计师超级友好的设计作品分享下载网站-原图网（yuantunet.com），

简简单单的上传作品就能躺赚了。

上传作品享无限收益

为了鼓励设计师上传，原图网的收益体系最大限度地向设计师让利，

作品可以从多种途径产生收益，非常的惊喜

首先只要上传作品就能通过审核在网站展示，就可以每天产生收益

其次作品被会员下载，可以获得当日每次的VIP下载分红，平均一个的分红高达0.5，如果上传200作品为例，假如每天被VIP会员下载50个，也就是意味你每天账户都可以自动获得25元收益，这意味着每年都有万元的额外收入进账。

会员付费下载作品，设计师可以获得91%付费下载收益，这个就是非VIP下载的，数量并不多，不过如果有就是一笔不错的收益，

最后，祝你好运！

其实GoF的《设计模式》一书，一共有三个层面的内容:

1. 指出编程开发活动中存在模式，提出总结设计模式需要关注的四要素 "名称-问题-解决方案-效果“ ，并给出描述一套模式的格式模板。

2. 提出了面向对象开发中”针对接口编程优于针对实现编程”，”组合优于继承”的总体设计思路

3. 选取了现实开发中基于上述设计思路所形成的23种常见设计模式作为例子详细描述

虽然第3点包括的多个具体的设计模式实例占据了最多的篇幅，但事实上第1,2点才是纲。实际上《设计模式》一书最划时代的意义，在于第1点。在此之后，出现了以设计模式的格式来组织内容的《分析模式》，《企业架构模式》，《企业集成模式》，《xUnit测试模式》，《重构》等等质量颇高的书籍

在书中有一段我认为非常重要但很容易被忽略的话

本书中涉及的设计模式并不描述新的或未经证实的设计，我们只收录那些在不同系统中多次使用过的成功设计。这些设计的绝大部分以往并无文本记录，它们或是来源于面向对象设计者圈子里的非正式交流，或是来源于某些成功的面向对象系统的某些部分，但对设计新手来说，这些东西是很难学得到的。尽管这些设计不包括新的思路，但我们用一种新的、便于理解的方式将其展现给读者，即：具有统一格式的、已分类编目的若干组设计模式。

这段话的关键是：

1. 书中的模式不是作者的发明创造或独门秘籍，而是早已存在并已经广泛使用的做法，只不过没有被系统地加以记录。换而言之，只要遵循某些原则，这些所谓模式完全可能在无意识的状态下自发出现在产品代码中。

2. 这些模式在各种系统被多次使用。换而言之，你只要接触足够多的代码，必然会大量接触到这些模式的实际应用。只不过在看过《设计模式》一书之前，你可能意识不到这是一个成体系的设计手段。

3. 作者认为《设计模式》这本书的价值在于对设计模式进行了有效的组织和便于理解的描述。换而言之，这本书的写作出发点是”便于理解“，并且是面向”设计新手“的。而不少初学者却恰恰觉得这本书难以理解，这说明，作者已经在保证准确性的前提下，选用了他们所认为最便于理解的描述。比本书描述更为显浅的描述，很可能会牺牲准确性（不准确的描述对于新手来说是显然是害处大于好处）。当然某些人认为是作者表达能力有限，这种事情无法求证，但我倾向于前者。

===================================

现在开始正题，如何正确使用设计模式，准确来说，正确使用GoF的《设计模式》一书中所涉及的23种模式。但我们不妨先考虑一个比较容易回答的问题，如何避免不正确地使用设计模式。毕竟不正确地使用还不如不用，你在避免不正确使用的前提下慢慢用起来，就是正确使用了。

使用设计模式最常见走入歧途的做法是：你看了《设计模式》中某个具体模式，觉得似懂非懂，或者甚至根本没看过原书。然后去看了一些举例子打比喻的”再谈“，”妙解“，”大话“之类的东西，觉得豁然开朗。之后在开发时发现某一处非常符合你对这个模式的理解，于是开始使用。这种做法用来练手可以（也就是你明知使用这个模式未必是一个好主意，只是为了尝试在现实场景中去实现一下，练习代码并不进入最终产品代码），用来做真实的设计则往往谬以千里。

原因很简单：设计模式是一种驾驭抽象概念的技术，而描述模式的标准格式里就包括了抽象描述，代码示例和应用场景。如果一个程序员根据这些信息还不能理解一个设计模式的话，说明他首先抽象思维尚不足以驾驭设计模式，其次在理解代码和接触应用场景方面经验不足。简单来说，还未能达到“设计新手”的入门水平。在这种状态下勉强去使用设计模式，出问题是在所难免的。

因而得出第一点：如果你已经看过某个设计模式的描述，要正确使用它的最基本前提是，你能完全看懂GoF《设计模式》中对它的描述。在此之前，只看，不用。看是指看该模式的原文描述或者具体代码。特别地，不建议通过一些类比具体生活例子的方式来理解设计模式。设计模式的写作格式是经过验证，能有效地描述一个模式而又不失准确性的手段。如果你无法理解，看实际生产代码的应用场景是唯一真正有效的方法（因为设计模式本身就是从具体代码中总结出来的）。用类比的方法降低设计模式的抽象性来帮助了解没有实质的意义——即使你觉得自己懂了，你的抽象思维和开发经验还未达到能正确使用这个模式的水平。

正如前面所言，只要你对面向对象一些基本原则有充分的理解，你甚至可能在没看过《设计模式》之前就开始使用某种模式了，如果你已经达到这种程度自然能无压力看懂描述。退一步假如你还没达到这种程度，既然《设计模式》中的模式非常常见，你只要有心多看代码，在现有代码中必然能接触到。通过实际应用的代码与书中的描述互相印证，要理解亦不难。再退一步，假如你接触的代码就一直没遇到 某个模式，你也一直无法自发理解某个模式，那么这个模式就对你没用，你没必要一定要找机会用。

避免不正确使用的第二点是，避免过度设计。这里说的过度设计本质上就是你为可能发生的变动支付了过多的复杂度代价。其实过度设计和设计模式没有必然的关系，只要你认定一个地方会变动，你就会考虑是否应该增加复杂度来换取灵活性。设计模式只不过针对某些具体场景提供了一些效率较高的以复杂度换灵活性的手段而已。避免过度设计的关键是，你能正确评估未雨绸缪所引入的复杂度，相对于发生变动的可能性和破坏力，是否值得。

正确评估变动的可能性和破坏力，只能依靠行业经验，属于资历问题。如果你对当前场景没有足够的经验进行评估，最好的办法就是假定它不会频繁变化，只采用普通的高内聚低耦合策略，而不需要增加额外的复杂度来提供灵活性。等到确认出现变化时，再进行重构。

而对设计模式的认识可能会影响对复杂度的估计，不少设计模式的初学者很容易错误估计实现某个设计模式所带来的复杂度，认为灵活性随手可得。又或者下意识地寻找练手机会而忽略掉复杂性的代价。在假定程序员对某个设计模式已经充分理解的前提下，我觉得评估复杂度时至少应该考虑到这些因素：

1. 需要额外引入哪些新的概念。要明白一段代码涉及的概念越多，就越难理解。

2. 设计模式自身的实现复杂度

3. 一旦引入后，为了保持设计所带来的灵活性，后续开发需要注意的地方。是否能通过代码层面的限制来保证灵活性不会被破坏。

4. 团队中其他人对这个设计模式的理解程度

5. 对排错调试，代码静态分析可能造成的影响 （例如Observer模式和Visitor模式往往会打乱静态分析，难以通过阅读代码确定执行状态）

如果能够大致准确地评估上述要素然后作出决定，我觉得即使变动最终没有发生，也算是一个合格的设计决策。真正的难点在于评估变动，这只能靠经验。还有就是每次做出设计决策后最好能跟踪总结，为下次决策积累经验。

关于设计模式的使用暂时想到这些。

========================

既然题目中提到了“设计模式的荼毒”，这里也说说我认为《设计模式》一书中最大一处问题：一句看上去正确，但被后来一些读物误解并放大，在实际执行中造成最多问题的话：

命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。

这句对“模式名称”要素的描述的话，在很多后续书籍或文章中被引申为：设计模式的一个重要作用是为团队提供了一套方便的交流手段。看上去非常正确，例如，我可以对同事说，这里需要一个Adapter；或者在代码中直接命名XXXApapter，同事们一看就知道这是什么了。交流变得非常方便——前提是，我们都看过《设计模式》并清楚关于这个设计模式的描述。使用设计模式进行交流的结果就是：了解某个设计模式的人跟不了解这个设计模式的人根本无法交流。

而交流在团队中是一种非常基础，不可或缺的东西，进一步的结果就是，了解某个设计模式的人认为不了解这个设计模式的人达不到基础水平。而按照前文的分析，设计模式只不过是对已有开发手段的总结，完全有可能出现某个人的能力已经足够自发使用设计模式，只不过因为没认真看过《设计模式》这本书，而被认为达不到基础水平。这造成了很多有一定编程能力的开发者对设计模式十分反感。

再一步引申的结果是，因为设计模式变成了一种鉴别是否具有基础水平的手段，那么为了让自己看起来有基础以上水平，就必须要表现得懂设计模式——即使看不懂《设计模式》原文。这就给许多“大话”，“再谈”读物带来了市场，进而造就了一大批不是从实际开发或阅读代码中理解设计模式，在实际应用中错漏百出的初学者。