文/郑清之

我在船上最喜爱的一门课是可持续的社会企业精神，由斯坦福D.School联合创始人George Kemble和Unreasonable Institute创始人Daniel Epstein共同教授。整门门课只有一个知识点，即设计式思考（Design Thinking），其余则是我们轮番和不同公司合作，以做咨询的视角来感受如何应用。创造力没有规则，而这个设计式思考（Design Thinking）的大体运用原则，可以指导我们对生活和工作中不同事物的理解和创新。下面我将对设计式思考（Design Thinking）的原理做出简要介绍。

      

第一，同理心（Empathy）

同理心（Empathy）之所以是设计式思考（Design Thinking）的基础是因为以人为中心的设计需要我们能深入地了解人。在观察人的行为时，最简单直接的就是带着三个问题去观察：What ——行为主体是谁，在做什么？ How——他是怎样做的，有什么样的情绪？ Why——为什么他这样做，为什么用这种方式？

观察之后，如果要更深入的理解就需要访问了。访问也是一个循序渐进的过程，通常是“自我介绍=>建立和被访者的联系=>采访故事=>挖掘情感=>提问=>总结和致谢”这样一个大体步骤。同时，在我和不同人聊天，想得到他们的观点的时候，也发现有这样一些事情要注意：比如，鼓励对方说故事，因为故事常能体现他们的世界观；提问后不要自己补充自己的观点进行回答，这样会使对方无意识地区同意你的建议；给对方沉默和思考的时间；要善于发现对方叙述有可能出现的前后不一致的地方并发问；观察肢体语言。

第二，定义问题（Define）

第一步访谈之后，我们会搜集到非常多的信息，这时就需要做一个定义问题的工作，把注意力集中到问题的核心上。但是如何才能从那么多的信息里找准问题的核心呢？我们要把手上的信息分类：一是被访者的需求（Needs），二是出乎意料的发现（Insights）。

分类记录好你的信息之后，我们可以用下面这个简单实用的格式进行问题定义：

比如，在我做这个练习的时候，我的目的是给我的搭档重新设计一次送礼物的经历。我发现她希望能送给她的继父一个有用的礼物（needs），但是她的继父是一个非常循规蹈矩的人，很不接受新鲜事物，而Janette却觉得太常规的东西没有节日气氛（insights）。所以我Define我的statement为：Janette (user) needs a way to send her stepfather a gift，making her stepfather and herself happy(needs), because her stepfather doesn’t accept anything out of his routine while Janette likes her gift to be creative and special (insights).

有了这样一个定义描述, 我们才能找准对方的需求并且平衡其中的影响因素以找到一个有创造力的解决办法。

第三，Ideate (出点子)

如果说刚才定义问题的思维模式是“聚集”，那么现在Ideate的思维模式应该是“扩散”。在这一步，目的是要去探索一个广阔的解决问题的空间，出意想不到的电子来解决刚才定义的问题——点子在量上要多，在质上要多样。同时，不管是独立构思点子或是一个团队一起头脑风暴，在Ideate这一步，有三点要注意：

  1. 此时不要去评价点子；
  2. 跳出最明显的解决办法，尽可能天花乱坠地设想；
  3. 如果是团队头脑风暴，要学会在其他人的想法基础上建立新点子。

诺贝尔化学奖获得者Linus Pauling曾说过，“想出一个好点子的最好办法就是想出很多很多点子。”所以，找出一张纸，在上面写出你能想到的尽可能多的主意吧！

进行完“出点子”的步骤后，才能对点子进行评价。首先我们可以把杂而乱的点子们分成三类：

  1. 最保险的解决办法；
  2. 最长效的解决办法；
  3. 最有意义的解决办法。

第四，建立原型（Prototype）

如果说一幅画值千句话，那么一个模型就值千幅画。出点子是让活动进行在脑海里，而建立原型则一定要把活动拿到现实世界中。一个成功的原型最关键的就是要让人去经历并产生互动 。例如，有人想开发一个买车的App, 他要把这个点子进行原型建立，方法就是在纸上画出这个App的内容，为潜在用户模拟出一次使用经历。

在这个建立原型的过程中，要记住Keep it Low-resolution，即“低解决率”。因为很多时候要有这个模型使人有了使用体验之后你才能去评估，所以大胆建模，而非先去评价点子用臆想判断。

第五，测试（Test）

测试是为我们的解决办法获得回馈，所以与潜在用户进行互动非常重要。由于我们在原型中建立的模型都是“低解决率”的， 所以测试的失败率可能会很高。但是这时我们不应该以失败的眼光来看待，而应把每一次失败都看成快速学习的机会。只有在原型与测试中失败，而非在项目正式开始后失败，代价才是最小的。

同样，得到用户的反馈后，可以用下面这个简单易行的图表去评估点子，把测试后的点子分成四类：有用的；无用的；不确定的；新发现。

这样，我们就能更深入地去理解用户，也许会修改点子，也许重新定义问题。但通过这个循环，一个有创造力的解决办法一定能被找到！