Design Thinking的适用性思考

接触到越来越多的DT,一直在体会与既往的咨询方法的差异点和优缺点,刚翻出来DT过程的文档,扫了一遍,有了点新的感悟。

我是做SAP出身的,所以,今天突然get到一点,DT和我原来所熟知的SAP咨询方法体系的基本差异在所谓“未知性”上。

做SAP ERP,通常通过用户调研,了解as-is后,我们就可以给出to-be是什么了,以及gap是什么,提升点在哪里。因为我们讲的是最佳实践,基于SAP的业务流程体系和管理方案,我们知道应该的未来是怎么样的。所以,我们不会把过多的重心放在跟用户聊,激发与激活他们的思考,让他们逐步形成需求。

但DT所解决的,或者说所适用的场景,是面向未知。我没有最佳实践,你也不知道你要什么,这时候不光需要乙方的脑力激荡,更需要的是甲方的脑力激荡,那么好,我们用一种形式化的方法和范式化的工具,来激发和激活大家,通过共创,定义出来我们的所要寻找的方向。这也就是DT的中文名字为什么通常被叫做设计思维“创新”工作坊的原因吧。

那么,在这种模式下,我们怎么应用DT方法呢?原来的方法体系扔掉?显然不是,那肯定是要适时适度结合的了。问题是怎么适时,怎么适度,怎么结合?

第一,面对未知时才考虑DT。如果一个项目是打着最佳实践的招牌,请不要再高举DT的招牌,否则这就是个自我矛盾的故事。如果面对甲乙双方都可以坦然承认,特别是乙方承认,且甲方认可:“我不知道应该如何,我们可以一起去创造”的场景时,这就是适当的时候了。我乙方虽然不知道目标所在,但我知道去到目标的方法,让我带着你上路吧。

第二,2B项目,有的时候可以把DT当做一块奶酪。DT的最常见应用场景是2C领域:面向消费者,项目双方都不是消费者本主,ok,我们来观察,然后头脑风暴,形成对消费者及其心理和行为的认知,从而指导产品的设计。2B领域里,用户就是甲方自己,甲方很清楚知道自己的工作流程和内容,那么在项目开始阶段,就不要一开始就引入DT。试想一下,DT是要纠集一堆人,分组讨论,每个组都画一遍同样的现状流程,有意义么?所以,最起码初版的as-is就应该用传统的方式做就好,找一两个关键用户,把基本流程讲清楚就可以了。然后,如果没有最佳实践,那么从as-is到to-be的过程中,要抓哪些重点,这些重点的关键改进方向是什么,群策群力的形式化方法和做说想感的范式化工具就体现出其价值了,这时候DT就可以闪亮登场了。这里面要注意两点,一点好,一点不好,应该说是一个可能的副作用。

  • 传统模式下,我们讲的是流程,DT模式下,我们讲的是用户体验,是以用户为中心的用户旅程,旅程也是流程,但此流程非彼流程。这里的主视角不再是完整的工作流程,包含着多个相互协作的角色,而是限定在某个主人公身上,他的所做所思所感所想,这时候,甲方参与人员从被动的被访谈者,变成了舞台中心的主角,大家围绕着他,关心他,期待他,他逐渐放开了自己,变得侃侃而谈,能说会道的他,看到他的一个个诉求被倾听和认可,感觉好极了。这是好的一面,DT激发了用户的活性,参与感、责任心有了明显增强,多个用户之间很可能还会卷起来。

  • 副作用么,则是,在甲方的滔滔不绝下,可能会得到大量的需求点,但由于体验者多为一线的人员,其视角受限,往往会陷入过于个人化、过于细节的境地,更坏的是,囿于既有的井口,想的都是怎么做井里的精装修,而很少考虑扩建、改建甚至打破这口井。

这个问题是尤为需要注意的,解决办法有二。第一,要配备资深的顾问,有经验有高度的顾问才有能力做适当引导。第二,项目经理或顾问组长要及时review各小组的成果,不要关注量,不需关注有多少需求点出来,而是要关注质,特别关注有多少高价值点需求,每个小组都必须要有三到五个关键提升点。第一轮,或者第一天下来,就应该有一些了,如果没有,就需要复盘了。

再往后,也不是to-be蓝图就有了,DT只是给了关键方向和点状主线,蓝图还是需要回到传统方法,细细的一点点讨论,形成完整的描绘。当然,这时候按照现时流行的方法,可以agile化,细化一点,做一点,不断迭代推进。

请使用浏览器的分享功能分享到微信等