對于 B 端數字產品來說，建立一套企業級的 Design Systems 可以提升團隊生產力為企業賦能，這當中會沉淀很多設計資產（設計資產指設計體系中的所有產出物）。在有了設計資產后，如何確保使用者能夠正確使用？如何維護其良性發展？如何管理設計體系資產？如何建立和諧的資產共創流程？這需要一套完善的、行之有效的更新機制。

說到更新，那必然不是 0-1 的過程，而是 1+1>2 的事情。去年我們更新了設計資產 V2.0 版本，隨著業務的不斷發展，在使用過程中發現基礎組件模式需要新的拓展以更靈活的應對業務、發現缺少了組件的應用指南、使用場景等內容以更好的指導使用者、發現圖標庫缺少統一的管理等問題，因此在我們做了充分的調研和分析之后，啟動了 V3.0 版本的更新工作，剛開始我們僅借鑒有贊的更新機制執行更新，但在執行過程中，我們遇到很多現實性的問題，基于此，我們結合團隊現狀沉淀出了一套完整的更新機制，它更適用于沒有專門設計體系團隊的中小型團隊，在此跟大家分享，希望可以啟發你的靈感。

在進入正題之前，我們先思考一下，為什么做項目可以從立項到最后穩定運行一步一步執行的那么有條不紊？那是因為在項目的整個生命周期中，有項目經理在利用十分成熟的項目管理知識體系，在指導每一步流程如何執行。那么同理，對于設計資產，它也是一個項目，我們借用項目管理思維去管理它，把更新流程代入到項目管理的閉環，該如何來做？下面從項目管理的五大過程來分享我們每一環節的方案。

一、啟動過程

目的：觸發開啟、確定范圍及周期

首先我們需要在啟動時明確的核心內容是：什么時候開始更新？以什么樣的周期進行更新？更新的范圍如何定義？

1. 觸發開啟

在項目開啟前，需要決定什么時候開始維護設計資產，這個很簡單，在一個發版后，就要開始思考下一版本需要做什么了，這跟項目的版本迭代是同理的。所以在開啟之前我們就應該要定義好如何做準備工作，如何收集設計資產的需求，這一點是我們一開始沒有想清楚，后來在執行過程中總結出來的。

對于設計資產需求的收集是一個需要全員(資產建立者及使用者)參與的過程，需求的來源是每一個角色在使用設計資產做項目的過程中遇到的問題，把這些問題進行匯總記錄，便形成了可能要做的需求。所以此時要有一個需求池承載這些內容，為確保大家更好的協作，我們在釘釘知識庫建立了在線表格「設計資產需求池」用統一的格式提需求，讓問題可追溯。

2. 確定范圍

確定范圍就像產品做需求管理是一樣的，需要對大量的需求進行篩選、歸納、排序等，最終確認每個版本的需求范圍。同樣，針對需求池中的內容，我們是以月度為時間節點召集相關干系人（也會根據產品的更新頻率動態調整為兩月一次），對需求池進行定期評審，通過需求決策三角模型來決策是否轉化為有效需求，從需求的普適度、拓展性和實現成本三個維度來篩選、歸納、整理需求，然后用采納、不采納和待定三個狀態來決策是否要做，最后會根據迫切度對需求排出優先級，這樣就完成了我們需求范圍的定義。

然后，針對范圍內的需求，進行解決方案的討論，或許是優化、或許是新增的內容，都需要對提出人的解決方案進行討論，若方案被大家一致共識 OK，那么方案按其實現；若有人存在異議，則需探討出更優的方案。總之，是為了得出大家共識的和更優的解決方案，這是建立共同意識的良好時機，也為后續的組件資產使用提前加深印象。

3. 確定周期

為了使每個人都能與設計資產的進化步調保持一致，它的更新是需要有節奏的、定期執行的。

更新周期需要結合項目的實際更新節奏去定義，設計資產作為設計的指導工具，當然是不能很頻繁的更新，特別對于 B 端產品來說，大部分是以業務為主，組件的更新多半是一個事后的行為，所以我們暫定的頻率是月度進行一次需求評審，根據通用性、復用性這兩大指標的重要程度，在組內討論看是否需要對其更新，會先進行內部文件更新，以季度的時間節點進行一次線上更新需求的評審，以評估是否要進行線上庫的更新，實際線上庫是時隔一年我們發布了 V3.0 版本。

二、規劃過程

目的：制定計劃、明確分工

有了節點劃分，具體要做的事情該如何去做，應該存在一個流程規范，并且要根據參與角色的不同分別制定。在我們設計資產更新維護過程中主要有以下幾個角色和對應要做的事項，具體為：

1. 設計共創者：發現問題、輸出方案、提出需求、參與討論、執行驗收…
2. 前端工程師：發現問題、提出建議、提出需求、參與討論、開發實現…
3. 資產負責人：制定計劃、資產維護、組織評審、推進進度、全流程統籌管理…

在設計資產維護過程中為確保角色之間的協作能夠順暢的進行，我針對多個角色從需求階段、設計階段、開發階段三個階段，分別定義了流程圖和產出物流轉圖，需求階段的流程如下：

