本篇文章主要想和大家探讨：什么是设计交付?设计交付从哪来到哪去?究竟解决什么问题、价值何在?大厂或者说那些代表业内最先进生产力的团队，他们是怎么理解、以及怎么做设计交付的?
(相关资料图)
另外，还有一些 MasterGo 产品团队关于行业发展趋势的洞察和思考分享，以及一点点供刚入行同学们参考的小建议，希望能为大家带来些许助益。
什么是设计交付?
提到交付二字，我们普遍会想到向客户交付，例如交付一个产品、交付一组订单等等。这个动作的完整结构，包含了“交付的主体”、“交付的客体”、“交付的方式”、以及“交付物”，四个关键要素。
完整的表达句式
谁向谁，通过什么方式，交付什么。
举个例子：韩梅梅向李明明，通过在线文档的方式，交付了关于《设计交付工具竞品调研》的报告。
再比如，Nate 向 Jane，通过物流方式，交付了上周的苹果订单。
相信很多刚入行的小伙伴，在团队中会听到研发小哥问：“某某需求的设计稿什么时候交付?再不交这个迭代排不进来了啊。”或者听到自己 Leader 问团队里其他小伙伴：“这周会有哪些需求进入到交付环节?大家赶一赶，没评审的尽快约评审”之类的对话。
那么，当我们在谈论设计交付时，我们究竟在谈论什么?套用上面提到的句式：“谁向谁，通过什么方式，交付什么”。我们来填空，看看在产品、设计、研发协作领域，设计交付到底意味着什么。
交付主体是谁?
就是我们设计团队的设计师们。尤其是占大头的用户界面设计师们，可以说是这个行业里绝对的“交付”主力。
交付客体是谁?
当然是我们协作的下游，可爱的研发工程师们。他们会拿着我们的设计稿，将一个个按钮、页面变成网页、APP、小程序、运营管理后台等等。
交付方式是什么?
这里就有意思了，也是后面会展开的重点部分。整个行业经历过几个不同的发展阶段，每个阶段受到技术的限制、工作习惯、分工和协作关系等因素，都有它特定的交付方式。
交付物是什么?
是我们产出的设计稿。而且既然是交付，就说明设计环节的活儿已经完成，该移交至下一个环节的小伙伴。这就意味着，我们产出的设计稿已经通过了设计团队、产品团队、以及需求方的检验，该做的修改和调整都已经完成了。
填好这四个空之后，大家对“设计交付”有没有一个相对清晰的理解呢?我猜很多同学会想，然后呢?这不就是把设计稿给到研发同学就好了嘛，好像没什么复杂，也没什么学问在里面啊。接下来，我们带着这个疑问，来一起了解下为什么我们需要做设计交付，设计交付经历了哪些发展阶段，又是在哪些因素的驱动下不断发展变革的。
设计交付的前世今生
时间线 2000 - 2010 年
互联网在国内开始兴起。新浪、网易、搜狐三大门户网站占领了第一代网民的心智，这个十年加入互联网的一代，基本算是国内的第一批从业者了。
那时候，产品经理这个岗位刚刚兴起。
他们输出了很多对行业发展、对技术趋势、以及对海外新思想的思考和洞察，让所有人都认为产品经理是那个最关键的角色，团队里每个人都听 ta 们的，他们告诉大家做什么、怎么做，他们人数不多，有时候一个业务团队里就一个独苗，甚至大部分团队还招不到产品经理。
他们用 Google Docs, Evernote, Visio, Axure, Keynote，还有闪亮的初代 Macbook Air 和 iPhone 3Gs，他们不用 Word 和 PPT，更不会用 Excel，对，就是不用。
他们中的一些人，还会用 Photoshop，甚至会 Illustrator 和 Coreldraw。那时很少有人会挑战 ta 们：“我们为什么要做这个?”以及“我们为什么要这么做，而不是那样做?”
那时候，设计师还不叫设计师，大多被称为美工。
他们有些来自传统印刷和纸媒行业，他们用 Photoshop 和 Illustrator 很溜，操作速度快得飞起，还会写脚本批量修图。他们中的一些人，很早地嗅到了产品经理这个岗位的发展利好，积极转行，更多人则朝着界面设计的专业方向，越走越深、越走越远。还有那么一小撮人，他们极力地想要实现自己的设计，他们用 Dreamweaver 直接构建自己的理想，成为站长。
那个时候，还有一个神奇的领域，叫做 GUI (Graphic User Interface)
这个名字远远没有体现出他们的厉害之处，他们把 Photoshop 画板放大到很大很大，大到一个像素大约有指甲盖那么大，然后一个像素一个像素的在屏幕上点击鼠标，当缩小画面后，一个边缘平滑、过渡自然的图标跃然而生!
这个时期，不管是会比划 Photoshop 的产品经理，还是精通 Illustrator 的美工，在前端工程师眼里，都是美工，见到他们的第一句话都是：“图出来没?图切好没有?”
在他们的工具技能树上，有一款奇迹一样的产品，叫做点 9 切图工具，它能帮助我们实现自动拉伸、压缩按钮尺寸而不会失真!
这个时期，他们交付给研发团队的，往往是一个 .zip 或者 .rar 压缩包，里面包括了一片片能够拼凑出完整页面的拼图碎片，以及一张张标记满满尺寸信息的界面。不论你的设计多么精妙绝伦，多么美得不可方物，最终都得附着密密麻麻的红色线条和数字，变成一个个碎片而无法完整展示给前端工程师。
时间线 2010 - 2020 年
移动互联网从起飞到平稳的十年。这十年里变化太多、也太快，快到回过头看，会发现我们一起经历过那么多精彩和美好。
从阿里、百度、腾讯的三分天下，到京东、美团、滴滴的快速崛起，再到后来字节、快手、拼多多...，大家一边感叹创业再无机会，一边新的独角兽继续层出不穷。这个时期，产品经理、UI 设计师、前端工程师的队伍在快速扩大。
大多数产品经理一边学习着如何操作 ProcessOn
一边向身边的人推荐 Notion;一边吐槽着 Axure 和 Visio 多么难用，一边远离着 Office 三件套。他们中的绝大多数人不再需要使用、更不会安装 Photoshop，因为连设计师们也不再使用。
相当一部分设计师开始使用 Sketch
这对他们来说是划时代的产品，因为，他们第一次用上了专门为他们设计的设计工具，这不仅带来效率提升，更代表着在团队内影响力的极大提升。
Sketch 的图层样式、文字和颜色变量还有 Sketch Library 令他们两眼放光，组件思维、原子思维迅速蔓延，设计规范的建设成为各个用户体验团队的军备竞赛，谁也不愿意再做那个不停重复造轮子的傻子。就连一些产品经理也拜倒在 Sketch 的钻石光芒之下。然而，他们交付给团队的，仍旧是一个 .zip 或者 .rar 压缩包。
在这个十年的最后 2-3 年里，还出现了一款叫做“蓝湖”的产品
它的神奇之处在于，你只需要在 Sketch 里安装一个插件，就可以一键把设计图传到云上。这样一个链接丢过去，不论研发小哥是在公司电脑前敲代码，还是在个人电脑前 LOL，甚或是在马桶上握着手机，你的设计稿都绝不允许被他们忽视。不只如此，他们可以动动手指，就查看到详尽的标注，再动动手指，所有切图直接下载到自己电脑上。更贴心的是，它还能兼容那些仍然坚守在 Photoshop 上的小伙伴。
这种交付方案的变革，为广大设计师带来福音，他们原本需要花费和设计一样长的时间，去标注、去切图，现在，有了蓝湖这样的产品，他们的头发再也不需要做无谓的牺牲了!
2020 年开始
注定是改写这个产业的最关键的十年。
伴随着各行各业数字化进程的进一步推广和加速，数字交互界面也成为一个明确的、潜力巨大的产业。未来，人们将越来越多的通过一个个或大或小的界面，来获得信息、服务、甚至人生中的绝大部分“真切”体验。这个十年的开始，正如 Figma 在国外对 Sketch 的全面“清剿”，国内也涌现出一批新一代的在线协同设计平台。
这一代产品不但继承了、并且进一步发扬光大了组件化设计的思想，还把布局能力、设计规范助推到设计系统这一新的高度，甚至和代码化的组件打通。
设计不再是纯视觉的游戏，不再是需要代码“转译”的非结构化信息，而是能够指导样式代码编写的、所见即所得的产品定义过程。
并且，不只是设计师，在新一代协同设计平台上，产品、研发，甚至运营、市场团队，都有机会在项目早期就加入到产品创作的过程中。整个业务团队围绕共同的目标、基于可见的产品原型，共同描绘着未来，定义着一个个数字交互界面产品，一起为一个个用户、一个个客户创造价值。
交付，不再是你干完活儿后，交给我继续干，而是我和你，我们一起一边探讨、一边创造，当我们定义好产品时，相应的代码也一并生成，标注、切图、走查将不复存在。
我们有机会实现普适的低代码和无代码解决方案，通过标准化、工程化的组件来构建应用，甚至实现一键部署、发布给自己的用户。数字交互界面的生产力得到极大释放，更多的界面产品得以面世。这时，交付不再是设计师交付给工程师，而是由创造者直接交付给用户!
当然，趋势归趋势，畅想归畅想。回到当下，设计到研发的交付场景仍是产设研协同链条上最关键的一环，让我们一起看看走在效能实践前沿的“大厂”都是怎么做的。
大厂是怎么做设计交付的?
我们说大厂，不是单单看规模，看企业人数，而是那些代表了产业内最高水平的企业，这些企业面临激烈的市场竞争，需要持续不断地提升自身的效能、加速迭代自己的产品和服务，才能够持续引领产业发展并保持自身的领先地位。
同时，随着数字化进程的加速，各行各业都需要一支“互联网式”的研发团队，因为在向客户交付产品和服务以及持续和客户的互动过程中，越来越离不开数字交互界面，例如小程序、APP、网站、车载大屏等等。
在设计团队、研发团队各自解决了自身内部规范和效率问题之后，大家发现，从界面设计到界面开发这个环节，长期受到工具障碍和语言障碍的影响，效率问题越来越突出：
1. 定义产品需求的工具不统一：产品、设计、研发各有各的偏好
2. 信息的载体不统一：包含文档、脑图、流程图、视觉稿等等……
3. 理解需求、认知产品的视角不统一：产品关注需求有没有被解决、价值有没有实现，设计关注用户实际使用时的综合体验，研发关注技术栈、实现成本、性能还有可维护性
大厂如何解决这些问题呢?他们做了非常多实践，包括各种工具和流程体系建设，大体上可以分为三个阶段：
早期
基于 .psd .sketch .html 文件，搭建本地服务器来集中存储和访问，通过 SVN 管理文件版本
成熟期
使用三方(蓝湖、Zeplin)或自建设计交付平台(例如阿里的 D-One、美团的印迹、滴滴的魔方等等)
突破期
使用在线协同设计平台(MasterGo、Figma)替代 Sketch + Axure + 设计交付平台的工具架构，实现产品定义、评审、交付研发的一体化
这里重点介绍下后面两个阶段：成熟期和突破期。
成熟期
搭建本地服务器的方式一方面存在一定的实施门槛。它不难，但是对绝大多数设计团队而言，还是要请研发小哥帮个忙。另一方面，虽然它为非设计人群省去安装 Sketch 的麻烦，让团队可以直接访问服务器查看设计稿，而不用费力地找一台 Mac 电脑下载安装包。
这里很多人会抱怨下 Sketch，它成就了一代 UI 设计师，也因不能跨端、文件不便于访问的问题，造就了一批交付平台，最终也让自己被市场淘汰。这种交付方式最大的弊端就是不适合迭代、不适合敏捷开发。过程中改动那么多，每次改动都要反复上传反复通知大家一定要看最新版本，而随着团队人数增多，业务范围扩大，这种方式最终演变为混乱的灾难。
Sketch 大抵也是非常清楚大家的痛点，便开放了相关数据结构和接口，于是有人提出专门做一个交付物的管理平台，例如 Sketch Measure。这样 Sketch 文件上传后把必要的数据解析并绘制出来，然后不仅可以查看标注、获得切图，还能提供评论功能。对于设计团队上传方便了、评审方便了，对于研发团队而言更是极大地改进了他们的体验。于是交付平台几乎在 3 年内便渗透到每一个设计和产研团队，极大提升了产设研团队的协同效率。这其中有海外的 Zeplin，也有国内的蓝湖，还诞生了多个大厂自建的内部交付平台。
关于大厂自建交付平台，不得不提到中台化这个概念，在那一波降本增效的大背景下，减少重复造轮子，是人人都会挂在嘴上的信条，大厂内众多中台团队应运而生，这其中也不乏设计中台团队，而内部交付平台，大都是由设计中台团队承建和维护。
突破期
交付平台帮助团队解决了很大的问题，集中交付、可视化、版本管理、在线评论、自助查看标注和获得切图、甚至完成走查...但是，它没能解决一个更本源的问题：数字交互界面的设计标准和生产标准是什么?它解决了表面问题，而一旦本质问题得到解决，上层场景可能就不复存在。
Figma 的出现让大家看到了这个本质问题，并逐渐形成了一个认知：我们如何生产决定了我们如何定义。或者说，设计创意不能脱离技术实现它的方式。在标准得到充分对齐的情况下，整个制程、工艺中组件化程度会大幅提高，生产效率将得到大幅提升。而在整个生产链条中，设计工具起到至关重要的作用，它不仅是创意和工艺的体现，更是行业标准的集中体现。
一线大厂早在 19 年前后就关注到下一代协同型的产品设计工具，但对于是否切换以及什么时候切换分成了两类：
1. 我们有自己的交付平台，并且功能在持续完善，我们有充足的中台资源来支持集中交付和流程管理平台的开发和落地，新工具尚不成熟，Sketch 仍是最佳选择，对新工具保持关注
2. 我们正在决策是采购三方交付平台，还是自行开发，我们有预算、有资源，新工具出现的正是时候，省去了交付平台的麻烦，直接用。
我们来看看像 MasterGo、Figma 这一代产品，是如何解决交付问题的，为什么在这么高沉没成本的情况下，大厂们还是坚决要推进工具换代。
100% 基于 Web 并且能够多人实时协作
使得团队无需再依赖任何三方、二方交付平台。因为任何人使用任何设备都可以直接访问甚至编辑同一份数据，这使得团队中的非设计角色有机会更前置地了解、甚至参与产品定义的过程，而不是等到方案评审时来个大 battle。
完全基于在线数据
省去反复传递数据的同时，更避免了大量因为数据不同步、不一致带来的沟通和协作成本。
组件和实例、网格和自动布局
这些已经在代码侧得到充分迭代和验证并沉淀下来的生产方式，直接体现了我们对于数字交互界面这一类产品的认知范式，正加速成为所有产品设计师理解和构建数字交互界面的共识的方法。如果代码实现不了，就先不要被设计出来，反之，如果一定要设计出来，就需要找到代码实现它的方式。
理论上无需走查
因为结构一致了、标准一致了，新一代设计工具更接近成熟产业中的 CAD，输出的产品定义将 1:1 直接指导产品生产过程，从而保障设计意图的“精准还原”，所以，理论上走查场景会不复存在。
综上，大家不难看出，新一代工具的优势是巨大的，它的用户和使用场景不局限在设计师个人，而是一整个设计团队，甚至整个产设研团队;同时它划时代地将生产数字交互界面的内在原则，逐渐清晰且一致地呈现给所有人。
可能有人会问，我们之前那么多历史数据，还有那么多团队、那么多人的使用习惯怎么办?
首先，这波工具换代潮不是简单的习惯变更、功能变更，而是更先进的生产力和生产关系的变更，不换，必然落后于人;其次，千万别让历史数据阻止自己革新、前进的脚步，在数字交互界面产品的生产逻辑里，可复用的才是有价值的，只要完成样式规范和组件库的迁移，就可以在新的平台上快速跑起来，其他历史数据根据未来迭代的实际情况，按需迁移即可。
这里给大家一个参考，帮助大家更好地评估规范迁移的工作量：
某团队前后投入 3 人、断断续续历时 2 周便将一个之前在 Sketch 上持续维护的、包含了 1000+ 组件的团队库迁移到了 MasterGo，并且还为组件引入了包括自动布局、组件状态在内的新特性，极大提高了组件库的易用性和可维护性。
“去设计交付”下的新挑战
可能还有很多人认为，交付场景不会消失，至少不会这么快消失，因为工作流程不还是产品出需求，设计师接需求出设计，然后开发照着设计做吗?
如果这个工作流不改变，交付场景就始终会在。没错，前提是工作流不改变，你是对的。但我们在前面说过，这次工具换代会是产业进入成熟期的重要标志之一，对推动产业变革起到了关键的催化作用。
产业变革的进程会体现在：
1. 基于新一代工具，协作的可能性和价值得到充分释放
设计团队更开放地和上下游联动，更主动地吸纳意见、同时输出设计思维的价值，于是传统的瀑布式的大流程必然得到优化。项目中更多的专家角色有机会在更早期参与到目标和策略的讨论与制定、以及产品方案的设计，从而前置地、更有效地影响产品或项目的走向、进而确保最终价值的实现。这就对设计师群体在项目中的沟通和协调能力提出更高要求，他们不仅是呈现方案的人，更是促进更优方案产生的促进者。
2. 仅仅做流程优化已经不能很好地释放产品设计价值
能力模型、岗位设置、甚至组织架构需要相应调整和优化。
UI、UE、动效、3D 设计师 vs 全栈设计师、设计系统架构师、组件设计师、Design Thinking、DesignOps...
3. 持续地寻找适合自己的过渡方案
没有明确的交付节点，“设计定稿”这件事本来就是难点，在加速迭代中也变得越来越不现实，而新一代协同型的工具在适应期内可能会加剧这个问题带给大家的负面感受，而这种感受恰恰反映了瀑布模式下的思维惯性和动作惯性。
在这个迁移、适应的过程中，不论是通过规范项目、文件、页面结构推动设计系统落地，规范流程，还是在一段时间内继续搭配交付平台来使用，这需要 Team Leader 或促进者带领团队持续地寻找适合自己的过渡方案。
4. 将早期、不成熟的思路毫无保留地暴露出来，而不是憋大招
这一点在我们的调研中，发现对很多人不论是设计师还是产品经理都存在很大挑战，大家普遍倾向于把自己认为 ok 的内容再呈现出去，怕露怯、怕被挑战。但这实际是很多职场人真正步入职业化的重要一步，重点不是我们自己在过程中露不露怯，而是在过程中积极主动地吸收不同视角的意见和建议，广泛地听取意见、独立做决策、最终拿到好成果，职场同伴自然会认可你，你的影响力才会增加。
5. 产设研共同拥抱不确定性和极限迭代
在 CI/CD 理念的启发下，实践 CD/CD (Continuous Define / Continuous Develop)
写在最后
大厂其实没有光环，只是在过去 10 年间，更早地聚集了先进的思维、优秀的小伙伴，并且有相对充裕的社会资源和影响力去探索更好的生产和协作方式。
但随着业务的成熟、组织结构的庞杂，惯性越来越大，更难在接下来做出变革性的创新，大厂内部也在发生积极的“裂变”。下一个十年，随着新一代协同型产品定义和生产平台的加速渗透，更多、更好、更先进的方法、能力、资源被带入更多团队，我们相信，是千千万万中小团队产能爆发的十年，让我们一起创造，共同推动数字世界的用户体验和商业价值最大化!
