实践Design System Driven Delivery，真的考虑UX和Dev 就够了么?

于2017年@北京

一通电话

一切看起来还算平常，直到story也拆完了，工作量也评估完了，UX指着自己做的component library对Dev说，这是我们的Design System，你 们估计需要做多久?接着就泛起一些犹疑的声音:我们需要做成这样么?这个项目时间特别紧张。这可得花不少时间啊。UX暗自叫苦，看来推 行DSDD果然不易啊。
之后，我就接到这通电话，电话那头的UX跟我说明了上面这个情况和一些看法。我听下来基本总结为两点:一. Dev们不明白DSDD也不知道该如何行动。二. 项目进度本就紧张，原本要实践DSDD的事情现在排在很低的优先级。
我们是不是觉得这个问题有点熟悉，如果我们把DSDD换成其他的一些实践，比如TDD，比如CD，好像也蛮合适的嘛。这和给团队导入敏捷 实践没什么两样，况且DSDD还不像其他敏捷实践一般成熟，有关于她的方法论，包括这个实践的成本收益，适用场景甚至怎么操作都只有不 多的参考。

几个问题

首先，虽然起初UX和Dev达成共识要实践DSDD，但是相关的工作并没有被充分考虑并体现在story及其工作量评估上。 其次，建立重点没有落实，团队成员对这样一个新实践具体要做什么并不充分明白，除了UX和Dev还包括BA要怎么拆卡，QA要怎么验收，团
队从客户成果交付的角度怎么能更好持续给客户提供并展现DSDD的价值。 几点建议

独立，才难以被忽视

尽管也有人把Design System的工作分配在原来的story里，但我建议把Design System的工作独立拆卡来做，尤其是在不熟悉DSDD的团队。 原因有三。
Design System实际是在团队内部建立起一套统一语言，一个独立的story能够给团队同步一个更明显的信号关于这套语言的更新，当然更能 防止大家估算工作量的时候忘了它。
独立出来的story也能更能凸显原本埋没在其他story里的Design System里的细节比如颜色，尺寸，信息架构等等。
把Design System的工作独立出来，配合Living Design Deliverable的工作方法，能够极大加快我们获得一个可工作原型的速度。举个例子，我们曾用一天时间就交付给客户一个计划两周完成的软件的原型。

赢得客户的支持

即便是小范围的组织变革，我们也不得不认识到，这是一笔生意，你要改进你的生产方式，起初可能会需要一些投资，尽快让你的客户认可 DSDD的价值并赢得支持获得更多投入，也是持续改进的基础之一。
比如，可以在定义完Design System之后，甚至用贴图的方式快速交付可交互原型，之后再逐步把图片替换成代码实现。很多人会觉得这不 可思议，但你知道上面的那个一天的例子就是这么实现的，客户甚至以为我们几乎完成了全部。这么做一开始会花一些时间但不会很多，可 这却给客户换来了更多人基于可工作原型的反馈和讨论，尤其在探索性的项目凸显价值。相比类似Flinto这样的原型工具，以Design System+Living Design Deliverable方法交付的原型还能连接真实API，跑在真实的设备上，提供更真实的体验的同时更支持持续演进。泛客 户端上真正的持续交付终于可以从一开始就进行了。这些都可能是你赢得客户支持的筹码。尽管你了解了我的说辞，但你依然要尽快交付其 中一部分价值并演示给客户。

明确团队成员的工作

首先要明白DSDD要在团队建立统一语言，就一定会涉及所有成员。你可能需要提供像菜谱一样的指南，告诉并教会他们如何在DSDD的方 式上工作。当然这是另外一个大话题，我会另外专门撰文说明这点。但是这肯定不只涉及UX和Dev，你需要从每个实践及其价值重新考虑 DSDD对团队工作带来的改变。

Takeaways

如果你要在团队里推动DSDD实践:

• 把Design System的工作独立出来。
• 一定不要忘了考虑她给整个团队带来的工作上的变化。
• 赢得客户的支持，让他们看到价值以投入更多在初期显得尤为重要。