对于那些深切关注设计系统的人来说，最难的事情之一就是为一个专门的设计系统进行辩护。领导层的人员经常会要求你证明它的价值。为什么我们要关心良好的前端开发和一致性？当然，当然，当然，他们说——每个人都想要一个炫目的设计系统——但它是否值得付出代价？
这个问题很难回答，因为开发人员的生产力、前端质量，甚至在一定程度上来说的可访问性，都是非常模糊的概念。相比之下，这是 Google 的 核心网络指标 最聪明的地方之一，因为它为问题设定了数字，并提供了一些非常切实可行的方法来解决它。
在设计系统方面，我们并没有真正可以指向并说“啊，是的，我需要把人们放到设计系统团队，这样我们就可以把设计系统从 60/100 的糟糕分数提高”的指标。如果我们有的话就好了，但我认为我们永远不会有。
Sparkbox 登场了。他们想通过测试他们的 8 名开发人员在一个小型测试中的速度来解决这个问题。他们让他们的开发人员手动创建一个表单，然后使用 IBM 的 Carbon 设计系统（他们以前从未使用过）再次创建表单。
使用设计系统使简单的表单页面的开发速度提高了 47%，而从头开始编码则慢了。从头开始提交的表单的中位时间是 4.2 小时，而使用 Carbon 提交的表单的中位时间是 2 小时。Carbon 的计时包括开发人员花在熟悉设计系统上的时间。
现在想象一下，如果这些开发人员已经熟悉 Carbon 的设计系统！如果那样的话，我认为创建这些表单的时间会比最初的结果快得多，快得多。
研究方法似乎有点不对劲。所有 8 名开发人员首先从头开始编码表单，然后用 Carbon 再次编码。这意味着任何花在理解表单设计上的时间都算在了从头开始的测试中，而不是 Carbon 测试中。
对上一条评论的回复。方法很好。它仍然使设计系统更快。如果你去掉他们花在学习 Carbon 系统上的时间，现在还不到 2 小时了！
在过去的七年左右的时间里，我一直在这几家公司开发这些系统。为了让它们发挥作用，开发人员和设计人员必须完全接受这种方法，并熟悉这个过程。
如果设计团队习惯于引入特殊情况，或者开发人员还没有采用组件，那么第一次迭代将会非常艰难且成本高昂。
看起来 Sparkbox 从一开始就拥有很多知识渊博的人，这很幸运。对于大多数组织来说，我建议让设计团队起草一个设计系统并以 PDF（非常低技术）的形式交付，让开发人员在一个小型项目中手动遵循它，这样每个人都能够理解保持设计一致性的微妙之处。然后逐渐过渡到“活生生”的版本。