工作經驗|設計組件的更新和優化,需要哪些流程?

1 評論 2766 瀏覽 24 收藏 11 分鐘

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

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

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

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

  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 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 作者總結的設計組件的更新和優化的流程很詳細全面,學習到了。

    來自江蘇 回復