最近闲来无事，把盘出包浆的《武林外传》又翻出来追了一遍顺便当下饭视频。正好看到第39集《吕秀才得理不饶人，郭芙蓉自食苦月饼》中，李大嘴为钱掌柜三做月饼的情节：明明（追加款项后）秉承“客户就是玉帝”的李大嘴做的都是惊世骇俗的作品（放到现在量产分分钟几百万上下那种），可是依然导致希望获得“天下独一份的月饼”的钱掌柜，“兴高采烈地回去了，鼻青脸肿地回来了”，最后还是嘱咐李大嘴做了份普通月饼草草交差。
正所谓创作工作千千万，“会呼吸的痛”总是天下大同：明明花了时间和精力、做出来的作品单从设计维度来看也是好作品，但是利益相关人总是不买账，最后干脆“用回第一版设计”。那我们怎么改变这种现状呢？换句话说，假设你进入了《重生之我是李大嘴》这个游戏副本成为了刚接到需求的李大嘴（读者：我可谢谢您了…），你会怎么改写李大嘴做月饼的故事，做出符合钱掌柜需求的的月饼呢？
1. 他没有在开始做需求前，理清利益相关人之间的关系及每一方的需求。取而代之的是，他闷头花费大量时间做出“提案”，用“提案”去挤牙膏似的从钱掌柜的反馈中，逐渐获取更多需求相关的信息。
2. 他拒绝团队合作和反馈，仅凭主观意识去获取局部信息。比如在搞清楚什么是“犹抱琵琶半遮面”这个需求点时，他询问秀才的是“这句话是什么意思？”，而不是“你觉得这句话在月饼中能怎样体现？”“你觉得我的作品符合这个描述吗？”。
3. 他在正式提案前没有进行任何内部测试和迭代。在给甲方钱掌柜呈现每次的提案前，他既没有自己试吃，也没有邀请大家来品鉴和提意见，进行团队内的改进和迭代，而是直接把提案急吼吼呈现给了甲方，导致了最后差点翻车翻到终极甲方爸爸——娄知县那里去。
你看，需求理解不透彻、反馈收集不深入、迭代优化不彻底… 换个场景就很像我们平时做设计工作的时候犯的问题。果然，人人都笑李大嘴，人人都是李大嘴。其实说到底，这些问题的根源就在于：虽然我们做的是设计工作，但是我们从未带着设计思维去做工作。
那什么是设计思维呢？简单来说，它就是一套探索设计解法的方法论：以人的需求为出发点，创造出符合其期待的解决方案。如下图，它包含了共鸣用户、定义问题、形成概念、绘制原型、迭代方案和实施这几个环节。它秉持的理念是“好的解决方案是沉淀出来的”——在实际场景下运用这一套方法时，我们往往获取的先是几个不同方向的提案，再逐渐按条件剔除，最后获取一个或一套“最佳解法”。
带着设计思维去解决问题，有助于我们脱离“问题→答案”这种简单粗暴的直球式思考模式，让我们更能够带着批判性思维、深入表象看问题，从而呈现更合理、更有创造力、更彻底的解决方案。说到设计思维的优点，最经典的案例就是亨利·福特开创福特汽车公司的那个耳熟能详的故事了：用户说想要的是跑的更快的马车，福特回去一顿想，最后给弄出了辆汽车出来。如果他当初带着直球思维，去思考的恐怕不会是“用户到底需要的是什么”，而是“如何让马车跑更快”。那么，汽车工业革命恐怕要变成马车工业革命了。
同时，在实际场景中，我发现这种思维模式引申出的工作模式，有助于增加设计师和其他团队角色之间的信息互动，让别人更了解我们的工作和专业能力所在，提升设计角色在团队中的影响力，从“弟位”到“地位”指日可待。
关于设计思维的概念咔咔说了那么多，再接着讲方法论可能就开始逐渐抽象了。那么接下来，让我们重新回到钱掌柜委托做月饼的副本中，带着设计思维来探索这“天下独一份月饼”可能的设计解法：
第一步：与用户产生共鸣
由上图可见，当前情景下的“月饼”其实更类似于2B类产品——“用户”（这里我将其解读成“利益相关者”更合适）不单单指最终吃到月饼的娄知县，它还包含了甲方的关键采购者，即钱氏夫妇。毕竟，基于使用者去探讨产品好不好用的前提是，这产品得顺利到达使用者手上，而采购方正是决定这个前提的关键角色。所以说，不仅用户是玉帝，各位老板也得是玉帝啊…
为了让以上关系链能够顺利运行起来，让“月饼”最终落到娄知县手中，“月饼”需要达成的目标就是让所有的利益相关人的痛点，甚至是期待点都得到满足。
那么接下来，我们要做的是通过共情用户来探索关键利益相关人的画像（心智模型），找出他们的痛点/期望点。如下所示，是我看了n遍武林外传后，根据情节总结出的关键利益相关人的画像：
第二步：定义问题
接下来，我们需要对关键利益相关人的痛点/期望点进行卡诺分析和聚类，从而找到问题所在（这也就是后续我们展开设计的时候，要探索的关键点）。
首先将上一步提到的“关键利益相关人的关注点”，按种类分成时间、月饼、月饼盒三个组别，接着我们可以再进行卡诺分析，将关注点分为基本型需求（必须要满足的绝对条件）、期望型需求（关键角色意识到的期望点）、兴奋型需求（关键角色并未意识到的问题，通过梳理人物的心智模型找到的隐藏关键点），如下图：
如上图圈出来的部分所示，这就是我们在研究了关键利益相关人之后，沉淀出来的、后续展开月饼的设计提案时，需要重点探索的问题。对这些问题我们可以再再进行聚类，则又可以将其分成意向、诠释手法、表面媒介三个类别：
第三步：围绕问题进行脑暴，形成概念
哎哎哎，还没到开始做月饼的时候呢，请各位李大嘴先将手中的锅碗瓢盆、油盐酱醋放下来，并关门放吕秀才——接下来我们需要基于上面一个环节探索出来的关键点，开始合理又离谱的脑暴。由于我不是真的能召唤出同福客栈的全体员工坐着讨论，这里就先不上眼花缭乱的脑暴会议主持手段了，大家自行百度谷歌。咱们这儿先返璞归真，用最朴实的思维导图，推演最离离原上谱的ideas。
这边我用三种颜色代表了三种来源不同的思维导图节点：
这样标记有个好处是，当绿色的部分灵感不够的时候，我们可以努力刨一刨用研资料、数据报告，搜一搜百度，充实一下黑色和白色的分支，多开几个大道，总能联想到罗马去。以下是我随意发散的一些例子，相信一千个李大嘴，有一千个哈姆雷特，啊不，是一千个思维导图：
我们先将意向和诠释手法中，看起来比较可延展的要点分别标记出来（如上图所示的红色文字），并且将这些要点进行穷举式组合、筛淘出可行性比较高的概念层面的抽象方案，如下：
接着我们可以对表面媒介的可能变体的点进行脑暴，如下所示：
最后，我们把筛淘出的概念层面的方案，结合上述的表面媒介可能变体的点进行揣摩和思考，可以进一步细化和筛淘设计方案。最后筛淘出的可落实方案，比如（不是专业搞包装设计的，我悄咪咪用抽象点的示意图划个水，见谅见谅）：
需要强调的是，在获取了背景信息和设计目标（问题）后，本环节中设计方案的概念发散和聚合工作，最好能让团队中最相关联的职能角色全都参与讨论，并最终达成共识。原因是：
1. 不同的职业和社会背景的参与者，能增加思维发散环节的集体创造力和启发性。
2. 更多的职能角色意味着，方案将被从更多角度推敲，能让最终筛淘出来的方案更具有可执行性。
3. 最终成品往往需要团队合作共同完成，更早让团队参与意味着更低的信息不对称的风险，后续执行时实际产物跑偏的概率能下降。
比如在李大嘴做月饼这个情境中，同福客栈的掌柜和伙计作为相关职能角色，他们的职业和社会背景非常不同，在讨论最终方案时，就能从不同角度给出建议：
第四、五、六步：绘制原型并迭代打磨，直至可以发布
接下来，我们需要将想法进行落地，并不断迭代优化直至满意。当然，落地后的迭代并不能大而化之、糊里糊涂去做。产品可能分为不同的元件部分，且各部分之间的关联度有强有弱，目的也是各不相同，因此如何将落地+迭代的产品功能范围，进行合理分组，以及如何设计落地后的迭代计划，就显得尤为重要。
首先是落地设计方案的环节。在李大嘴做月饼的情景中，由于涉及的产品——月饼，分为盒子和月饼本饼两个较为独立的部分，佟湘玉需要根据每个人的职业技能，做出如下可独立运行起版本迭代的分组规划：
接着就是按照计划分别开始独立的内部迭代和共同的外部迭代了。需要强调的是，在开始内部迭代前一定要设置一个迭代评价标准，以便于在同福客栈品鉴大会的时候，有的放矢地去检验产品的各个部分是否已达成要求，是否可以停止内部迭代、进行下一个环节了。而后，钱掌柜可能会再提一些继续优化的反馈意见，或者直接开心收货、向娘子交差了，而这一步以及后续的打磨修改就是外部迭代了：
这样我们就运用设计思维，完美通过了《重生之我是李大嘴》的中秋做月饼副本了。相信这样一份精心分析、琢磨出来的月饼，能让钱夫人看了放心、娄知县吃了开心，能让李大嘴升职加薪、担任总经理、出席CEO，成为同福客栈首席厨师不是梦（那啥，虽然客栈也就他一个厨子…）。
好滴，李大嘴副本到这里先暂时完结撒花辣~接下来，为了更（不）深（离）刻（谱）解读设计思维的实际应用效果，给大家举个我作为UX设计师的、在实际工作中的例子吧。
举一个（糖炒）栗子
如下图所示，是一个租赁双方基于租赁时期产生的物品损失或人身伤害，进行协商索赔的、短租平台提供的官方流程：需要索赔的房客，要选择索赔种类、填写索赔金额、提交相关证据以完成索赔申请，而房东则需要操作同意/拒绝索赔。若申请被拒绝/过期未处理，申请则会直接提交到客服部，由客服专员进行进一步沟通调解。
这个流程的产品目标是：能尽可能提升该流程下的索赔申请的解决率，从而降低用户转而联系客服处理的数量，以及申请后续被客服介入的数量，最终有效降低客服成本。当时数据信息表现出来的直观问题是：房客的 申请提交数/索赔事件总数 极低，用户在申请过程中的跳出率较高。所以团队当即做出的下意识判断是：（基于申请索赔的页面是分散式的按步骤申请），应该将索赔申请的填写表单进行整合，降低房客在频繁的跳转中引发的跳出可能。
这个需求如果按部就班梳理下去，那么后续设计师重点发力的方面就是“如何精简多任务表单，减少页面跳转”了。但是当时我注意到数据信息的两个异样：
1. 在整个索赔流程中，房客的跳出率呈现前多后少的趋势（即在选择原因、填写金额的页面多，在上传证据的页面少）。而一般因为流程过于碎片化而导致的跳出较多的情境下，高跳出率往往集中在流程的中后段。
2. 房东的接收率较高，但是查看了页面后的拒绝率/过期率十分高。显然房东这边也有缘由可深挖，我们解决问题不应该仅仅盯着房客方面的流程。
基于此，我对产品的解决思路提出了质疑，后续又邀请了用户研究专家组织了有申请成功/失败记录的租赁双方用户，进行了深度的用户访谈，从而共情角色并建立了角色画像：
果不其然，我们在共情角色的历程中，有了新的发现和认知：
由于房客的最大目标就是：尽可能让申请被出租人或客服尽快通过、从而获取赔偿。并且，他们操作申请时，往往都是准备好了材料、专门辟出时间专注于填写表单的（毕竟涉及的金额往往都不低，值得认真对待）。因此，他们对于流程的跳转频率并没有明显的用户体验上的“不适感”，更别提“因为跳转多而退出”的这种可能性了。
取而代之地，真正的问题在于：模糊的填写指南和严格的审核制度，导致用户不敢贸然提交申请——毕竟索赔申请关系到用户的信用等级，且为了防止恶意申请，用户的可申请次数是被限制的，因此用户对提交申请的举动十分审慎。但问题在于，当前流程中没有明确可参考的索赔标准，以及针对不同类型申诉的证据种类模板可以参照。这就导致了房客更倾向于放弃申请、直接联系客服咨询并委托调解，一了百了。
而对于房东，本着保持好评率、但是又要考虑盈亏问题的立场，往往对待申请的态度是讲理又慎重的。但是由于在房东端的索赔申请处理流程中，也缺乏了索赔标准相关的参考信息，他们往往倾向于直接拒绝或让申请过期，然后把烂摊子丢给客服去处理。
以上的问题也侧面呼应了上文提到的数据信息的两个异样点出现的原因。到了此时此刻，我可以更加自信地定义出后需要探索的实际问题：如何在索赔申请的流程中，添加能让用户自信进行操作决策的索赔参考信息？
接下来就是脑暴环节，为了提升脑暴的效率和最终建议的可采纳率，我的做法是：专业的领域让专业的人去脑暴。如下图，我邀请了以下的团队中的关键角色（包括我自己），围绕各自话题展开圆桌式脑暴：
然后我快速画了一些提案，就提案价值和可行性和上述关键角色进行了探讨，并最终几经删改敲定了如下方案，最终事实证明这也确实是正确的解决问题的方向：
你看，运用了设计思维去探索设计问题的话，我们的创造力变得更加“有的放矢”了——每个设计依据点都是环环相扣、信息充足的，我们可以更加自信、高效地去创造了。同时，由于设计过程不再是直球思维式的“从问题到解法”模式，而是被拉长填入了探索、脑暴、收敛、实践这些流程，更多的职能部门能更早期参与进去，基于建议或共同进行决策。这非常有助于减少后期的沟通成本，同时也是给其他职能部门打开了一扇能一窥设计世界究竟的窗口，对提升设计角色在团队的话语权非常有帮助。
1. 找出并了解关键的产品相关者，从行为（听、看、说）分析他们的想（期望和目标）是什么
2. 找到实现他们的期望和目标，还缺少的信息、还需要解决的问题
3. 邀请团队相关职能角色，一起围绕关键问题进行探索和脑暴，一起收敛出可执行的设计方案
4. 以各组件的独立性为标准，将产品分组并进行初代MVP版本的探索、设计各部分的迭代预期
5. 通过内部迭代和外部迭代，打磨产品直至符合预设的标准
那么问题来了，下次当你在工作中又又又遇到了《重生之我是李大嘴》的中秋做月饼副本的话，你会做出怎样的月饼呢？
转载：https://www.zcool.com.cn/article/ZMTQyMzY2OA==.html#kuak
作者：RenaHuang
17期早鸟预定，10月中旬开课，点击查看，8个名额
本篇文章来源于微信公众号: 应谋鬼计
