工作經驗|設計組件的更新和優化,需要哪些流程?
編輯導語:設計組件的更新與優化,需要哪些流程呢?本文作者將優化流程大致歸納為搜集、探究、設計、開發、發布這五個流程,并作出了詳細分析,一起來看一下吧。
有很多讀者想要了解關于組件更新和優化的工作流程和經驗,我最近就經常會收到如下讀者和粉絲的提問:
- 組件的更新需要怎樣的工作流程呢?
- 組件在更新與維護的過程中,設計與前端要如何配合呢?
- 組件設計師和其他設計師的工作有什么區別呢?
其實組件庫的建設和優化工作其實并沒有絕對的標準,只有適合自己團隊的工作流程,才是真正有效和實用的。具體到每一個組件的更新優化,我的經驗是:從「發現組件的存在的問題」到「將組件進行更新和修復」,優化流程大致會被歸納成五個步驟:
- 搜集組件問題及優化需求
- 探究分析組件的優化方案
- 設計優化方案并進行評審
- 開發方案完成并進行驗收
- 發布上線并同步組件更新
01 搜集組件問題及優化需求
如果你希望你的組件庫可以與時俱進、賦能業務,定期搜集組件問題和設計師們的使用反饋就很有必要。通常組件問題和需求可能來源于:
- 設計師 / 開發在使用組件做業務時發現的組件問題
- 設計師 / 開發發現其他優秀的組件庫案例中有值得借鑒之處
- 設計師在使用組件的過程中覺得不方便、不易用
- 產品的用戶反饋某些功能或局部模塊在使用時體驗不好等等
收集和整理問題需要一張需求列表。你可以通過需求類型、完成狀態、負責人等方面對需求進行描述。同時你也需要對需求定義優先級,確定排期和完成時間。下圖為需求列表的基礎示例:
- 參與人員:使用組件的設計師和前端開發
- 所用時間:不定期反饋和收集
- 所用工具:公共的開放文檔或看板(比如語雀文檔、數據表、討論區等)對收集需求會有一定幫助,可以使其他設計師在做設計的過程中,遇到組件問題就自發填寫需求列表,實時共享。組件負責人將需求歸類整理、做好排期即可
Tips
1)群策群力,用制度約束行為
收集組件問題需要使用組件的所有設計師群策群力,但是設計師遇到問題忙著做需求來不及記錄是常有的事情。因此必要時可以采用簡單的制度來做約束,比如每個設計師每月必須提交 1-2 個組件設計優化想法,或者每季度評審「組件問題查缺補漏」一二三名,給予精神或物質獎勵。
2)評估需求,不是所有需求都值得優化
你需要判斷這些需求的真偽和輕重緩急。并不是所有的組件設計需求都需要被立即優化,區分優先級和做好排期很重要。你可以參考以下內容對需求進行綜合評估:
- 設計和開發當前可用資源
- 設計優化內容難易程度
- 組件在業務中出現的頻率
- 業務需求的緊急程度
- 組件的通用程度和擴展性等
3)指定到人,每個需求進度易追查
如果組件設計小組人數充足,組件負責人也可以安排指定的組件設計師來完成對應需求,因此需要指定到專人,并在表單中有體現,便于聯系和實時溝通。
02 探究分析組件的優化方案
這需要對你上一步搜集到的問題和需求進行分析和研究。對于業務組件的研究,我的建議是:一定要帶入到業務場景進行考慮。
你可以通過兩個方面來做組件分析和研究:
- 競品中類似的業務場景:收集和分析同類產品或類似功能場景下的實際應用案例。已經成熟的產品會更有說服力,也更值得被參考。
- 其他組件庫的解決方案:收集和分析其他優秀設計系統 / 組件庫中的同款組件案例,熟知的如 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 協議
作者總結的設計組件的更新和優化的流程很詳細全面,學習到了。