你好，我是炒炒。

还记得上节课的内容吗？我跟你分享了如何提高设计师工作效率，让设计流程更高效的几个关键点。那么，在今天的这一讲，我想跟你继续分享一下设计中台相关的话题。

不过，可能有的小伙伴就会问了，设计中台是什么呀？我好像听说过，但是设计中台真的那么厉害吗？

可以这样说，如果我们能够利用好设计中台，我们的工作效率就会大幅度地得到提高。作为设计师，我们就会有更多的自由时间，去思考创新，去优化我们的设计，不会被每个设计需求追着跑。

不过，很多人一说到设计中台，可能会想到很多类似的说法，比如设计规范、设计系统等。那么，设计中台和这些概念之间，有什么区别呢？对设计师来说，中台的作用又体现在哪里呢？

所以，今天，我们就来了解一下设计中台的知识。

什么是设计中台？

首先，我们来了解一下设计规范、设计中台以及设计体系之间的联系与差异。

为了让你更直观地感受这三个概念的差异，我还做了一张三个概念的关系图，如下图所示。但是，每个概念里面包含的资源是根据我们公司的实际情况列举的，供你参考。

通过上面这张图，你能看出，设计体系是包含设计中台的，而设计中台又包含设计规范，三者是一层一层包含的关系。你可能也是对设计规范和设计体系比较熟悉。那么，问题来了，设计中台的出现，会给设计师的工作带来哪些变化呢？

我用我之前的经验来回答一下。

我之前在做一个新项目的设计时，当时还没有设计中台。在想好产品的页面逻辑和需求细节后，往往需要先把一些设计控件的样式画出来，或者直接改造自己以前项目的设计控件。

可是，折腾完这些设计控件，整整一天就过去了，而页面却还没开始做。等到设计走查的时候，我还需要去挨个地复查每一个控件。这么一圈折腾下来，投入的时间成本非常高。

而现在，我们是在开源的设计中台，一键下载对应的设计资源库，里面包含了通用的设计控件。这样，我们直接就能开始页面的设计，省去了以前画设计控件的时间，快速响应了需求。

不光如此，在设计走查阶段，因为有一些组件开发也是用的设计中台里的控件库，所以，我们也不用再浪费时间去挨个地查看每个组件的还原度，极大地节省了走查的时间成本。

从我刚才说的这个例子里，我们可以发现，设计中台 有 两个关键能力：资源 调动 和共 享 共建。

从第一点，资源调动的角度来说，我们可以直接把资源拿来应用在不同的项目中。

比如说设计组件，设计师在设计页面时，可以直接使用这些设计组件。通过不同组件的组合，就能够快速形成页面。而开发也不用单独开发每个组件，他们只是通过一些封装组件的调用，就能组装成页面。

第二点，共享共建，你可以理解为能够被多个不同的项目复用，而且在各项目的支持下，持续迭代升级。

比如说，你整理了一套组件库，但是在样式上，由于个性化太强，这套组件库只适合于你当前的项目使用，没有办法把它用到其他的类似项目，那这个能够称为设计中台吗？

在我看来，这个是不能称为设计中台的，因为它不能被其他项目复用。

但是，如果我们把这套组件库改造一下，让它变得可以被其他项目复用。我们再结合其他项目的一些调用反馈，持续地进行迭代升级，那我们就可以称之为设计中台。

你发现了吗？设计中台的思维借鉴了统一的标准件逻辑思维，它就好比是抽象、归纳可复用的资源，聚焦在效率提升和用户体验的一致性上。

什么情况下需要做设计中台？

既然设计中台这么厉害，有这么大的好处，那是不是所有企业都可以搭建一个设计中台呀？

当然不是了，设计中台虽然是一种非常友好的工具，但不见得每一个企业都要做自己的设计中台。最大的原因就在于，搭建一套设计中台非常地耗费资源，还需要持续维护。盲目跟风地搭建设计中台只会成为你的负担，给你所在的企业也不一定带来很大的价值。

