如何将服务设计的思维，应用在产品体验设计？
服务设计在各个行业有着其使用和落地的特殊性。对此，本文作者总结分享了如何将服务设计的思维应用在互联网的整个行业中，以及如何使用服务设计思维更好地理解业务、梳理业务和推动业务。希望对你有所帮助。
服务设计随着时间的流逝，也随着所用之人在各行各业的沉淀和积累，可以看到其在各个行业有其使用和落地的特殊性，本文是Yeutz在实际工作和实践中逐步去总结，如何将服务设计的思维应用在互联网的整个行业中，去使用服务设计思维更好地理解业务、梳理业务和推动业务。
为了方便记忆，本文的结构分成服务设计思维融入互联网产品体验设计的1234，即1 个定义、2个特性、3个方法和4个警惕 。
一、1个定义：解决复杂性的系统内外问题的思维——服务设计思维（SDT） 关于什么是服务设计思维这个问题，要提到 服务设计思维五力模型 。
服务设计思维定义（从五力模型角度）：服务设计思维是一种基于系统性思维、复杂性思维、创造性思维、战略性思维与批判性思维等五种思维模式为一体的有效解决各事物间的关系要素问题，从而形成的一种基于服务和体验领域的特有方法论和思维体系。
服务设计思维五力模型
而简单的定义其实就是： 解决复杂性的系统内外问题的思维。 至于解决什么样的问题，以下引用Cynefin框架是对问题的四个象限的定义， 随着当前世界、社会、行业、业务这层层剥离下的问题，都可以根据复杂程度用这个框架去定义不同的问题。而服务设计面向复杂和繁杂的问题更适合用它的思维去理解和梳理，从而想出解决方案。
肯尼芬框架（Cynefin framework)
进入一个环境，我们很容易就能区分出两种状况：
清晰的（clear）系统 混沌的（chaotic）系统 但介乎于清晰与混乱之间的状况却很难被区分。这样一来， 感知能力就变得极为重要，感知能力会让你搞清楚现在的状况。让你清楚是该借助过往的经验和手法处理问题，还是探索新方法、新方式解决问题。 肯尼芬框架是在清晰和混沌两种状况之间（或被称为混沌的边际 the edge of chaos），增加了两个维度：繁杂（complicated）与复杂（complex）。
在肯尼芬框架下，朝着箭头指向逆时针旋转，系统的复杂性越来越大。在清晰的系统内，只要遵照某种SOP，遵循流程去走，事情就会自然而然步入正轨。随着不确定性提升，有些议题的答案变得模糊，这些议题就落入了“繁杂性”系统，需要专家通过足够多的案例经验来摸索路径。解决问题的办法不再是遵照流程，而变成了摸索前行。
接着我们会发现，黑天鹅事件一次又一次席卷而来，无论是整个社会还是市场中的大多行业都慢慢走进了复杂的区域。最后，我们来到箭头朝向的终点——混乱，系统性崩盘。在这一系统内，你不能想、不能感知，你要迅速作出反应。
而面对业务这样的一个小系统来说，面对问题帮助决策，该框架也同样适用。
二、2个特性：流程性、系统性 之前的文章中有多次提到服务设计思维的2个应用特性： 流程性、系统性 。为什么会这么说呢？服务设计通常使用的工具都是从这两个维度入手，同样也是解决这两个维度下的问题。例如互联网行业概念中的用户全生命周期，用户路径、用户旅程、增长模型、上瘾模型等等都是流程性的概念，这样的概念下，服务设计将适用于逐层拆解，逐步发现问题并提供解决策略。
相对地，互联网行业中的一些行业概念如：业务模型、数据模型、商业化、用户增长等其实都是系统性的问题，服务设计需要在其中去剥离具体的系统要素，而通常流程性和系统性是同时应用去解决问题的，因为复杂性的问题必然存在着这两个维度。
服务设计流程性案例：服务设计如何赋能用户增长分析了服务设计针对流程性的内容有着天然的优势，所有流程性的业务/情况都可以运用服务设计梳理一遍 服务设计系统性案例：服务设计如何赋能商业化设计策略分析了服务设计的系统性是如何帮助商业化设计高效产出有效的方案 三、3个方法：战略性思维、数据性思维、系统性思维 1. 战略性思维拆解行业背景和业务定位 （1）Why
战略性思维强调全局观，从 整体性的视角 探究行业去判断和定位当前业务在行业中的情况，帮助理解业务全局和业务所在的时期和阶段，来判断整体价值和可能达到的效果如何，使用这个方法可以避免 被产品团队牵引而失去自我判断 。
（2）How
这里重点介绍 价值链 ，即一个行业/系统的上下游关系，以内容行业举例，分为：
内容生产——内容供给——内容分发——内容消费
这里面又涉及到了创作者、消费者、平台三个主要角色，顺着这样的思路拆解下去就能明晰 看到行业现状和业务之间的关系 ，从而懂更高的维度洞察业务。
内容行业价值链分析 （仅举例）
小程序游戏行业价值链（研发-发行-消费）分析 （仅举例）
（3）What
基本上的产出如上图所示，但是具体业务和行业具体分析，除了从行业报告中去寻找/查看相关的价值链分析之外，也要从自己所在业务去放大业务所在的模块，看价值如何流动。
2. 数据性思维赋能产品策略和业务创新 本是系统性思维中的一环，但是数据对互联网行业乃至各行各业的重要性是有目共睹的，因此单独提出来看服务设计应用的具体思路。
（1）Why
数据作为判断互联网产品的核心指标之一（这里强调“之一”是避免误导大家数据作为唯一要义去判断），数据性思维有效帮助业务在「探索期」和「成熟期-衰退期」的时候能够作为引导依据，辅助决策，但值得注意的是： 数据背后的信息重于数据本身。
（2）How
数据性思维的背后，实际上也是为了引导业务从数据维度发现问题分析问题和解决问题。因此数据性思维这里的方法更多是从数据维度拆解业务。从最早阿里整合出的GSM模型，主要针对设计度量去看，但其从还原论的角度看，数据也同样遵循类似的拆解，即引用增长黑客一书里介绍的 「北极星目标-过程目标-核心策略」 逐步拆解下去。
阿里GSM模型
以GMV为指标的业务拆解模型
（3）What
数据模型具体拆解根据业务的指标和不同需要有不同的拆解方式，本文不展开讲述，后续有机会单独一篇文章讲解这部分的内容。但具体拆解的结果可以 结合用户行为和用户旅程去梳理 。
业务逐层拆解的数据模型
3. 系统性思维深入产品细节和业务耦合 （1）Why
系统性思维用来逐渐地深入到产品的细节中去，不只是看细节， 而是从系统要素的角度去分离开细节，从整体到局部，再从局部到整体，逐步放大和缩小，这样视角的切换能够弥补自己在业务中的常态以及对整个行业的感知力 。
而随着系统性思维的深入，你也会发现当前个人乃至团队所做的事情只是整个系统中的一环而已，而更应该从全局视角去看待业务之间的耦合关系，达到整体之和大于各个业务之间相加，虽然这很难，但需要有这样的视角去把自己放在一个全局的位置去思考，才能更有力的推动业务发展。
这里引入一个最近比较火爆的模型：L型赋能 —— 赋能是指将我们孵化成功并验证有效的项目，复用给同样需要这个能力的业务团队，降低重复孵化的成本。我将这个过程称为“L 型赋能”，垂直地做好自己原本的业务，就像 L 的竖线，再横向影响到其他业务，就像 L 的横线。
L型赋能（引用自极客时间）
（2）How
以我们耳熟能详的两个项目举例。电商 App 中双 11 的主会场设计，有许多模块容器给业务带来了显著增长，这样的设计方式就可以复用给其他的大促主会场；Ant Design 的出现，在满足自身业务之后，开放给市场，供更多阿里内部或外部的 B 端产品高质高效落地。不管是负责单一业务的设计，还是同时负责多条业务的设计，我们都可以将项目影响力进行扩展。在之后的课程中，我们会以具体案例一起了解如何将项目成果进行 L 型赋能，扩大项目能力的影响力。
（3）What
这里产出更多的是全视角的业务贡献，具体情况需要具体分析，没有成型的产出物的引导。
四、4个警惕 在应用上述思路的时候，要注意有4个值得关注的点，这里称为4个警惕：
1. 警惕过于全局分析而模糊的行业颗粒度 在分析整个行业的时候，有时候我们会深度探索整个行业的深度，但是这个时候需要浅尝辄止， 了解整个行业全貌后还是要回归本身业务上去看整体和局部的关系 ，在业务上继续细分具体的内容及可能的业务规划和发力点。
2. 警惕强数据思维和弱用户思维的准确性 在分析业务数据和指标的同时，也要对用户有所了解，数据只是辅助决策方法之一，用户侧的内容也会给予不同的帮助， 从数据的角度去看大的变化，从用户角度去看更细节的感知和感受，同时也要避免把自己当作真实用户 ，更多还是要去以CE的角度去发现新的问题，结合数据验证，才能达到相对准确的判定。
3. 警惕产品体验与产品管理之间的分界限 写到这里，大概有小伙伴会问，产品体验做到这几个思维程度，那和产品经理的区别是什么，我们更多的是在做体验的管理而不是整个产品的管理，产品的体验的部分负责除了基础体验还有业务未来可能性的探索，这部分也是体验的一部分， 确认好各自的界限，但也要保持持续合作的关系，互相给予新的思路和方向 。
4. 警惕深入细节而忽视全视角下的业务线 最后一个警惕就是涉及到逐渐深潜在某一个具体业务的时候，会更关注业务的细节而忽视掉全貌，这时候就是警惕去看整个业务线当前的发展趋势是什么，再来看这个细节是否会有所影响， 考虑细节和全局的关系，会比设计师只埋头进入需求更重要 。
五、结尾 本文总共分为1个定义、2个特性、3个方法和4个警惕，帮助大家更好的记忆，其次，本文致力于帮助服务设计背景的互联网产品设计师们从服务设计视角进行实战业务，帮助设计师开阔思路和理解业务，也帮助互联网设计师们了解并应用服务设计思维解决问题，期待和大家后续的更多交流。
作者：Yeutz Chen，微信公众号：YeutzDesign（ID：Yeutzsheji），专注于服务设计领域，致力于服务设计创新转型研究。
本文由@陈昱志Yeutz 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
给作者打赏，鼓励TA抓紧创作！
{{{path> 赞赏
