数字化转型与架构 - 规划篇｜殊途同归的解决方案框架

　　IDEO 是全球知名的设计和创新咨询公司，Google 是全球知名的科技公司。如上图所示，两家公司的解决方案设计方法有很多的相似之处。完整的设计过程，都包含定义问题、方案创造、原型制作和测试验证，这四个主要阶段。设计思维的框架更看重定义问题，通过与用户共情的方式一起探寻问题的起因。设计冲刺框架更看重创造部分，创造出更多的方案进行选择。

　　数字化转型的解决方案不是一份 PPT 或者一套系统设计方案。解决方案应是一套完整的运营方案或者配合运营方案的系统设计。我们根据收集到的业务流程、甲方业务需求和各种内外部约束开始进行设计。经过前几篇文章的介绍，我们已经完成了‘定义问题’的阶段。部分用户对问题已经有了自己的定义，甚至已经给出了部分“答案”。但是，我们需要依据调研信息、借助分析方法，独立完成从问题定义到方案创造的这两个过程。下面我们将使用头脑风暴方法（Brainstorming）尝试解决问题。

头脑风暴

　　头脑风暴是一种开放式讨论的会议方式。参与者可以围绕待解决的问题，提出各种无外界限制条件的结局办法。但是，头脑风暴并不是随心所欲的茶话会，也需要遵循几条基本原则和流程。

畅所欲言，不墨守成规；

接受想法，不品头论足；

数量优先，不苛求细节；

取长补短，不闭门造车。

　　这四条原则，保障了头脑风暴的开放性。头脑的风暴的可执行性需要通过下面的流程和方法进行保障。

　　第一步：问题定义。所有人将自己发现的问题写在便条贴上，每个便条贴上只写一个想法。大家轮流的介绍自己的想法，有不清晰的地方可以提问，但不要质疑他人。将问题分类，合并重复问题。最后对问题进行投票，排序出问题的重要程度。

定义问题示意图

　　第二步：解决问题。此步和第一步的流程类似，只是我们要提出的是解决上一步问题的方案。在介绍每个方法的过程中，可以适度提出改进意见。在最后一步的排序过程，我们要评估所有方法的卓越度。在最终方案中，满足所有最基础的方案，尽量完成更多的进阶方案。

解决问题示意图

　　解决方案制定之后，我们开始着手制作原型，为获取到用户的真实反馈进行准备。

原型制作

　　原型是按照头脑风暴的结果制造出用于演示的模型或者系统。原型是为了试跑完整的业务流程，而不纠结在某一个操作细节。早期的 IT 系统原型多为可运行的 Demo 程序，Demo 程序一般为演示部分功能进行开发。虽然 Demo 程序的功能和性能有一定限制，但是交互体验较完整。随着系统的复杂性增高，逐渐演变为制作更容易的 Axure 等产品设计工具。产品设计工具绘制的原型一般只具有简单的交互界面。

　　在原型制作的过程中，遵守几个基本原则：聚焦在核心功能和用户体验；准确表达业务关系及流程；最小化制作成本。这些基本原则的目标都是为了缩短验证和迭代的周期。

原型示意图

验证迭代

　　验证方式一般分为两种：面向企业的系统通常采用评审会方式，面向终端用户的系统多是用户体验反馈方式。

　　评审会的方式通常由一位产品负责人进行讲解。负责人通过原型演示实现业务的全流程。在演示的过程中，参会人员都可以要求产品负责人澄清未描述清晰的事项。最终，对整个解决方案进行评审，确认待改进的部分或通过验证。

　　用户体验反馈可以邀请真实用户参与进来，获得最直接的反馈信息。如果是成熟的软件产品进行迭代，在发布新版本前也会收集用户体验反馈。企业会筛选出一批种子用户参与体验和反馈。例如：手机 App 会推送体验版本下载消息。当用户同意后，可以更新到 Beta 版本的软件，参与使用和反馈。没有条件的情况，也可以请未参与设计的企业员工进行体验。至此我们又可以使用用户旅程图帮助完成用户反馈的评级。

　　解决方案的前一部分流程，同需求调研有一些重叠的内容和步骤。但是我们的前置输入条件并不一样，在调研过程中我们倾听客户的意见，在设计过程中我们激发自身的创意和灵感。最终还是会依据客户的外部环境限制进行调整，制定出可落地的方案。

划重点：

解决问题的通用框架：框架包含发现问题和解决问题，经过多次的发散和收敛执行完成整个框架的流程。第一组的发散和收敛过程，解决问题是什么（What）。之后的发散和收敛过程，解决怎么处理问题（How）。不断的调整解决问题的方法，直到满足预期效果。