? ?????全文共 2872 字，閱讀需要 8?分鐘

有很多讀者想要了解關于組件更新和優(yōu)化的工作流程和經(jīng)驗，我最近經(jīng)常會收到如下問題：

-????組件的更新需要怎樣的工作流程呢？

-????組件在更新與維護的過程中，設計與前端要如何配合呢？

-??? 組件設計師和其他設計師的工作有什么區(qū)別呢？

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

Step 1.? 搜集組件問題及優(yōu)化需求

Step?2.??探究分析組件的優(yōu)化方案

Step?3.? 設計優(yōu)化方案并進行評審

Step?4.? 開發(fā)方案完成并進行驗收

Step?5.? 發(fā)布上線并同步組件更新

STEP 1

搜集

搜集組件問題及優(yōu)化需求

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

- 設計師 / 開發(fā)在使用組件做業(yè)務時發(fā)現(xiàn)的組件問題；

-?設計師 / 開發(fā)發(fā)現(xiàn)其他優(yōu)秀的組件庫案例中有值得借鑒之處；

- 設計師在使用組件的過程中覺得不方便、不易用；

-?產(chǎn)品的用戶反饋某些功能或局部模塊在使用時體驗不好等等。

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

·? 參與人員：使用組件的設計師和前端開發(fā)。

·??所用時間：不定期反饋和收集。

·??所用工具：公共的開放文檔或看板（比如語雀文檔、數(shù)據(jù)表、討論區(qū)等）對收集需求會有一定幫助，可以使其他設計師在做設計的過程中，遇到組件問題就自發(fā)填寫需求列表，實時共享。組件負責人將需求歸類整理、做好排期即可。

???TIPS：

?? 群策群力，用制度約束行為

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

?? 評估需求，不是所有需求都值得優(yōu)化

你需要判斷這些需求的真?zhèn)魏洼p重緩急。并不是所有的組件設計需求都需要被立即優(yōu)化，區(qū)分優(yōu)先級和做好排期很重要。你可以參考以下內(nèi)容對需求進行綜合評估：

- 設計和開發(fā)當前可用資源?

- 設計優(yōu)化內(nèi)容難易程度?

-?組件在業(yè)務中出現(xiàn)的頻率

- 業(yè)務需求的緊急程度?

- 組件的通用程度和擴展性等等

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

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

STEP 2

探究

探究分析組件的優(yōu)化方案

這需要對你上一步搜集到的問題和需求進行分析和研究。對于業(yè)務組件的研究，我的建議是：一定要帶入到業(yè)務場景進行考慮。你可以通過兩個方面來做組件分析和研究：

一是競品中類似的業(yè)務場景：收集和分析同類產(chǎn)品或類似功能場景下的實際應用案例。已經(jīng)成熟的產(chǎn)品會更有說服力，也更值得被參考。

二是其他組件庫的解決方案：收集和分析其他優(yōu)秀設計系統(tǒng) / 組件庫中的同款組件案例，熟知的如 Ant Design、Material Design、Lightening Design、Carbon Design、SAP Fiori Design 等等。

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

·? 參與人員：指定的組件設計師。

·??所用時間：2-3 天。

·??所用工具：公共的開放文檔或設計文檔。

STEP 3

設計

設計優(yōu)化方案并進行評審

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

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

·? 參與人員：組件設計師、使用組件的設計師和前端開發(fā)。

·??所用時間：2-3 天。

·??所用工具：公共的開放文檔或設計文檔、線上或線下會議。

???TIPS：

???有理有據(jù)，分析過程要保留

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

?? 建立標準，評估更快捷

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

???業(yè)務先行，先完成業(yè)務需求

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

STEP 4

開發(fā)

開發(fā)方案完成并進行驗收

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

·? 參與人員：組件設計師、前端開發(fā)。

·??所用時間：2-3 天。

·??所用工具：公共的開放文檔、開發(fā)稿、線上或線下會議。

STEP 5

發(fā)布

發(fā)布上線并同步組件更新

組件的上新「發(fā)布」包括幾件事情：

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

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

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

·? 參與人員：組件設計師、使用組件的設計師和前端開發(fā)。

·??所用時間：1-2 天。

·??所用工具：公共的開放文檔、線上及線下組件庫、線上或線下會議。

???TIPS：

???規(guī)則簡潔，好記才好用

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

???定期同步，有規(guī)律、可預期

有規(guī)律地同步組件優(yōu)化進度。可以以周會的形式，將本周更新的組件內(nèi)容同步給團隊中的所有成員；或者以月報的形式，每月通過郵件發(fā)布組件工作和優(yōu)化進度，以達到全員知曉。

?? 重在穩(wěn)定，避免頻繁更新

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

本文內(nèi)容為轉(zhuǎn)載 僅供個人學習使用