前不久突然感觉看不清东西，去检查后原来双眼都上升了50度。于是开心的借这个机会重新换了副很酷的机车款眼镜。带了半个月左耳却被压的发紫，很痛。这阵子总被这种耍帅的痛折磨，希望被压的那块皮肤能被磨厚些，缓解下戴眼镜的压力。最近简书把积分都换成了简书币——一种基于区块链技术的比特现金。简书做区块链是非常合适的，不过也比较担心，以后自己写文章会不会被影响的追求这种B而变得不纯粹。
在上一期，用户故事（我们常叫它“需求”）经过了机会阶段的初步筛选、探索阶段的设计和技术侧的可行性评估。侥幸存活的需求，终于进入了方案的设计和验证阶段。在这一阶段，设计师将会根据用户故事，利用设计方法输出功能原型。这一阶段正是我目前工作负责的内容。
《用户故事地图》介绍了一种可能是国外常用的设计方法——设计思维，三年前，我有幸听一位老师讲设计思维——那是我第一次接触它。经过三年的沉淀和学习，尽管今天我认为它有时不太适合中国的产品设计环境，但我依然非常推崇它的核心思想。接下来会对它做一些简单的介绍。2015年我刚接触这个思想的时候写过一篇文章《设计思维——臭皮匠的方法论》，也可以了解下。
设计思维
设计思维的实践方法共有5个阶段，分别是：移情、定义问题、形成想法、制作原型和测试。
- 移情：走到使用场景中去，与使用者交谈，收集用户对产品的实际感受，并且收集信息；
- 定义问题：为假想的用户创建一份用户画像，并将实际得到的信息融入到这个画像中形成案例，使用地图来绘制用户当前的行为。这一过程也是对上一阶段采集到的信息达成共识，找到隐藏在背后真正的问题；
- 形成想法：根据上一环节的内容，找到解决方案。可以使用二种方法；
- 头脑风暴：除了传统的脑暴方法，这里也可以使用“故事地图”辅助脑爆：在卡片或便签上直接写下对解决方案的想法，然后将它们直接放至最相关的位置。用一个表现痛点、快乐及其他用户信息的地图。针对这个地图进行脑暴，广泛收集想法。
- 设计工作室：具体使用方法见下文。
- 制作原型：针对几种方案制作简单的原型，并保证其具有一定的保真度；
- 测试：将原型拿给用户看，是否真能解决他们的问题，并获得反馈。最终找到最合适的方案。
设计思维强调小型的多学科团队协作，团队成员通过制作简单模型、草图和低保真的文档来进行交流。设计思维帮助我们真正理解“解决什么问题”，而不是我们认为的“要去解决什么问题”。
然而，设计思维并非万能或一定可以成功，设计思维最大的缺陷是花太多时间在前期设计和分析，从而对方案产生很强的依赖（这也是理想化设计的通病），一但结果不如人意，就会对设计过程产生质疑。其实大可不必如此，按照幂律分布，实际开发出来的东西中失败和成功的分别占20%，还有60%说不上成功或失败，基本上无用的。此外，进入市场的功能也很有可能收不到用户能用或不能用的反馈。
验证性学习过程
做为交互设计师至今，随着对实际产品设计环境理解的不断加深，我渐渐明白，一套严谨的设计流程固然可贵，但是要想在有限的时间和资源前提下快速获得方案，这种基于严谨流程的方法论必然会碰壁。一套结合实际开发流程、契合国人快（急）速（功）验（近）证（利）的期待，必须要从其他方面找方法，于是我碰到了“敏捷思想”。无独有偶，《和户故事地图》中也提到设计思维的弊端，从而提出了另外一种设计思想“验证性学习过程”——“开发-度量-认知”模型。
- 开发：尽可能做最小可行实验，用以验证设计方案的可行性；
- 度量：从访谈、可行性测试和软件使用中进行真接观察和数据分析；
- 认知（学习）：根据收集到的信息，重新思考设计方案，重新形成新的解决方案。
它的具体过程是：
- 获得信息：与其他伙伴（与用户直接打交道）共同讨论，获得目标用户和他们可能面临的问题；
- 找到事实：通过讨论，为猜测的用户和问题找出真实的原因和事实；
- 构建方案：构建多个解决方案，并将其聚合为最好的1〜2个解决方案；
- 找到风险：基于聚合的方案，猜测用户如何使用方案以及技术风险，并找到其中影响最大的几个风险；
- 开发原型：设计和开发小型测试，做出一个最基本的能表达方案的原型（可以使用设计连环画，这是我很感兴趣的方式）；
- 测试原型：使用原型，对用户进行测试，验证问题的存在以及方案可行性；
- 分析结果：测试结束后分析结果，若设计之初假想的方案是错的，则根据已知信息和新的猜测，进行下一轮测试；
设计工作室
设计工作室是一人快捷的、协作式获得想法的方法。它的方法大致是这样的：
- 邀请8〜12个人，你认可他们的想法，并且希望他们能帮助你改善产品；
- 描述你正在解决的问题，它的背景、机会和探索的信息，但不要说太多，防止影响他们的想法；
- 选择性的分享一些同类产品的案例，或者其他借得借鉴的产品功能设计；
- 每个人根据已有的信息绘制草图，可以限定时间；
- 每4个一组进行小组分享，时间为30分钟。教练对每个人方案解决问题的程度给出反馈，并指导他们如何融合其他人的想法；
- 要求每个小组综合得出最优秀的想法，并输出一个组织好的解决方案，这个过程通常需要15〜30分钟；
- 以小组为单位，向所有人分享想法，并展开讨论；
- 收集他们的草图和想法，团队成员用这些资料最终创建一个最终的、进行充分整体的草图。
絮絮叨叨又说了这么一大堆。有时候不得不说写字是非常有趣的过程，看着不懂的内容，写出来，哪怕是对照着一字一字写，也能快速在脑中构建清晰的思路，这也许是使用文章输出进行学习的真意吧。现在是23点35分，无眠的朋友们晚安，有眠的伙伴们好梦。
—— end ——
全部内容链接：
用户故事地图（1）：体验用户故事
用户故事地图（2）：作用
用户故事地图（3）：故事与卡片
用户故事地图（4）：创建方法
用户故事地图（5）：开发流程之“机会”阶段
用户故事地图（6）：开发流程之“探索”阶段
用户故事地图（7）：开发流程之“设计”阶段
用户故事地图（8）：开发流程之“故事工作坊”阶段
用户故事地图（9）：开发流程之“研发-评估-交付”阶段
用户故事地图（10）：开发流程之“回顾”阶段
用户故事地图（11）：故事（需求）拆分
用户故事地图（12）：后记
