有時候一些産品的UI設計非常精巧，在網絡上好評如潮。但這些産品往往都是互聯網産品，傳統企業的産品恰恰相反，他們的UI被吐槽一成不變，跟不上時代。傳統企業當前也存在着優化體驗的訴求，但落實起來卻面臨着行動步調不一緻的困難。本文作者圍繞傳統企業的UI展開了分析，與你分享。

傳統企業對産品體驗的忽略程度是互聯網公司難以想象的，以至于粗糙得還像個demo的版本就可以如期上線了，“功能至上”并不是傳統企業專屬的理念，互聯網公司也是功能為先，隻是差别在于互聯網公司是“功能”和“體驗”并重，傳統企業是“功能”一枝獨秀。

傳統企業當前也存在着優化體驗的訴求，但落實起來卻面臨着行動步調不一緻的困難。在工期估算方法不變的情況下，單純地提高對一線開發人員的要求，是一件推動起來明顯吃力的事情。UI一緻性工程，或許是傳統企業解決這個問題的一個方向。

一、UI一緻性工程是什麼

提起UI一緻性工程，很多人可能不太了解，但說起組件化，相信很多人都比較熟悉。

以前我們說組件化，常常是指開發側，而且一般是指前端，因此組件化常常是指前端代碼的組件化。前端代碼組件化，是把頁面中重複率比較高的一些樣式代碼提取出來，做成一個個的代碼組件，這樣再遇到需要開發相同或類似的樣式，就可以直接拿過來使用，而不需要再從頭開始寫，它在一定程度上提高了前端開發效率。

那麼UI一緻性工程又是什麼呢？它和前端代碼組件化有哪些差别呢？

前端代碼組件化，通常隻涉及開發側，不涉及設計側，而且它的主要目的是提高開發側的效率。UI一緻性工程，可以粗略地認為是對前端組件化的一個比較大的升級，它不僅僅關注開發側，也關注産品設計側，它的視角是整個研發過程，自然它的目的也不再是單一的提高開發側的效率。

UI一緻性工程，更為重要的命題是：如何保持UI的一緻性。在多業務線、多場景、多渠道多終端、多部門多項目團隊之間，想要保持UI上的一緻，向公司内外部用戶傳達統一的視覺風格和品牌标識，對于産品經理和設計師來說是一件看起來太過于奢華的夢想。它的成本極高，以至于似乎遙不可及，單從作為視覺源頭的設計師來說，對于設計規範的管控和遵從就已經顯得力不從心了。在這個背景之下，UI一緻性工程應運而生。

想要保持UI的一緻性，UI一緻性工程的重要使命便是：設計規範的統一貫徹落實。這個落實，既包括設計團隊的落實，也包括開發團隊的落實，甚至也可以将産品團隊包括進來。

設計團隊通過UI一緻性工程保障設計規範能夠很好地貫徹落實的手段在于：設計的組件化和設計資源的管理與限定。UI一緻性工程首先的任務便是将設計規範進行設計組件化和設計資源化。通過創建設計側組件，并在設計團隊内分享複用，既提高了設計效率又避免了無效創新，以達到設計上的統一。通過設計資源化，使整個設計團隊保持統一的設計風格，減少誤用、濫用，以保持體驗的一緻。

開發團隊通過UI一緻性工程，不僅僅将之前沉澱的前端代碼組件更加規範，還包括了設計資源的規範代碼。通過對組件代碼和資源代碼的複用，使UI設計更加有效地落地，提升開發還原度，無需再重複走查、頻繁回歸，形成設計-開發流程的閉環，提升複用性與開發效率。

UI一緻性工程通過全局變量和組件關聯變量的提取，并在設計側和開發側的定義，使快速實現視覺優化、設計升級和更新的成本大大降低，使一鍵變更主題、适配Dark Mode等難以實現的需求變得非常easy。

設計組件和開發組件之間的便捷關聯，對于後續項目上實際的設計開發工作起着舉足輕重的作用。我們完成了設計的組件化和資源化，也完成了組件代碼和資源代碼，但若沒有一種便利的在設計稿上找到對應代碼片段的關聯方式，就會面臨功虧一篑的境地，前面實現的越多，後面查找起來就越費勁。一個能在設計稿中對設計組件和設計資源中的元素進行自動标識和代碼關聯的協作平台必不可少，是UI一緻性工程中至關重要的一環。有了這個平台，開發人員可以在設計師輸出的設計稿上直接看到哪些使用了已經創建好的組件和資源，并且點擊即可直接查看到對應的組件代碼和資源代碼，極大地提高了開發對于組件代碼和資源代碼的複用效率。

二、UI一緻性工程對傳統企業的意義

傳統企業對産品體驗的重視程度不足，又缺乏産品和設計方面的專業人才，在這個大背景之下，現有的産品體驗不盡人意。長期注重功能開發，為了滿足業務的快速上線，很難去落實統一的設計規範，在開發過程中由于UI缺乏标準導緻的問題不斷凸顯，主要表現在三個方面：

