從藍圖中可以看到，中台是由標準規範，共享業務服務，技術平台服務，平台管理組成。

我在公司中屬於用戶體驗部門，能做的就是標準規範（a.k.a 設計規範）。單單把標準規範拿出來推，它的力量是單薄的，但是把標準規範放在中台里，去推中台這個方法論，它的力量是強大的。

好了，怎麼去推動呢？先想想，我們需要哪些人的支持，能給他們提供什麼價值。

我把推動的過程，分為幾個階段。

一，證明標準規範。

1. 設計規範的內容

元素--------控制項--------組件--------頁面--------業務類型

元素：字體類型的、主色輔助色、按鈕的觸發效果（默認，懸浮，點擊，已選）……

控制項：用元素組合成的：按鈕、選項框、下拉框、進度條、icon……

組件：用控制項組合成的UIKIT

頁面：用組件+頁面布局組合成各種層級的頁面

業務類型：用一系列頁面&它們之間的跳轉關係，組合成某種業務線的模版

展現出來的設計規範，可以直接從組件+頁面開始，比較實用。能經受住考驗的設計規範，必定是可溯源，自成體系的。元素、控制項、受欄位類型、後台支持、用戶習慣的影響結果一定要記錄下來，也是為後期完善組件庫，頁面庫做準備。

2. 標準規範的來源

• 對於單個系統來說

當系統設計到前期的時候，可以邀請資深的用戶&業務提提意見，但沒必要邀請初級用戶進行驗證。這個時候根據經驗來形成系統雛形。

當系統設計到中期的時候，由於原型來源於不同的產品經理/交互設計師，同功能會出現不同樣式。這個時候就可以從業務中提煉出來（控制項，組件，頁面，流程等）再形成標準：對於同樣的功能，就用統一的樣式。解決了體驗中的「一致性」問題（以及由於不統一規範，而引發一系列的問題：學習成本高、系統臃腫……）。還可以提高開發的效率。

當系統設計到後期的時候，可以邀請用戶，去驗證整理出來的樣式、統一出來的標準是否能滿足用戶的習慣，需求。這個過程是持續而且長久的，各方面的意見就是在增加設計規範的價值和延展性（持續增加價值）。

• 對於多個系統來說

B 端的用戶，很有可能是同一批人群，對應同一套用戶習慣。但他們使用不同的系統就要學習不同的操作習慣，增加了學習成本，也會降低用戶的工作體驗。

在公司內部中，業務的開展往往涉及到N多個系統。對於業務方來說，只想快速實踐業務，驗證一下是否能到達效果，兵貴神速。但是往往要開展一個新的業務形態，需要搭建平台，搭建C端應用，搭建資料庫等基礎建設，需要大半年的時間才能見到一點點業務的落地效果。隨著企業的發展，業務的增加，B端系統數量也持續在增加，這個時候不同平台、系統之間的重複造輪的情況是十分常見的。如果企業內有一套規範（有且只有一套），就能減輕用戶的學習成本，提高工作效率。減少開發團隊的重複勞動，縮短新業務的落地時間。

• 適用的系統類型

B端十分適用，C端不完全適用

規範是為了解決效率低，不統一的問題，這種問題在B端常見，C端因為本身迭代改版快，所以也沒太多內容需要規範（好比就做了一個app，裡面的功能很少有復用，那這時候想做規範就很難推）。

設計規範的目的：一，統一標準 ；二，提高效率

再加上一些方法論的指導形成的統一約束就是規範了。

3. 設計規範的價值

設計規範本身就是對交互設計工作的提煉，交互設計工作都是承接B端產品經理的需求。而B端的需求本身就代表了解決業務問題的價值。所以說「怎麼去證明設計規範的價值」，有兩個方面的價值：

一、設計規範的內容對於業務的價值，這就需要持續與業務、用戶體驗相結合驗證，迭代升級設計規範。側重點是：全面收集業務場景，沉澱經驗，提升&統一體驗。

二、是設計規範，中台的方法論對於it的工作流程中，可以在拉通資源，統一標準，提升效率，減少重複造輪上實現價值。屬於公司內部工作方式的業務變革。側重點是：各方團隊&領導層對於此方法論的認可程度 ；作為方法論的推動者，要根據自身能調用的資源去推動各方。

二，引導&滿足多方需求。

如果要達成合作，推動方案，那麼肯定要與對方細化工作，排除顧慮，滿足對方的需求，引出對方的期望，那麼對方就會願意幫你，形成共贏。

• 標準規範是給誰用的？

