編輯導語：設計組件的更新與優化，需要哪些流程呢？本文作者將優化流程大致歸納為搜集、探究、設計、開發、發布這五個流程，并作出了詳細分析，一起來看一下吧。

有很多讀者想要了解關于組件更新和優化的工作流程和經驗，我最近就經常會收到如下讀者和粉絲的提問：

• 組件的更新需要怎樣的工作流程呢？
• 組件在更新與維護的過程中，設計與前端要如何配合呢？
• 組件設計師和其他設計師的工作有什么區別呢？

其實組件庫的建設和優化工作其實并沒有絕對的標準，只有適合自己團隊的工作流程，才是真正有效和實用的。具體到每一個組件的更新優化，我的經驗是：從「發現組件的存在的問題」到「將組件進行更新和修復」，優化流程大致會被歸納成五個步驟：

1. 搜集組件問題及優化需求
2. 探究分析組件的優化方案
3. 設計優化方案并進行評審
4. 開發方案完成并進行驗收
5. 發布上線并同步組件更新

01 搜集組件問題及優化需求

如果你希望你的組件庫可以與時俱進、賦能業務，定期搜集組件問題和設計師們的使用反饋就很有必要。通常組件問題和需求可能來源于：

• 設計師 / 開發在使用組件做業務時發現的組件問題
• 設計師 / 開發發現其他優秀的組件庫案例中有值得借鑒之處
• 設計師在使用組件的過程中覺得不方便、不易用
• 產品的用戶反饋某些功能或局部模塊在使用時體驗不好等等

收集和整理問題需要一張需求列表。你可以通過需求類型、完成狀態、負責人等方面對需求進行描述。同時你也需要對需求定義優先級，確定排期和完成時間。下圖為需求列表的基礎示例：

• 參與人員：使用組件的設計師和前端開發
• 所用時間：不定期反饋和收集
• 所用工具：公共的開放文檔或看板（比如語雀文檔、數據表、討論區等）對收集需求會有一定幫助，可以使其他設計師在做設計的過程中，遇到組件問題就自發填寫需求列表，實時共享。組件負責人將需求歸類整理、做好排期即可

Tips

1）群策群力，用制度約束行為

收集組件問題需要使用組件的所有設計師群策群力，但是設計師遇到問題忙著做需求來不及記錄是常有的事情。因此必要時可以采用簡單的制度來做約束，比如每個設計師每月必須提交 1-2 個組件設計優化想法，或者每季度評審「組件問題查缺補漏」一二三名，給予精神或物質獎勵。

2）評估需求，不是所有需求都值得優化

你需要判斷這些需求的真偽和輕重緩急。并不是所有的組件設計需求都需要被立即優化，區分優先級和做好排期很重要。你可以參考以下內容對需求進行綜合評估：

• 設計和開發當前可用資源
• 設計優化內容難易程度
• 組件在業務中出現的頻率
• 業務需求的緊急程度
• 組件的通用程度和擴展性等

3）指定到人，每個需求進度易追查

如果組件設計小組人數充足，組件負責人也可以安排指定的組件設計師來完成對應需求，因此需要指定到專人，并在表單中有體現，便于聯系和實時溝通。

02 探究分析組件的優化方案

這需要對你上一步搜集到的問題和需求進行分析和研究。對于業務組件的研究，我的建議是：一定要帶入到業務場景進行考慮。

你可以通過兩個方面來做組件分析和研究：

1. 競品中類似的業務場景：收集和分析同類產品或類似功能場景下的實際應用案例。已經成熟的產品會更有說服力，也更值得被參考。
2. 其他組件庫的解決方案：收集和分析其他優秀設計系統 / 組件庫中的同款組件案例，熟知的如 Ant Design、Material Design、Lightening Design、Carbon Design、SAP Fiori Design 等等。

當然你也需要綜合應用一切可行的設計方法和工具，通過學習競品、研讀文章、與有經驗的設計師交流討論（也歡迎向我提問和討論）、做 AB Test 等方法，研究合理的解決方案。

• 參與人員：指定的組件設計師
• 所用時間：2-3 天
• 所用工具：公共的開放文檔或設計文檔

03 設計優化方案并進行評審

當設計師根據上一步的研究分析，產出優化后的組件設計稿，就可以組織或邀請團隊中其他設計師（尤其是組件問題的提出者）和開發對組件設計方案進行檢驗和評審。

評審通過后，進入組件的代碼開發階段；評審不通過，收集意見再進行修改、更新和二次評審。

• 參與人員：組件設計師、使用組件的設計師和前端開發
• 所用時間：2-3 天
• 所用工具：公共的開放文檔或設計文檔、線上或線下會議

Tips

1）有理有據，分析過程要保留

「組件優化的評審」比「業務需求設計評審」更加注重設計分析依據。因為組件評審人以設計師為主，而業務需求的評審人以業務和產品為主。設計師們之間的交流更需要有充分的證據和思考流程。

2）建立標準，評估更快捷

你可以根據組件庫的設計原則，建立組件設計的評審標準，根據標準和原則來進行設計評審，可以有效避免不必要的爭論。

3）業務先行，先完成業務需求

有時組件設計和業務設計是同時進行的，任何時候都要遵守「業務先行」的規則。組件設計師可以先配合業務設計師，完成當前業務的需求，之后再將組件進行通用性沉淀。業務應用也是對組件最好的檢驗場景。

04 開發方案完成并進行驗收

這一步由開發將組件的優化方案落實到代碼，完成組件。開發完成后，需由組件設計師進行走查。完成的內容和質量反饋可以補充到上文所提到的「組件優化需求列表」中，易于追查。

• 參與人員：組件設計師、前端開發
• 所用時間：2-3 天
• 所用工具：公共的開放文檔、開發稿、線上或線下會議

05 發布上線并同步組件更新

組件的上新「發布」包括幾件事情：

一是將組件庫的設計Toolkits和線上開發使用庫進行更新；

二是補充和編寫組件更新后的使用規范；

三是團隊的更新事項同步，要做到所有成員的使用版本保持最新和統一。

• 參與人員：組件設計師、使用組件的設計師和前端開發
• 所用時間：1-2 天
• 所用工具：公共的開放文檔、線上及線下組件庫、線上或線下會議

Tips

1）規則簡潔，好記才好用

關于組件的使用規則，我們曾經在文章：如何讓「設計規范」被有效執行和落地？一文中做出過詳細的講解，設計規范的內容表達方式要「接地氣」，拒絕「假大空」，好記才好用。

2）定期同步，有規律、可預期

有規律地同步組件優化進度?？梢?strong>以周會的形式，將本周更新的組件內容同步給團隊中的所有成員；或者以月報的形式，每月通過郵件發布組件工作和優化進度，以達到全員知曉。

3）重在穩定，避免頻繁更新

組件庫的更新和迭代的時間不宜過于頻繁，小的修改和優化，比如組件的局部細節調整、次要顏色的色號更新等可以以周 / 月為單位進行統一迭代；大的優化和升級，比如設計風格更新導致的主題色、圓角、交互形式的優化則推薦以年為單位進行更新。

作者：元堯，微信公眾號：長弓小子

本文由@ 元堯 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議