借此文谈谈，我所理解的全链路设计究竟是怎么样的。

最近所谓「全链路设计师」的话题很火，不过坦白来说，在我的认知里全链路早就不是什么新鲜的概念了，而且也并非什么岗位头衔（和全栈、什么都能干一点的定义是两码事），更接近于一种设计思维与方法。全链路设计也不是适用于所有业务的，对于贯穿线上线下、涉及到的角色和接触点多的场景，它可以发挥的空间更大；而对于纯线上、用户单一、接触点少的场景，则并没有什么明显优势，不适合盲目进行套用。

笔者这段时间以来刚好参与过一些适合应用全链路设计的业务（LBS、票务、旅游……），学习使用了一些相关的服务设计方法，也在过程中感受到了和传统设计流程的种种差异，所以想借此文谈谈，我所理解的全链路设计究竟是怎么样的。

接触的需求更加「原始」

在需求阶段，我们比较传统的一种流程，是被动从产品经理处接受已被加工为具体方案的需求，对需求产生的背景并没有什么深刻的接触和理解。而在进行全链路设计的业务场景中，业务方不会直接给你一个加工好的答案，甚至他们自己都没想清楚问题出在哪里、应该如何解决，而更多是带着一个提升某业务指标的原始诉求或一堆零散的原始用户反馈来找你；至于怎么从中引导对方发现问题、分析问题、归纳机会点、输出能帮助达到商业目标的产品设计方案、甚至协调推动落地，都需要设计师作为 Owner 去思考和负责。

如果说传统流程中我们需要从产品给的方案里对需求进行逆向推理还原的话，全链路设计流程里，则是一开始就要自己从「混沌状态」里抽丝剥茧，驱动对方一起思考和找到答案。这个过程中有很多方法可以帮助我们，比如对方提过来的是提升转化率一类业务指标，可以使用用户行为漏斗分析看各个阶段的数据流失情况，找到问题集中在哪；又比如对方给了一堆原始用户反馈，可以用 Service Blueprint、Task Grid 等方法分阶段归类问题，用 5 Why 分析法层层推导问题本质、还原问题场景，进而找到解决问题的思路，等等。除此之外，亲身去线下场景实地体验走查、拍照记录，把自己深度代入用户视角去感受问题、发现机会点也很重要。

（图片来源）

（图片来源）

设计的对象更加多元

之前提到全链路设计更适用于贯穿线上线下、涉及到的角色和接触点多的场景，而这也意味着我们设计的对象会变得更加多元化，不只是前台的数字产品界面，也包括整体服务流程、线下实体物料、后台配置方式等，这样才能给用户一个更加完整而非割裂的整体体验。

再换一个角度，即使出于一些限制我们不能直接去改变一些流程和触点的设计方式，在前期阶段将他们考虑进来也没什么坏处，一些在这些触点上可能遇到的问题，也可以通过我们能控制的数字产品界面设计来提供解决方案。比如线下地标不明显导致迷路的问题，除了对地标本身作出改进外，也可以用线上导航/AR导航等方式来解决；又比如各种延误、排队的等待类问题，可以通过提前预警通知、备案建议、提供打发时间的互动方式来给用户更好的终端体验。

连点成线构建成闭环

在考虑服务流程中多个角色的诉求时，如果只是孤立地围绕每一个角色去思考，那和传统的以用户为中心的设计思维并没有什么区别；而我理解的全链路思维还应该在这个基础上更进一步，将不同角色的诉求连接、整合起来考虑，设计出合理进行资源分配，最大化各方综合利益的方案。

拿之前参与过的一个票务场景举例，人们来票务平台咨询的目的各不相同，有人想买到心仪演出的票，有人临时去不了想退票，如果只是孤立地考虑流程，很容易被平台本身的一些规则（票量有限，一经售出概不退换等）所限制死，而如果将两者的诉求整合起来，建立有平台保障的二手交易资讯闭环，则可以实现更加合理的资源分配，让多方都感到更满意。

除了角色闭环之外，还有用户使用产品本身的闭环，设计师考虑的不应只是某个具体页面布局或者组件的设计，还包括用户怎么产生动机、形成接触、深入使用、建立忠诚度、主动扩散与传播等，这一点对于角色和接触点少的纯线上场景也一样适用。

提案落地的跟踪推进

交互设计师考虑问题会有尽可能完整周到的习惯，但实际可以落地的方案。因为资源和时间限制，往往很难还原到我们基于机会点提出的概念设计的方方面面，而只能从其中的几个点优先切入。

这也就需要我们在提出解决方案的同时，对解决方案背后的问题影响面有清晰认知，知道什么是高频场」、什么是长尾场景，和利益相关方一起进行优先级拆解，梳理迭代节奏计划表，必要时准备合适的过渡期 MVP （最小化可行性）方案，进而推动其更好地落地，并在解决方案上线之后进行数据反馈追踪，发现问题及时分析和推动迭代改进等。

本文由人人都是产品经理专栏作家 @鸿影（微信公众号： 鸿影的设计思考录） 原创发布于人人都是产品经理 。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议