以往是叫設計規範，針對一個系統，通常給體驗團隊中的交互設計師，視覺設計師用，以提高體驗質量。完成設計之後交付給開發人員，就形成了框架。

當設計規範從一個系統上升到所有系統，從一個項目上升到所有項目，那就必須得有個統一的標準規範，它的作用不僅僅是規範設計，也是經驗知識，項目資料的沉澱，記錄了現有資源的技術實現能力。凡是參與系統的人都可以稱之為設計者，標準規範是給設計者用的：

1，規範的開發團隊，與選用規範的開發團隊（標準規範的選用與建設）

系統的開發團隊在項目的初期往往會選擇一套開發框架，主要會考慮到以下因素：

• 技術：在可實現的能力範圍內；
• 體驗：能保證體驗質量；

再看看行業內，已經有很多現成的規範/框架。那麼哪些方面的亮點會影響選擇呢？

• 技術

新系統處於開發階段的時候，為了保證項目上線，首先考慮到的是規範/框架的可行性，如果前期技術團隊沒有選擇你的框架，那麼後期再用上的可能性不大。從適用性來說，用戶會看技術框架是否滿足業務形態，對老系統的適應性和對新系統的支持。

所以需要展示出：

1. 全面：讓別人覺得你的很全面， 很實用。這方面在下面【體驗】一節會詳細講到。

2. 可參與：留給用戶修改，新增的空間，讓別人在你現有標準規範/框架中找不到想要的內容時，允許用戶自定義一些新型的樣式（不屬於標準規範中，但是能讓其他用戶也用上）。

這部分後期將會成為補充 標準規範/框架 的實用素材。

• 體驗

在上一階段提到過，同一批用戶必定是有類似的工作習慣，這與其所依附的組織文化有直接關係。如果沒有規範進行約束和記錄，沒有對用戶意見進行分析管理，容易造成系統更改頻繁，從而衍生出新問題。

標準規範，代表了用戶體驗部門對體驗的最高要求，以及在平時的工作中積累的經驗。體驗的需求，往往是浮動的，但是有些成功的案例是可以沉澱下來，有些個性化的問題是可以少數服從多數。標準規範需要在保證業務能順利進行的前提下，提出前瞻性的要求，再根據實際的技術支持情況，針對不同案例設計出不同方案。

上面提到過，在展示框架的時候，要讓別人覺得很全面，很實用。

1. 全面：全面&精確。如果說規範是把之前的設計交付物的總結，是從其他的規範中借鑒過來的總結，這樣做成的規範是不成體系的。我認為給用戶感知的「全面」，不是行業內，設計樣式的全面。而是規範的內容夠精確，組合起來體現在業務中的全面，讓用戶感覺到，用你的規範能立刻適應業務，而且實現的方法不止一種，讓他有選擇。當規範比較豐富的時候，做好說明（適用範圍）很重要，哪些是急需實現的，哪些是PLAN B。
2. 實用：指的是規範中的組件，頁面已經在上線的系統中實現了價值。（把資源用在能實現更多價值的上，對所有開發團隊都是有利的）

所以說規範全面，UI精緻，能結合業務組織文化，減少學習成本，又有參與空間的規範，是極具吸引力的。畢竟B端系統的考核指標，應該是都是圍繞系統建設、效率提升、工作能力進行指標構建，所展現出來的方法論，是可以快速學習。當用戶與規範，形成互補關係，就能長久地形成共贏。

2.產品經理

• 直接套用規範來輸出原型，無需經過設計師即可完成需求
• 看出目前的業務線/其他同事的業務線的進度。

3.項目經理

• 從規範可看出目前團隊需要調配的資源情況，可以精確地調配資源，以及規劃未來的空間。

4.新用戶

• 入職之後，通過規範能快速上手業務。

4.業務員

• 提供最優的系統，拉通信息，縮短業務上線時間，快速支持業務變革。（規範越豐富，落地時間越短）
• 記錄行業經驗。

5.用戶

• 學習成本：不用學習多套系統，減少學習成本。
• 意見反饋：統一收集意見（這些意見能進行數據分析、製作用戶畫像），對規範進行升級（更新個別組件就能滿足用戶要求）。

以上就是推動中台的一些想法，在平時工作中，我是先從一個大項目開始試點，取得成功之後再進行推廣。在其中如果得到領導的支持當然最好，如果沒有，也可以從「與前線人員合作」入手，再根據實踐情況採取對應的戰略，最終取得共贏。

在此感謝各方對於我工作的支持。

要特別感謝的是李老師，給予我啟迪，讓我受益良多。