对于 B 端数字产品来说，建立一套企业级的 Design Systems 可以提升团队生产力为企业赋能，这当中会沉淀很多设计资产（设计资产指 设计体系 中的所有产出物）。在有了 设计资产 后，如何确保使用者能够正确使用？如何维护其良性发展？如何管理设计体系资产？如何建立和谐的资产共创流程？这需要一套完善的、行之有效的更新机制。
说到更新，那必然不是 0-1 的过程，而是 1+1>2 的事情。去年我们更新了设计资产 V2.0 版本，随着业务的不断发展，在使用过程中发现基础组件模式需要新的拓展以更灵活的应对业务、发现缺少了组件的应用指南、使用场景等内容以更好的指导使用者、发现图标库缺少统一的管理等问题，因此在我们做了充分的调研和分析之后，启动了 V3.0 版本的更新工作，刚开始我们仅借鉴有赞的更新机制执行更新，但在执行过程中，我们遇到很多现实性的问题，基于此，我们结合团队现状沉淀出了一套完整的更新机制，它更适用于没有专门设计体系团队的中小型团队，在此跟大家分享，希望可以启发你的灵感。
在进入正题之前，我们先思考一下，为什么做项目可以从立项到最后稳定运行一步一步执行的那么有条不紊？那是因为在项目的整个生命周期中，有项目经理在利用十分成熟的项目管理知识体系，在指导每一步流程如何执行。那么同理，对于设计资产，它也是一个项目，我们借用项目管理思维去管理它，把更新流程代入到项目管理的闭环，该如何来做？下面从项目管理的五大过程来分享我们每一环节的方案。
一、启动过程 目的：触发开启、确定范围及周期
首先我们需要在启动时明确的核心内容是：什么时候开始更新？以什么样的周期进行更新？更新的范围如何定义？
1. 触发开启
在项目开启前，需要决定什么时候开始维护设计资产，这个很简单，在一个发版后，就要开始思考下一版本需要做什么了，这跟项目的版本迭代是同理的。所以在开启之前我们就应该要定义好如何做准备工作，如何收集设计资产的需求，这一点是我们一开始没有想清楚，后来在执行过程中总结出来的。
对于设计资产需求的收集是一个需要全员(资产建立者及使用者)参与的过程，需求的来源是每一个角色在使用设计资产做项目的过程中遇到的问题，把这些问题进行汇总记录，便形成了可能要做的需求。所以此时要有一个需求池承载这些内容，为确保大家更好的协作，我们在钉钉知识库建立了在线表格「设计资产需求池」用统一的格式提需求，让问题可追溯。
2. 确定范围
确定范围就像产品做需求管理是一样的，需要对大量的需求进行筛选、归纳、排序等，最终确认每个版本的需求范围。同样，针对需求池中的内容，我们是以月度为时间节点召集相关干系人（也会根据产品的更新频率动态调整为两月一次），对需求池进行定期评审，通过需求决策三角模型来决策是否转化为有效需求，从需求的普适度、拓展性和实现成本三个维度来筛选、归纳、整理需求，然后用采纳、不采纳和待定三个状态来决策是否要做，最后会根据迫切度对需求排出优先级，这样就完成了我们需求范围的定义。
然后，针对范围内的需求，进行解决方案的讨论，或许是优化、或许是新增的内容，都需要对提出人的解决方案进行讨论，若方案被大家一致共识 OK，那么方案按其实现；若有人存在异议，则需探讨出更优的方案。总之，是为了得出大家共识的和更优的解决方案，这是建立共同意识的良好时机，也为后续的组件资产使用提前加深印象。
3. 确定周期
为了使每个人都能与设计资产的进化步调保持一致，它的更新是需要有节奏的、定期执行的。
更新周期需要结合项目的实际更新节奏去定义，设计资产作为设计的指导工具，当然是不能很频繁的更新，特别对于 B 端产品来说，大部分是以业务为主，组件的更新多半是一个事后的行为，所以我们暂定的频率是月度进行一次需求评审，根据通用性、复用性这两大指标的重要程度，在组内讨论看是否需要对其更新，会先进行内部文件更新，以季度的时间节点进行一次线上更新需求的评审，以评估是否要进行线上库的更新，实际线上库是时隔一年我们发布了 V3.0 版本。
二、规划过程 目的：制定计划、明确分工
有了节点划分，具体要做的事情该如何去做，应该存在一个流程规范，并且要根据参与角色的不同分别制定。在我们设计资产更新维护过程中主要有以下几个角色和对应要做的事项，具体为：
设计共创者：发现问题、输出方案、提出需求、参与讨论、执行验收… 前端工程师：发现问题、提出建议、提出需求、参与讨论、开发实现… 资产负责人：制定计划、资产维护、组织评审、推进进度、全流程统筹管理… 在设计资产维护过程中为确保角色之间的协作能够顺畅的进行，我针对多个角色从需求阶段、设计阶段、开发阶段三个阶段，分别定义了流程图和产出物流转图，需求阶段的流程如下：
后续在我们的资产和流程成熟后，会规划把收集需求这一过程开放出去，让更多的角色参与进来。前提是我们已经在公司内做好了设计系统的推广和普及的工作，这是计划下一步要做的事情。因为在项目协作过程中你会发现，除了前端和设计之外，像产品、测试他们都有了解设计系统的需求，如在测试过程中，当他们对一些功能点的交互方式或组件的视觉呈现有疑问时，就会到设计这边来询问，或者有一些建设性的建议等，这些外界的声音我们作为 设计系统 的构建者应该及时收集，所以后续我们会思考如何更全面的收集需求，让更多的人参与构建。
三、执行过程 目的：执行工作、确认交付
执行过程分为两条线，一是设计侧本地文档更新的执行过程，二是前端侧线上库更新的执行过程。
1. 设计侧
设计侧的执行是要及时的更新设计稿，根据每月对需求的评审，会按评审频率同步更新本地设计资产文档，也就是我们的 sketch 文档，这份文档更新之后便满足了设计组内做产品设计时可以使用完整的内容。
对于设计资产文档的维护单独库对应到人进行一对一负责的，最初为了让大家共同参与进来，在基础组件库的设计时，让每个业务线的设计师单独设计，然后由负责人进行汇总，但这样受限于 sketch 软件本身，遇到一个很繁琐的问题：当组件由不同的人各自在不同的本地文件绘制后，汇总的人没有办法直接 copy 到公用的文档中一键生成可调用的组件插件（不知道使用云文档的团队是否可以直接实现多人对一个文档进行共同编辑，不用本地文档传来传去），所以最终的汇总基本是需要重设计一遍，这样就引起重复工作的问题，在经历了两次这样的流程后，我们对此进行了优化，后续改为每个库由单独的人来负责设计产出，图标库、基础组件库以及可视化组件库都分别由一人负责绘制、上传、对接、更新。
2. 前端侧
本地设计稿更新之后，需要前端支持进行线上库的更新，线上资产更新需要设计和前端协作完成，这时我们是通过产出设计资产平台文档前端版来进行协作的。这个文档是从使用者的角度进行设计的，按照：基础规范、通用组件两大类进行划分，其中通用组件包含：导航、数据录入、数据展示、数据反馈、其他五大块内容，每个组件元素的内容分为：实例、API 和指南三大模块，其中指南当中包含了：使用场景、组件构成、组件尺寸、交互状态等内容，是一份用来帮助使用者更好的使用组件的指南型文档。
线上资产的更新频率以季度为周期（也根据业务产品的迭代频率动态调整），图标库的更新是跟随产品版本按照图标的固定流程进行更新。
四、监控过程 目的：发现偏差、做好验收
开发过程中和完成后，需要对还原度进行监控，验证是否与预期保持一致，这里的做法跟我们项目验收是一样的，检查资产实现的质量，整理到验收文档中与前端对接优化。对于设计验收之前写过一篇复盘小文，感兴趣的可跳转查看。
最后一道防线！五步提升 UI 交互验收效率（附验收模板） 细节决定成败，这次跟大家聊聊项目开发中最后一个环节，也是考验细节能力的一个环节，即「设计验收」。
阅读文章 >
监控过程是上线前的质量把关环节，这个过程中我们也是全员参与的，设计+前端，通过互查、自查、验收的方式对组件进行验收，这个过程也是建立共识的好时机，所以更应该积极推动每个组件干系人积极参与进来。
五、收尾过程 目的：发布版本、归档复盘
在发布版本之前，需要编写更新记录，更新记录我们是维护了两份，一份是线上平台中展示的更新记录，主要由前端编写，内容涉及到组件具体的实现、调用替换等技术修改相关内容，较为细致。另一份是维护在钉钉公共库维护的「设计体系更新表」，此表格的内容更为概括，主要是做功能变更记录，两份文档的更新版本号是保持一致的。
所有的工作完成之后，最后，发布版本。每个版本更新后，除了将更新内容同步给核心的使用者以外，还需要将设计资产更新内容进行更广泛的分享，需要主动的引导和推广团队内更多的人去关注和学习设计体系知识，才能使更多人更好的使用起来，才能使其良好且持久的运转，才能收集更多建议以建立更加和谐的资产共创流程。
收尾并不是结束，而是代表新的开始。
总结 这套完整的更新流程是根据今年设计资产从 V2.0 升级到 V3.0 总结而来，整个思路和灵感来源有项目管理知识体系以及 Design Systems 这本书，所有知识都是融会贯通的，我们利用项目管理的思维找到了适合自己团队资产更新的流程，能够适应我们团队的自然工作流程，只有这样团队里的每个人才会具有主动性，大家对设计资产的贡献才能更加均匀。虽然在执行的过程中还是会或多或少的需要一些问题，比如按时间节点迭代不能快速的解决组件当下的问题以更快的应用、大家在业务外需要花费更多的精力参与到共创过程难免积极性会有差异、具有创新性的想法不能及时的被纳入库实现……这需要我们不断的去优化这个小而美的流程，以更好的为团队协作提升效率。
流程提供的仅仅是大方向上的指南，具体的执行需要根据实际工作流程随机应变，在此把我们的思路和成果分享给大家，希望大家进行交流学习，路漫漫其修远兮，吾将上下而求索，设计的进步需要不断的反思和沉淀，需要更多的思维碰撞。
总之，多读、多看、多学、多分享，步履不停……
欢迎关注作者微信公众号：「做设计的小仙草」
