傳統企業,更需要UI一致性工程

1 評論 6921 瀏覽 23 收藏 14 分鐘

有時候一些產品的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設計與設計規范落實,也該提升一下效率了。一個頁面一個頁面地畫、一個元素一個元素地設計,雖然每個設計師也會有一套自己的設計庫,但這遠遠不足,依然存在很多環節可以改進和提升的地方。設計專業基礎的原子、分子、組織、模板、頁面的原子理論,也該將設計規范按照這個理論進行組件化和資源化了。說起這一點,不得不感嘆,開發側在分享、復用、協作這些方面比產品和設計側要走得靠前一點,在時間上、在廣度和深度上,都是如此?;蛟S,這是因為產品與設計側一直強調的是創意、創新,開發側更務實,強調的是效率、工期吧。

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

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

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

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

三、UI一致性工程之外

有了UI一致性工程以后,是不是單純依靠它就能解決所有問題了呢?當然不是。

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

專欄作家

厚厚,微信公眾號:厚厚的語和文,人人都是產品經理專欄作家。多年互聯網和傳統企業的跨界產品經理。

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

題圖來自 Unsplash,基于 CC0 協議

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 觀點很明確且論證透徹,傳統企業,更需要UI一致性工程。

    來自廣東 回復