那么，在什么情况下，我们才需要做设计中台呢？

对于一些中小型的公司、或者项目比较单一的公司来讲，我不建议花费精力去做一个设计中台，去直接使用那些开源的设计平台才是一种性价比更高的方式。比如说 Ant Design、Element 等。

不过，要提醒一点，在利用开源的设计平台的同时，要记得建一套自己的设计规范。

但是，对于一些产品线多、项目复杂的大型企业来说，就可以搭建一套更适合自己企业的设计中台。就拿我现在的公司来说，我们所服务的项目都是基于企业金融服务这个大的业务场景，然后内部和外部的相关系统加起来有上百个，同时我们企业对于信息安全有非常严格的要求。

所以，基于这些情况，我的企业就比较适合做一个自己的设计中台。

一开始，我们其实也是没有设计中台的，只有一套自己的设计规范文件，那时候，这套规范就已经足够帮助我们完成一个产品的快速交付了。后来，同期对接的项目多了后，设计团队的小伙伴也多了，我们就需要做好不同项目或子公司之间类似功能的快速交付。

所以，我们就把设计规范进一步升级，定义出了集团统一的设计语言和组件库资源，这个子公司间通用的资源平台就是我们的设计中台；再后来，我们为了做好能力开放，要设定一个生态级的设计标准来指导产品设计，让更多的外部公司来对接我们的设计标准，在自己的产品里呈现。

所以，我们决定进一步升级设计中台，最终把设计中台升级为了设计体系。

你发现了吗？中台并不是一下子出来的，而是业务需求催生出来的。因此，我们不仅要考虑设计师工作的效率问题，还要关注当前的公司大环境，去决定是否要做设计中台。

怎样高效地搭建设计中台？

那如果要是选择了设计中台，我们怎样高效地搭建呢？在接下来的内容里，我会结合我之前项目的实际情况，从四个方面跟你分享一下，怎样逐步地搭建我们的设计中台。

第一，设定专职维护人员，避免兼职推进。

在我们一开始设计中台项目的时候，就吃过没有专职人员的亏。那时候，我们是从其他项目借调的设计师和前端工程师，兼职地推进设计中台，也就是在他们本职项目空闲的时候，才去推进设计中台的建设，断断续续的。用户反馈一点问题，就解决一点问题，根本没有走在用户的前面。

比如说，当时，我们中台第一版有一个表格控件。随着更多项目的接入，初始的设计方案已经不能满足更多的业务场景。后来，在一个业务场景中，我们需要支持用户对表格的第一列的宽度，进行自定义调节，但我们的初始方案并不支持这个场景。

而且前端工程师是兼职的，他自己本身的项目一直很忙，抽不出时间来优化表格控件。这也导致了对接的项目进度以及质量，多多少少受到了影响，被不少用户吐槽。

踩了这个坑后，我们就向领导申请了两名设计师和两名前端工程师来专职做设计中台的项目。这样，设计中台的进度就能保证按照正常项目的进度推进了。

第二，增加 设计资源类型 ，拓展场景覆盖。

对于常规的设计中台来讲，资源包含设计理念、设计控件、典型模块、典型页面等设计元素。

但其实并不局限于这样，有时在工作场景中，对系统进行可用性测试也是一件非常频繁的事情。所以，我们就决定结合工作场景，把可用性测试的流程、问题以及测试报告框架模版化，也放到我们的设计中台里面。

这样的话，就可以让各个不同项目的设计师能够根据自己的情况，更加方便和快速地调用我们的工具包，高效地完成一场可用性测试，并输出一份让所有人都理解的可用性测试报告。而且我们会把相关联的可用性测试报告，上传到设计中台的资源池，方便各协作方随时查看。

后来，我们还陆续上架了用户调研问卷模版、用户画像模版、设计走查模版等资源。

