说“全链路设计”之前，必须稍微说几句另一个词——“全栈”。
“全栈”的概念在最近几年非常流行。追求扁平高效和极致的互联网有着越来越快的更新节奏，让我们越来越不能忍受高昂的沟通成本、繁复的工作流程和不同岗位之间的隔阂。
最早的互联网人大概就是“全栈”的，他们自己做开发、做设计、做运营推广。但是，随着产品越来越庞大，竞争越来越激烈，我们做产品的方式也愈发趋于精细化。在大公司，一个需求的实现，有产品经理、交互设计师、视觉设计师、前后端工程师、测试、用户研究等多个岗位共同支持。
精细化的好处是什么？
是术业有专攻，专人做专事，可以把产品打磨地更细致；是团队组件化管理，职责和目标分明；是为大公司这台机器打造高规格化的“螺丝钉”，当其中一个零件出了问题时，轻松更换。
当然，这些好处的代价，就是层层递进的沟通成本。以及对个人能力的限制。但不管怎么说，存在即合理，当大家都这么做时，必定是利大于弊。
扯远了。
我第一次听到
“全链路设计”
这个词是在今年初的年会上。不过，在提出具体名词之前，工作内容上其实已经有所体现。
一年前，我的工作内容集中在某一块具体的产品线上。比如搜索业务，日常工作主要是处理各个业务方的需求：手机行业运营说我们要在搜索里透个参数，帮助用户对比；用研同学说要在搜索里发放问卷，搜集用户反馈；客户端产品经理说要做更多导购内容......总而言之，横向产品设计师的工作更多是“实现需求”，进一步还可以制定产品线规范（帮助需求更好地融合）等等。
这样做的问题是什么？是我对上下游业务背景及后续反馈都非常不了解。食品行业说要发放优惠券，那这么做的原因是什么？基于什么样的市场背景？有没有更深层次的竞争或商业目标？
这些信息在做需求的过程中层层过滤，到设计师手上的时候已经具像化为一个最直观的需求——做一个组件，一个功能，写几个字。
即便是针对某个具体行业的设计师，他也许清楚地知道上游发生了什么，但同样很难搞清楚呈现时的种种困难和障碍究竟来自哪里。因为他对横向产品和下游流程没办法都了解到。
这就是与“全链路设计”相对的“单链路设计”存在的问题。
所以所谓“全链路”，“全”并非是指事事亲为，什么事情都要参与，而是从自己所在的立场上，向周围各跨一步的工作方式。
就像“全栈”往往指的是技能上的集合，常说的开发、设计、产品、运营一手抓。“全链路”则更侧重于业务层面，不只了解自己负责的，更要了解前因后果。
“全链路设计”有怎样的需要，会带来怎样的好处呢？我说说自己的理解。
先说说对个人的要求。
一、更宏观的专业视野
工作之后，很多人的焦虑都来源于“精耕细作”。尤其在大公司，盯着眼前的一亩三分地，很容易让人忽视整个行业正在发生的变化，让人的视野变得越来越小。“全链路设计”对个人最大的要求，就是更广阔的视野。
以我自己“交互设计师”为例，平时也经常被朋友问到，究竟什么样的工作属于“交互设计”范畴？
除了最基本的放按钮、摆组件，写文案算不算？文字的颜色算不算？需求背后的商业目标制定能否参与？运营计划听不听？技术方案讨论？
答案很简单，只要是为了能够把产品做的更好的，都算。
在团队，设计师更像是粘合剂，能够把苍白的文字、数字变成直观的设计稿，能够连接各个不同的岗位。这也要求你对产品的前因后果都有所了解。
甚至，有经验、有想法的设计师可以和运营、产品深度合作，一起去制定商业计划和产品需求。更有厉害的设计师直接产出整套的产品方案和运营计划，推动运营和产品经理去落地执行。
互联网行业发展太快，技能和专业随时都会被刷新。能够沉淀下来的，是一些通用的处事方法，以及相对稳定的行业、商业本身。（比如过十年也许大家都不玩手机了，但是衣服鞋子制造生产本身不容易有太颠覆的变化）。
二、对复杂信息、领域的整合能力
设计稿画的好不好，规范用的溜不溜，早已经不是对资深交互设计师的要求了。设计师之间的竞争更多发生在对信息和资源的整合上。如果你一味只会画需求界面，能带来的价值可能会非常有限。（当然基本功还是要练好的）
拥有了更宏观的视野和工作范围后，你所接触的信息也会呈指数增长。
以前做规范的时候，写的都是这个某某组件尺寸如何，点击后会有什么效果，最多写多少个字之类的“容器规范”。而现在，开始从业务的角度去指定产品规范：哪些组件的功能是为了提升转化率？建议运营填写什么样的内容？导购文案有什么要求等等。
以前做设计，更像是搭台子，反正容器做好，里面放什么交给运营和产品，我不管也管不着。而现在，我会花费更多的时间和他们去沟通“内容”。容器，反而没有这么重要了。
除了整合，还需要学会借力。
了解整个链路的“玩法”后，必须要清楚地知道每个环节大家想要的是什么。行业运营想要的可能是最直观的成交额，产品经理想要的可能是转化率和横向需求整合效果，工程师则追求做事的效率和组件化程度。
其实这些诉求看起来是某个岗位特有的 KPI，但对用户、对产品本身来说，每一个都是不可或缺的。为了提高转化率，如何从运营选品上作出选择？如何向用户描述贵的商品好在哪儿？所使用的组件能否帮助开发提高效率？这都是需要考虑的。同一件事，对不同人用不同的说辞，最终达到一个整体性的目标，就是所谓“资源整合”和“借力”。
再说说对团队和产品的好处。
一、场景与场景的联结更佳紧密
去年一年我都在做纯前台客户端的表达，也就是用户使用产品时看到的那些界面。但事实上，对电商体系而言，
一件商品到用户手上，经过的流程中有80%以上都是用户不可见的
。所以只做前台表达，其实只参与了商业中的一小部分。背后那些仓储、物流、供应链都是你所看不到的。