后續在我們的資產和流程成熟后，會規劃把收集需求這一過程開放出去，讓更多的角色參與進來。前提是我們已經在公司內做好了設計系統的推廣和普及的工作，這是計劃下一步要做的事情。因為在項目協作過程中你會發現，除了前端和設計之外，像產品、測試他們都有了解設計系統的需求，如在測試過程中，當他們對一些功能點的交互方式或組件的視覺呈現有疑問時，就會到設計這邊來詢問，或者有一些建設性的建議等，這些外界的聲音我們作為設計系統的構建者應該及時收集，所以后續我們會思考如何更全面的收集需求，讓更多的人參與構建。

三、執行過程

目的：執行工作、確認交付

執行過程分為兩條線，一是設計側本地文檔更新的執行過程，二是前端側線上庫更新的執行過程。

1. 設計側

設計側的執行是要及時的更新設計稿，根據每月對需求的評審，會按評審頻率同步更新本地設計資產文檔，也就是我們的 sketch 文檔，這份文檔更新之后便滿足了設計組內做產品設計時可以使用完整的內容。

對于設計資產文檔的維護單獨庫對應到人進行一對一負責的，最初為了讓大家共同參與進來，在基礎組件庫的設計時，讓每個業務線的設計師單獨設計，然后由負責人進行匯總，但這樣受限于 sketch 軟件本身，遇到一個很繁瑣的問題：當組件由不同的人各自在不同的本地文件繪制后，匯總的人沒有辦法直接 copy 到公用的文檔中一鍵生成可調用的組件插件（不知道使用云文檔的團隊是否可以直接實現多人對一個文檔進行共同編輯，不用本地文檔傳來傳去），所以最終的匯總基本是需要重設計一遍，這樣就引起重復工作的問題，在經歷了兩次這樣的流程后，我們對此進行了優化，后續改為每個庫由單獨的人來負責設計產出，圖標庫、基礎組件庫以及可視化組件庫都分別由一人負責繪制、上傳、對接、更新。

2. 前端側

本地設計稿更新之后，需要前端支持進行線上庫的更新，線上資產更新需要設計和前端協作完成，這時我們是通過產出設計資產平臺文檔前端版來進行協作的。這個文檔是從使用者的角度進行設計的，按照：基礎規范、通用組件兩大類進行劃分，其中通用組件包含：導航、數據錄入、數據展示、數據反饋、其他五大塊內容，每個組件元素的內容分為：實例、API 和指南三大模塊，其中指南當中包含了：使用場景、組件構成、組件尺寸、交互狀態等內容，是一份用來幫助使用者更好的使用組件的指南型文檔。

線上資產的更新頻率以季度為周期（也根據業務產品的迭代頻率動態調整），圖標庫的更新是跟隨產品版本按照圖標的固定流程進行更新。

四、監控過程

目的：發現偏差、做好驗收

開發過程中和完成后，需要對還原度進行監控，驗證是否與預期保持一致，這里的做法跟我們項目驗收是一樣的，檢查資產實現的質量，整理到驗收文檔中與前端對接優化。對于設計驗收之前寫過一篇復盤小文，感興趣的可跳轉查看。

監控過程是上線前的質量把關環節，這個過程中我們也是全員參與的，設計+前端，通過互查、自查、驗收的方式對組件進行驗收，這個過程也是建立共識的好時機，所以更應該積極推動每個組件干系人積極參與進來。

五、收尾過程

目的：發布版本、歸檔復盤

在發布版本之前，需要編寫更新記錄，更新記錄我們是維護了兩份，一份是線上平臺中展示的更新記錄，主要由前端編寫，內容涉及到組件具體的實現、調用替換等技術修改相關內容，較為細致。另一份是維護在釘釘公共庫維護的「設計體系更新表」，此表格的內容更為概括，主要是做功能變更記錄，兩份文檔的更新版本號是保持一致的。

所有的工作完成之后，最后，發布版本。每個版本更新后，除了將更新內容同步給核心的使用者以外，還需要將設計資產更新內容進行更廣泛的分享，需要主動的引導和推廣團隊內更多的人去關注和學習設計體系知識，才能使更多人更好的使用起來，才能使其良好且持久的運轉，才能收集更多建議以建立更加和諧的資產共創流程。

收尾并不是結束，而是代表新的開始。

總結

這套完整的更新流程是根據今年設計資產從 V2.0 升級到 V3.0 總結而來，整個思路和靈感來源有項目管理知識體系以及 Design Systems 這本書，所有知識都是融會貫通的，我們利用項目管理的思維找到了適合自己團隊資產更新的流程，能夠適應我們團隊的自然工作流程，只有這樣團隊里的每個人才會具有主動性，大家對設計資產的貢獻才能更加均勻。雖然在執行的過程中還是會或多或少的需要一些問題，比如按時間節點迭代不能快速的解決組件當下的問題以更快的應用、大家在業務外需要花費更多的精力參與到共創過程難免積極性會有差異、具有創新性的想法不能及時的被納入庫實現……這需要我們不斷的去優化這個小而美的流程，以更好的為團隊協作提升效率。

流程提供的僅僅是大方向上的指南，具體的執行需要根據實際工作流程隨機應變，在此把我們的思路和成果分享給大家，希望大家進行交流學習，路漫漫其修遠兮，吾將上下而求索，設計的進步需要不斷的反思和沉淀，需要更多的思維碰撞。

總之，多讀、多看、多學、多分享，步履不停……

歡迎關注作者微信公眾號：「做設計的小仙草」