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

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

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

一、啟動過程

目的：觸發(fā)開啟、確定范圍及周期

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

1. 觸發(fā)開啟

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

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

2. 確定范圍

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

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

3. 確定周期

為了使每個人都能與設(shè)計資產(chǎn)的進化步調(diào)保持一致，它的更新是需要有節(jié)奏的、定期執(zhí)行的。

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

二、規(guī)劃過程

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

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

1. 設(shè)計共創(chuàng)者：發(fā)現(xiàn)問題、輸出方案、提出需求、參與討論、執(zhí)行驗收…
2. 前端工程師：發(fā)現(xiàn)問題、提出建議、提出需求、參與討論、開發(fā)實現(xiàn)…
3. 資產(chǎn)負(fù)責(zé)人：制定計劃、資產(chǎn)維護、組織評審、推進進度、全流程統(tǒng)籌管理…

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

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

三、執(zhí)行過程

目的：執(zhí)行工作、確認(rèn)交付

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

1. 設(shè)計側(cè)

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

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

2. 前端側(cè)

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

線上資產(chǎn)的更新頻率以季度為周期（也根據(jù)業(yè)務(wù)產(chǎn)品的迭代頻率動態(tài)調(diào)整），圖標(biāo)庫的更新是跟隨產(chǎn)品版本按照圖標(biāo)的固定流程進行更新。

四、監(jiān)控過程

目的：發(fā)現(xiàn)偏差、做好驗收

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

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

五、收尾過程

目的：發(fā)布版本、歸檔復(fù)盤

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

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

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

總結(jié)

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

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

總之，多讀、多看、多學(xué)、多分享，步履不停……

歡迎關(guān)注作者微信公眾號：「做設(shè)計的小仙草」