最近大家都在说阿里巴巴将取消UI/交互岗位的招聘，取代以“全链路”设计，拥抱新零售。到底这是一个什么样的职位，来看高手们都怎么看待！
UXD 一词源自：《2017年设计师该如何转型？来看阿里UED掌门人的演讲！》
阿里内部设计师的思考：《最近很火的UXD是什么？听阿里巴巴设计师怎么说！》
一.?呆呆：
@Daidai丶呆?：其实，全链路”设计取代UI/交互岗位这个概念，在 UX for Beginners 这本书上由 Joel Marsh 于 2015 年就已经提出了。 已经是不能再老的话题了，我用白话文随便举几个例子来阐述下这个问题说明的当下情况。
螺丝钉概念
之所以做内部培养，其实在大厂工作过的朋友都会有感受，设计师顾及的面太窄了。导致在过需求出方案的时候，经常有产品或领导觉得设计师的方案不够具备全局性。
产品给了需求，交互出了方案，产品说：你的方案没考虑到成本问题；交互说：这样的体验能提升用户粘性，成本不是问题。（产品内心：没问题NMB，成本是你说了算么？）
「全链路设计」虽然是因为目前阿里内部业务线驱动所要培养的人才，但其实无论如何，设计师的思维方面本就该具备「全链路」（或者说全方面）这个概念。
小公司很多设计师同时会做产品、交互、设计的活，甚至会做测试、运营的工作，虽然相比于大厂培养出来的人才来说没有那么专业，但其实市场早就偏向这个点发展。
只是因为人们误以为的「专业」，而将其细分开来。所以你说取代不取代这个事情早就存在了，但其实没你想的这么复杂罢了。
真的是多专多能？
有看到小伙伴说：发展为 X 型人才，能力覆盖面要广，才有饭吃（才有出路）。
其实这里也是想多了，设计师要有产品思维，同时具备开发能力，真的是说「一人多岗」的意思么？
我还看到有人说：是不是说交互要会 UI 、懂手绘，再做做物料，同时还要做产品的工作？
这个其实是思考角度问题，如果真是这样，不仅行业人口缩水，产品质量其实也会下降。是大家应该都明白的吧？
其实整合第一点说的，就可以知道答案：懂得多是更好的配合其他人工作，而不是一个人去做多个岗位的工作。
比如开发跟你说一些很简单的东西：这个功能可能要用到 Android SDK 调用几个 API……然后你懵了。
该懂还是要懂，不过不管取不取消 UI 或交互的招聘，我都认为跟目前行业发展的关系并不大。一早就有这个思想的人现在依旧具备竞争力，担心的人应该是从入行之日起就打算做螺丝钉的人。
欢迎关注作者微信公众号：
二. 王镇雷
说“全链路设计”之前，必须稍微说几句另一个词——“全栈”。
“全栈”的概念在最近几年非常流行。追求扁平高效和极致的互联网有着越来越快的更新节奏，让我们越来越不能忍受高昂的沟通成本、繁复的工作流程和不同岗位之间的隔阂。
最早的互联网人大概就是“全栈”的，他们自己做开发、做设计、做运营推广。但是，随着产品越来越庞大，竞争越来越激烈，我们做产品的方式也愈发趋于精细化。在大公司，一个需求的实现，有产品经理、交互设计师、视觉设计师、前后端工程师、测试、用户研究等多个岗位共同支持。
精细化的好处是什么？
是术业有专攻，专人做专事，可以把产品打磨地更细致；是团队组件化管理，职责和目标分明；是为大公司这台机器打造高规格化的“螺丝钉”，当其中一个零件出了问题时，轻松更换。
当然，这些好处的代价，就是层层递进的沟通成本，以及对个人能力的限制。但不管怎么说，存在即合理，当大家都这么做时，必定是利大于弊。
我第一次听到“全链路设计”这个词是在今年初的年会上。不过，在提出具体名词之前，工作内容上其实已经有所体现。
一年前，我的工作内容集中在某一块具体的产品线上。比如搜索业务，日常工作主要是处理各个业务方的需求：手机行业运营说我们要在搜索里透个参数，帮助用户对比；用研同学说要在搜索里发放问卷，搜集用户反馈；客户端产品经理说要做更多导购内容……总而言之，横向产品设计师的工作更多是“实现需求”，进一步还可以制定产品线规范（帮助需求更好地融合）等等。
这样做的问题是什么？是我对上下游业务背景及后续反馈都非常不了解。食品行业说要发放优惠券，那这么做的原因是什么？基于什么样的市场背景？有没有更深层次的竞争或商业目标？
这些信息在做需求的过程中层层过滤，到设计师手上的时候已经具像化为一个最直观的需求——做一个组件、一个功能、写几个字。
即便是针对某个具体行业的设计师，他也许清楚地知道上游发生了什么，但同样很难搞清楚呈现时的种种困难和障碍究竟来自哪里。因为他对横向产品和下游流程没办法都了解到。
这就是与“全链路设计”相对的“单链路设计”存在的问题。
所以所谓“全链路”，“全”并非是指事事亲为，什么事情都要参与，而是从自己所在的立场上，向周围各跨一步的工作方式。
就像“全栈”往往指的是技能上的集合，常说的开发、设计、产品、运营一手抓。“全链路”则更侧重于业务层面，不只了解自己负责的，更要了解前因后果。
“全链路设计”有怎样的需要，会带来怎样的好处呢？我说说自己的理解。
先说说对个人的要求。
更宏观的专业视野
工作之后，很多人的焦虑都来源于“精耕细作”。尤其在大公司，盯着眼前的一亩三分地，很容易让人忽视整个行业正在发生的变化，让人的视野变得越来越小。“全链路设计”对个人最大的要求，就是更广阔的视野。
以我自己“交互设计师”为例，平时也经常被朋友问到，究竟什么样的工作属于“交互设计”范畴？
除了最基本的放按钮、摆组件，写文案算不算？文字的颜色算不算？需求背后的商业目标制定能否参与？运营计划听不听？技术方案讨论？
答案很简单，只要是为了能够把产品做的更好的，都算。
在团队，设计师更像是粘合剂，能够把苍白的文字、数字变成直观的设计稿，能够连接各个不同的岗位。这也要求你对产品的前因后果都有所了解。
甚至，有经验、有想法的设计师可以和运营、产品深度合作，一起去制定商业计划和产品需求。更有厉害的设计师直接产出整套的产品方案和运营计划，推动运营和产品经理去落地执行。
互联网行业发展太快，技能和专业随时都会被刷新。能够沉淀下来的，是一些通用的处事方法，以及相对稳定的行业、商业本身。（比如过十年也许大家都不玩手机了，但是衣服鞋子制造生产本身不容易有太颠覆的变化）。
对复杂信息、领域的整合能力
设计稿画的好不好，规范用的溜不溜，早已经不是对资深交互设计师的要求了。设计师之间的竞争更多发生在对信息和资源的整合上。如果你一味只会画需求界面，能带来的价值可能会非常有限。（当然基本功还是要练好的）
拥有了更宏观的视野和工作范围后，你所接触的信息也会呈指数增长。
以前做规范的时候，写的都是这个某某组件尺寸如何，点击后会有什么效果，最多写多少个字之类的“容器规范”。而现在，开始从业务的角度去指定产品规范：哪些组件的功能是为了提升转化率？建议运营填写什么样的内容？导购文案有什么要求等等。
以前做设计，更像是搭台子，反正容器做好，里面放什么交给运营和产品，我不管也管不着。而现在，我会花费更多的时间和他们去沟通“内容”。容器，反而没有这么重要了。
除了整合，还需要学会借力。
了解整个链路的“玩法”后，必须要清楚地知道每个环节大家想要的是什么。行业运营想要的可能是最直观的成交额，产品经理想要的可能是转化率和横向需求整合效果，工程师则追求做事的效率和组件化程度。
其实这些诉求看起来是某个岗位特有的 KPI，但对用户、对产品本身来说，每一个都是不可或缺的。为了提高转化率，如何从运营选品上作出选择？如何向用户描述贵的商品好在哪儿？所使用的组件能否帮助开发提高效率？这都是需要考虑的。同一件事，对不同人用不同的说辞，最终达到一个整体性的目标，就是所谓“资源整合”和“借力”。
再说说对团队和产品的好处。
场景与场景的联结更佳紧密
去年一年我都在做纯前台客户端的表达，也就是用户使用产品时看到的那些界面。但事实上，对电商体系而言，一件商品到用户手上，经过的流程中有80%以上都是用户不可见的。所以只做前台表达，其实只参与了商业中的一小部分。背后那些仓储、物流、供应链都是你所看不到的。
所以从今年开始，我也开始接触一些后台的需求。同一个项目，肯定既有前台表达又有后台能力支持，那设计师就应该通盘了解，通盘设计。甚至有些需求牵扯到多类用户的，那你也要同时考虑消费者、商家、供应商等多个角色的体验，达到平衡。
除了前后台，还有不同前台的产品线。同一个大促活动，从首页到搜索，从搜索到商品详情页，再到购物车、下单，如果每个环节都是不同的设计师在设计，该如何保障一致性、连贯的用户体验？
因此“全链路设计”可以很好地把孤立的场景串联起来，让“动线”真正流转起来。
更低的沟通成本
说白了，就是更