序言
2015到2016年，我和我们团队从SGDD(Style Guide Driven Development)的产品交付模式中受益良多，而2015年参与的一个DDD试验项目也让我考虑把DDD和SGDD结合来系统解决泛客户端产品设计交付的问题。经过若干次迭代，2017年，一套DSDD(Design System Driven Delivery/设计系统驱动交付)方法逐渐浮现眼前。
从2016开始，发展DSDD的过程就像一场实验，期间产生了不少实验记录和心得，现在我来把她们编排出来给大家徐徐展开。
致谢
整个过程中我参考和阅读了不少国内外相关的案例和文献，特别感谢twitter和slack上的design systems小组。北美互联网大厂，独角兽，澳洲政府等各种背景下的design system实践让各自相互间更具信心，也启发了我把design system实践进一步推向“驱动交付”的极致。
在当下这波数字化转型的浪潮中，越来越多的组织应用各种创新方法来快速验证想法。而其中大量的尝试都是以数字化产品为载体，无论是mobile native app，mobile web app，微信小程序，甚至desktop web app，这些泛客户端应用的发布正在变得更加频繁，同时每个组织发布的应用数量也越来越多。那么如何能在保证质量的同时，快速启动一个新产品。就对软件产品的设计交付这一环节提出了挑战。(文中对设计交付的定义是从UX设计师开始解决一个设计问题到开发完成最终交付到用户手上的过程)
过去几年我或观察或亲历了许多泛客户端应用的设计交付过程。我们一起来看看身在其中的参与者们都经历了什么。
产品交付团队视角
我们跟随一位UX在交付项目中的旅程来看看。
启动一个新产品
刚刚启动一个项目的时候UX会特别忙，虽然明白制定一套设计规范不仅有助于保证设计的一致性，还能提高UX和Dev的工作效率，但迫于交付压力，一直也没能有时间来制定设计规范。Dev也只能先“临摹”UX给的设计图，在讨论设计的时候也不得不反复陷入“几个pixel”这样的细节。
几个迭代后
设计不一致的地方越来越多，界面上出现了许许多多看似相同，实则尺寸大小有几pixel差异的按钮。Dev说是严格按照UX的图上调的，UX说那么多页面，怎么可能每个都那么准，Dev应该自己多想多问。Dev和UX开始把各种设计细节写在story里，比如某个组件的尺寸等等，BA发现写卡的时间越来越久，QA发现太多的设计细节无法一一测试和回归。
调整了视口宽度之后，看到随着宽度变大，原先居中的button不居中了，页面上的图片也跟着变宽而不是保持尺寸居中，UX说这完全和自己所想不同。Dev说我们现在根据拿到的iphone6的原型图来实现界面，如果咱们设计上要描述响应方式的话，比如这里可以写20%而不是75px就好了，要不我们一起定个规则吧。UX说这个你们简单自适应一下就好了，你看其他App，人家做的多好，你就参考着做吧，现在也实在没时间考虑不同尺寸的设计。
终于要离开这个项目了
UX想着真的只是留下一系列页面原型图就够了么，我的设计不会被破坏了吧。于是在和新UX交接的时候交待了一些存在脑子里的设计规范，顺便表达了一些这个项目上的遗憾，比如对设计还原度始终不满意。最后临行前不忘嘱咐新UX在和这些Dev沟通的时候需要重点标注xxx，要盯紧yyy之类的就离开项目了。
接手一个进行中的项目
交接的时候UX接到一系列页面原型图，从原先的UX和Dev口中了解设计规范，了解标注方式。坐下来面对着几十页原型图，对着别人的设计，自己改还是不改呢。改又担心不明白当初的设计逻辑怕是给改坏了。
产品交付服务公司视角
这类乙方公司随着业务量快速增长，迎来越来越多的短周期项目，原先面向长期软件开发项目的响应力难以满足甲方公司频繁快速创新的需求。直观一点表达就是从UX设计师开始解决一个设计问题到最终以产品形式交付到终端用户手上大多也是两周时间，这还是在团队具备了持续集成和持续部署能力的情况下，而一个快速创新的项目常常也就是一个月甚至更短的周期。那他们都遇到了什么问题呢？
新项目总是从零开始，没有积累，重复劳动成本高。 在泛客户端组件化开发盛行的这些年里，经常听到组件能否跨项目复用的讨论，但往往卡在技术栈，视觉风格，就没有下文了。难道真的只能从零开始？
难以提供稳定一致的质量服务，依赖个人发挥。 现在项目更多且短了，难以保证每个项目都有资深同事能照顾到，而新人(尤其是UX设计师一般团队只有一位)才独自熬过高压的项目前期，就要立马奔赴下一个项目。
两个问题指向同一个方向，缺乏统一的设计交付标准化过程和基础设施。
产品负责人视角
这里的产品负责人更多指的是一个产品线的负责人。
新产品启动响应慢。 启动一个新产品往往要在几周后才有第一版可工作软件去获取反馈，这个时间是否可以提前，比如项目开始一周以内？
产品难以持续演进。 交付团队只交付了产品，却没有留下支持产品背后的那个“产品”(design system 或者 living style guide)。一旦交付团队换人，产品往往只好艰难地基于设计师留下的一张张静态原型图来继续演进。这就好比你一栋楼盖了一半，接下来你要接着往下盖，所能凭仗的就是之前施工团队留下的，呃对，只有建筑效果图。虽然那些水彩看起来蛮漂亮，但是她无法给你还原设计上的细节和背后的决定逻辑。然而缺乏系统化的设计方法和工具的支持，即使是同一个设计师也难以快速对产品进行调整而不破坏之前的设计。
迈向平台化，但难以统一多个产品的设计。 单个产品的演进都难以进行，想要统一多个产品的设计就更加没有统一的实施基础了。
总结
不论从如今数字化产品需要在多平台上部署用户触点的技术层面，还是一家企业多款产品甚至打造平台生态的战略层面，都对设计交付在快速响应，一致体验，可持续演进上提出了更高的要求。而现实中大量的敏捷设计交付实践里把UX看作黑盒，把UX设计师和设计交付物看作艺术家和艺术品，回避其中的系统性和结构化，接下来我们需要把UX这个黑盒打开，全局优化，让UX的工作过程更系统化，更紧密地结合到交付过程中来，而不只是在UX或者泛客户端开发上做局部优化。在这方面我目前的答案是，设计系统驱动交付。且听下回分解。