比如说，去年的下半年，在我们服务的项目中，有 5 个项目涉及到各自项目的线上问卷调研。在设置每个项目的调研问卷时，我们就直接调用了设计中台里的问卷模版，再结合每个项目的属性进行了问卷题目的微调，就快速生成了每个项目对应的调研问卷。

这种方式不仅省时省力，还在一定程度上规范和统一了每个设计师的步调和做事方式。

第三，结合需求共享共建，保持资源更新。

一个设计中台，只有被项目持续地使用，并且有更多的人加入进来，结合需求共享共建，这个设计中台才有价值。切记，不要为了中台而中台，只搭了一个空架子。

当初，我们在设计中台搭建完成后，就额外成立了一个虚拟客服小组，主要承担两个职能：

  1. 一是及时跟进各项目在接入设计中台时遇到的问题，反馈的更新建议等；
  2. 二是及时对外同步设计中台的功能更新，对接更多新接入的项目。

虚拟客服小组的存在，就让设计中台和各项目保持了紧密的联系。

再跟你分享一件小事。当时，在我们的已有资源中，日期的输入是用的选择器的方式。但在维护群中，我们就发现，有的项目组说我们提供的常规日期选择器和他们的场景不太匹配。

于是，我们就找到他们进一步沟通。沟通后才明白，原来他们是需要用户填写出生日期，而用户有很多 50 后和 60 后，每次选择年份的时候，都需要往上划很久，才能找到对应的年份。

针对这件事，对应的项目组马上就重新设计并封装了一个出生日期输出的组件，满足了用户利用数字键盘输入出生日期的需求。开发完成后，这个项目组也立马就把新增的这个组件，更新到了我们共同的设计中台上，成为了设计中台上的一项新增资源。

在工作中，我们还发现运营的素材其实也是可以被各个子公司复用的。所以，我们还搭建了基于运营的素材库以及快速生成运营图片的在线工具。这些都是我们设计中台共建思想的体现。

第四，充分利用量化数据，高效推进投入与产出。

还记得量化手段吧？在我们自己的设计中台上，我们就附加了一个数据统计模块。

我们想通过这个数据统计模块，更加直观地看到设计中台接入的系统和产品数、组件总数、接入的页面数、控件被调用的总次数、单个控件被使用的次数明细等详细数据。

有了这些全面的量化数据，我们就可以轻松应对工作中的两个问题：

第一个问题就是帮助我们客观、直接地评估设计中台给项目带来的价值。这些数据就直观地展示了有多少系统对接了设计中台、有多少页面使用的设计中台的控件、每个控件被使用的次数。

这样，我们就非常方便地看到设计中台在所有项目中产生的价值，同时，也是为了能够推动更多项目对接设计中台，让我们的这个设计中台为公司节省更多的资源投入。

第二个问题就是我们可以通过数据去指引设计资源的准确投入。也就是说，我们可以看到已上线控件的被调用次数和被调用的趋势，针对一些调用次数较多的控件，还可以加强重点关注和优化。

对于没有被调用的控件或者次数很少的控件，我们可以进一步追踪原因，是控件不符合场景还是有性能问题。这样，也是为了能够有针对性地进行优化，把资源投在更需要的地方。

这四条就是我在搭建设计中台项目中的几个小经验，希望能给你带来一些启发。

设计中台有什么附加价值？

在我们推进设计中台的过程中，经常会有协作方问我一个问题：你们这个设计中台是不是只对设计师的帮助比较大呀？它对业务或者项目是不是没啥太大的价值呢？

你是不是也会这么认为呢？我说一个我们项目中实际的例子。通过这个例子，你就可以非常直观地感受到设计中台给业务、技术和设计师三方带来的帮助。

这是一个签约审批的相关流程。大致的业务逻辑是这样的：企业签约任何一款产品的时候，都需要走一个审批流程才能正式生效。但这些产品分属多个业务部门，导致不同的产品审批的步骤、角色都有差异，但审批的逻辑是一致的，基本上就是退回、通过、终止、延后这四种处理逻辑。