• 由于UI缺乏标準化設計規範或者落實設計規範不力，在不同産品/系統及不同開發語言平台上設計風格不統一，用戶體驗不一緻，同時設計資源與代碼均缺乏統一管理手段，無法實現積累沉澱，無法适應新的開發需求。
• 組件代碼實現碎片化，存在多次開發的情況，質量難以保證，各端代碼API不統一，維護拓展成本較高，變更主題、适配Dark Mode等需求難以實現。
• 重複走查，頻繁回歸，每次投産上線均需驗證開發質量與還原度效果，修改後還需要再次确認，由于效率比較低，造成為了提升産品體驗而做的工作性價比比較低。

産品經理進入傳統企業後，首先承擔起的便是産品體驗優化的重任，但一段時間以後就會逐漸發現，肩上的擔子分解下來的層層任務隻有自己那部分可控的任務能順利如期地完成，然後就會遇到難以推動的困境。提出的産品體驗優化相關的需求總是被功能性的項目需求一拖再拖。即便是領導親自下發了體驗優化的任務，也難以抵抗現有的KPI評價體系和業務與開發團隊的慣性思維和習慣性動作。

結合傳統企業業務經營場景與實際需要，缺乏有效提升産品體驗的體系化工具，可能是導緻産品體驗問題一拖再拖、一直得不到解決的關鍵所在。UI一緻性工程，或許是産品經理可以依托的一杆旗幟。

産品經理借助UI一緻性工程，不僅可以解決自己所負責産品/系統的産品體驗問題，還可以将其平台化，供其他項目團隊使用，這對于有比較多中後台系統的傳統企業來說，更是一個整體性的UI解決方案。傳統企業直接面向客戶的科技産品，尚且可以通過人力的單獨密集配置、産品體驗的重視程度、敏感度與開發還原度的提升等方式使之達到一個尚且不錯的水平，但對于中後台産品/系統的體驗問題基本上沒有辦法來集中解決、整體提升，更多依靠的是每個團隊自己，除非依靠UI一緻性這樣的整體性工程。

抛開所處的企業環境與人力資源境況之外，單說UI設計與設計規範落實，也該提升一下效率了。一個頁面一個頁面地畫、一個元素一個元素地設計，雖然每個設計師也會有一套自己的設計庫，但這遠遠不足，依然存在很多環節可以改進和提升的地方。設計專業基礎的原子、分子、組織、模闆、頁面的原子理論，也該将設計規範按照這個理論進行組件化和資源化了。說起這一點，不得不感歎，開發側在分享、複用、協作這些方面比産品和設計側要走得靠前一點，在時間上、在廣度和深度上，都是如此。或許，這是因為産品與設計側一直強調的是創意、創新，開發側更務實，強調的是效率、工期吧。

說了這麼多，其實UI一緻性工程歸根到底解決的是兩個方面的問題，一個是産品體驗的一緻性，一個是研發效率的提升。我們一定要在UI一緻性紛繁複雜的大工程裡始終清醒地認識到這一點，始終緊緊抓住這兩個關鍵作用，不能自己迷失了方向。

這裡的研發效率既包括開發側的效率，也包括設計側的效率，也可以包括産品側的一點效率。這裡的效率，更多的是體現在UI設計師和前端開發的工作效率，以及兩者需要相互配合完成的協作效率上，如開發還原度與UI走查。由于産品經理最主要的工作瓶頸不在于産品原型的産出，所以說是能提升一點效率。除此之外，産品體驗的一緻性和研發效率的提升也存在一點内部邏輯關系，這個邏輯關系便是：UI一緻性工程首先要達成研發效率的提升，才能進一步促使完成産品體驗的一緻性。這一點，在傳統企業裡是非常重要的，任何脫離開發隻談産品及體驗的改善都不具有足夠的吸引力。

UI一緻性工程的建設，可以幫助設計團隊提升設計效率、沉澱設計語言以及減少走查負擔；讓開發同學面對新項目時可以專注于業務需求，而無需把時間耗費在組件的編寫上；減少測試同學工作量，保證控件質量無需頻繁的回歸測試；幫助業務同學和産品經理提高版本叠代效率及版本需求吞吐量，提升業務的快速拓展能力。

雖然UI一緻性工程在落地上會增加開發同學不少的工作量，推進一緻性建設也是一個艱難的工作，由于成本較高，且無法量化評估收益，很多團隊最終未達到預期效果，但一旦有效運作起來後，團隊将獲得豐厚的回報。

三、UI一緻性工程之外

有了UI一緻性工程以後，是不是單純依靠它就能解決所有問題了呢？當然不是。

組件化與資源化雖是提效和統一體驗的好方式，但在設計過程中我們也不能過度強化組件和資源的使用，喪失了設計創新的可能性，而是通過對産品價值的深入認知、對設計方案的全局審視來進行決策，以實現兩者間的平衡和價值最大化。

專欄作家

厚厚，厚厚的語和文，人人都是産品經理專欄作家。多年互聯網和傳統企業的跨界産品經理。

本文原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部