編輯導語：設計元件的更新與最佳化，需要哪些流程呢？本文作者將最佳化流程大致歸納為蒐集、探究、設計、開發、釋出這五個流程，並作出了詳細分析，一起來看一下吧。
有很多讀者想要了解關於元件更新和最佳化的工作流程和經驗，我最近就經常會收到如下讀者和粉絲的提問：
元件的更新需要怎樣的工作流程呢？
元件在更新與維護的過程中，設計與前端要如何配合呢？
元件設計師和其他設計師的工作有什麼區別呢？
其實元件庫的建設和最佳化工作其實並沒有絕對的標準，只有適合自己團隊的工作流程，才是真正有效和實用的。具體到
每一個元件的更新最佳化
，我的經驗是：從「發現元件的存在的問題」到「將元件進行更新和修復」，最佳化流程大致會被歸納成五個步驟：
蒐集
元件問題及最佳化需求
探究
分析元件的最佳化方案
設計
最佳化方案並進行評審
開發
方案完成並進行驗收
釋出
上線並同步元件更新
01 蒐集元件問題及最佳化需求
如果你希望你的元件庫可以與時俱進、賦能業務，定期蒐集元件問題和設計師們的使用反饋就很有必要。通常元件問題和需求可能來源於：
設計師 / 開發在使用元件
做業務時
發現的元件問題
設計師 / 開發發現
其他優秀的元件庫
案例中有值得借鑑之處
設計師在使用元件的過程中覺得
不方便、不易用
產品的
使用者反饋
某些功能或區域性模組在使用時體驗不好等等
收集和整理問題需要一張
需求列表
。你可以透過需求型別、完成狀態、負責人等方面對需求進行描述。同時你也需要對需求定義優先順序，確定排期和完成時間。下圖為需求列表的基礎示例：
參與人員：
使用元件的設計師和前端開發
所用時間：
不定期反饋和收集
所用工具：
公共的開放文件或看板（比如語雀文件、資料表、討論區等）對收集需求會有一定幫助，可以使其他設計師在做設計的過程中，遇到元件問題就自發填寫需求列表，實時共享。元件負責人將需求歸類整理、做好排期即可
Tips
Tips
收集元件問題需要使用元件的所有設計師群策群力，但是設計師遇到問題忙著做需求來不及記錄是常有的事情。因此必要時可以採用
1）群策群力，用制度約束行為
來做約束，比如每個設計師每月必須提交 1-2 個元件設計最佳化想法，或者每季度評審「元件問題查缺補漏」一二三名，給予精神或物質獎勵。
簡單的制度
你需要判斷這些需求的
2）評估需求，不是所有需求都值得最佳化
。並不是所有的元件設計需求都需要被立即最佳化，區分優先順序和做好排期很重要。你可以參考以下內容對需求進行綜合評估：
設計和開發當前可用資源
設計最佳化內容難易程度
元件在業務中出現的頻率
業務需求的緊急程度
元件的通用程度和擴充套件性等
真偽和輕重緩急
如果元件設計小組人數充足，元件負責人也可以安排指定的元件設計師來完成對應需求，因此需要指定到專人，並在表單中有體現，便於聯絡和實時溝通。
02 探究分析元件的最佳化方案
這需要對你上一步蒐集到的問題和需求進行分析和研究。對於業務元件的研究，我的建議是：一定要
3）指定到人，每個需求進度易追查
進行考慮。
你可以透過兩個方面來做元件分析和研究：
帶入到業務場景
收集和分析同類產品或類似功能場景下的實際應用案例。已經成熟的產品會更有說服力，也更值得被參考。
競品中類似的業務場景：
其他元件庫的解決
收集和分析其他優秀設計系統 / 元件庫中的同款元件案例，熟知的如 Ant Design、Material Design、Lightening Design、Carbon Design、SAP Fiori Design 等等。
當然你也需要綜合應用一切可行的設計方法和工具，透過學習競品、研讀文章、與有經驗的設計師交流討論（也歡迎向我提問和討論）、做 AB Test 等方法，研究合理的解決方案。
方案：
指定的元件設計師
參與人員：
2-3 天
所用時間：
的開放文件或設計文件
03 設計最佳化方案並進行評審
當設計師根據上一步的研究分析，產出最佳化後的元件設計稿，就可以組織或邀請團隊中其他設計師（尤其是元件問題的提出者）和開發對元件設計方案進行檢驗和評審。
評審通過後，進入元件的程式碼開發階段；評審不透過，收集意見再進行修改、更新和二次評審。
所用工具：公共
元件設計師、使用元件的設計師和前端開發
參與人員：
2-3 天
所用時間：
的開放文件或設計文件、線上或線下會議
所用工具：公共
Tips
「元件最佳化的評審」比「業務需求設計評審」更加
Tips
。因為元件評審人以設計師為主，而業務需求的評審人以業務和產品為主。設計師們之間的交流更需要有充分的證據和思考流程。
1）有理有據，分析過程要保留
你可以根據
注重設計分析依據
，建立元件設計的評審標準，根據標準和原則來進行設計評審，可以有效避免不必要的爭論。
2）建立標準，評估更快捷
有時元件設計和業務設計是同時進行的，任何時候都要
元件庫的設計原則
。元件設計師可以先配合業務設計師，完成當前業務的需求，之後再將元件進行通用性沉澱。業務應用也是對元件最好的檢驗場景。
04 開發方案完成並進行驗收
這一步由開發將元件的最佳化方案落實到程式碼，完成元件。開發完成後，需由元件設計師進行走查。完成的內容和質量反饋可以補充到上文所提到的「元件最佳化需求列表」中，易於追查。
3）業務先行，先完成業務需求
元件設計師、前端開發
遵守「業務先行」的規則
2-3 天
參與人員：
的開放文件、開發稿、線上或線下會議
05 釋出上線並同步元件更新
元件的上新「釋出」包括幾件事情：
一是將元件庫的
所用時間：
和
所用工具：公共
進行更新；
二是補充和編寫元件更新後的
設計Toolkits
三是團隊的
線上開發使用庫
，要做到所有成員的使用版本保持最新和統一。
使用規範；
元件設計師、使用元件的設計師和前端開發
更新事項同步
1-2 天
參與人員：
的開放文件、線上及線下元件庫、線上或線下會議
所用時間：
所用工具：公共
關於元件的使用規則，我們曾經在文章：如何讓「設計規範」被有效執行和落地？一文中做出過詳細的講解，設計規範的內容表達方式要「接地氣」，拒絕「假大空」，好記才好用。
Tips
有規律地同步元件最佳化進度。可以
Tips
，將本週更新的元件內容同步給團隊中的所有成員；或者
1）規則簡潔，好記才好用
，每月透過郵件釋出元件工作和最佳化進度，以達到全員知曉。
2）定期同步，有規律、可預期
以週會的形式
元件庫的更新和迭代的時間不宜過於頻繁，小的修改和最佳化，比如元件的區域性細節調整、次要顏色的色號更新等可以
以月報的形式
進行統一迭代；大的最佳化和升級，比如設計風格更新導致的主題色、圓角、互動形式的最佳化則推薦
3）重在穩定，避免頻繁
進行更新。
作者：元堯，微信公眾號：長弓小子
本文由@ 元堯 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議