在设计中台接入前，不同产品的签约审批流程由多个项目自己做，这就导致了多个产品审批流程间的交互逻辑、展现方式也都不太一致。每个逻辑都要对应的业务、技术和设计分别维护，人力成本高，而且还会收到用户吐槽说“为啥我签你们公司的两个产品需要这么麻烦，而且感觉填的内容都差不多？”

针对这种情况，我们就想，是不是可以把这个签约审批做成一个标准流程，然后通过设计中台对接到各项目。针对不同的产品，我们只需要根据产品的属性，配置不同的审批角色就行，但审批的步骤、审批信息的展示方式都是统一标准的。

于是，我们就把签约审批流程给标准化了。这回，业务、技术和设计三方都尝到了甜头。

对于设计来讲，直接节省了大量的人力投入。按照之前的老模式，每个流程设计完了，要跟对应的业务再讨论，不同的业务对细节还会有一些个性的要求，一来二去的，沟通成本特别大。

有了标准流程后，双方在细节上也很容易达成一致，甚至有些产品设计都不需要再画审批流程的页面了，直接标示出调用的设计控件的编号就好了。

对于技术来讲， 也 不需要浪费很多资源做重复建设了。按照之前的老模式，技术要针对每个产品都开发一套审批流程，费时费力，而且还容易出错。有了标准流程后，前端的流程就可以直接调用，只需要配置一个节点字段，前端就会自动展示适合该产品的审批流程。

对于业务来讲，设计中台的存在极大 地 提高了项目的交付效率。针对签约的相关功能，因为统一的标准化组件的使用，业务也不用逐一地确认每个页面，只需要确认清楚业务流程没有问题就行，提高了双方的沟通效率。技术也可以直接调用相关组件，完成对应功能的开发，快速上线。

所以，你看，签约审批流程的标准化，同时帮助业务、技术、设计三方节省了人力资源的投入，而且还缩减了项目的上线周期，在这件事中，最功不可没的就是设计中台。

对于设计师来讲，设计中台的价值不仅仅是帮助解决重复劳动的成本问题，更是让我们用 50% 的资源，去完成 80% 的常规项目。这样，另外 50% 的资源就能投入到更需要创新的领域。

炒炒总结

今天，我们学习了设计中台的相关知识，我来帮助你回顾一下本节课的重点内容。

首先，我们通过对设计中台、设计规范以及设计体系三个概念的区分，对设计中台有了一个全面的了解，它是一个设计能力的复用平台；设计中台包含设计规范，同时可以升级为设计体系。

在这里，我们还提到了设计中台的两个关键能力，资源调动和共建共享。

接下来，我们讨论了一家企业千万不要盲目地为了中台而中台。一些中小企业直接使用一些开源的中台项目，反而是更适合的方式；但是，针对一些产品线多、逻辑复杂、而且彼此之间有一些共性的大型企业来说，自己去建一个设计中台会比较合适。

在搭建设计中台的过程中，我们要设定专职人员，避免兼职的低效率；要增加设计资源的类型，覆盖更多的设计场景；要保持开放思维，积极跟进中台的反馈，保持更新；还要学会设置中台的数据统计模块。这些都能够帮助我们更高效地推进设计中台的建设，放大设计中台的价值；

最后，设计中台不只是对设计师有帮助，对于业务方、技术方都有明显的看得到的帮助。

希望这节课可以帮助你在工作中更高效地利用设计中台，让你和加班从此说“拜拜”。

课后题

你在工作中使用过设计中台吗？你是怎样利用设计中台来提高工作效率的呢？

记得在留言区和我讨论、交流你的想法，每一次思考都会成为你进步的基石。

如果你喜欢今天的内容，也欢迎你把这一讲分享给你的朋友。

感谢你的阅读，我们下一讲再见。