在B端產品設計過程當中，好的設計規范能夠有效地幫助設計師提高工作效率。本文詳細介紹了落地設計規范，將之有效推廣的方法。最后對于設計師個人成長與發展方面，在制定及梳理設計規范設計方面提出了建議。希望能對你有所幫助。

前面我們聊了B端設計規范的前面五個部分，包括：設計規范的基礎概述、如何開始整理設計規范、大廠設計規范推薦、詳細的創建設計規范方式及注意點、組件庫的內容；

(資料圖片僅供參考)

那么接下來，我們來聊聊最后兩個部分，關于設計規范如何落地，以及在推廣設計規范期間，可以提升設計師的哪些個人能力？

一、設計規范落地不了的原因

組件擴展性弱：有時候設計師做出來的組件雖然看著很好，但是實際上使用時，適配效率很低，用組件去擴展和重新做的效率差不多。

脫離業務：

大部分時候設計師手中都有任務，于是這個任務就落在了相對不是那么忙的設計師手里（一般是新設計師），但是新設計了解業務相對來說是不夠的，做出來的東西就像是是空中樓閣，拋開業務談設計規范的都是很難落地的。

缺乏開發思維：

設計師不了解開發的實現方式，可能會做出來以后，開發較難實現，然后開發也就不會做。

缺少開發資源：首先，設計規范的作用是巨大而延遲的，不能即時產出很大的價值，另外一方面，設計規范的落地會增加開發工程師很多的工作量，且無法量化成果。這也導致很多時候設計師無法爭取到足夠的開發資源來做這件事，所以，很難導致達到預期的效果。

二、怎樣更好的落地設計規范？

設計師需要更加全面的了解產品及業務流程。

研究用戶：

前期需要做好用戶畫像，弄明白產品的目標用戶的差異，不同用戶的使用場景。只有弄清楚各個角色的關系以及功能設計的邏輯，具體用戶年齡，解決什么問題，才可以產出更符合用戶需求的設計。

研究業務：

如果是新的產品，那就需要去詳細的看類似的競品的功能及業務流，并且了解公司產品的定位及方向，所以就大致清楚設計的大方向。

研究產品：

系統整理產品情況，最好是做思維導圖形式，可以更好的梳理同類型的產品功能及組件，也就能更好的提高組件的復用性。

在制定規范前，需要明確產品中主要有哪幾種分類，將最基礎的分類定義好方便后續針對分類內容進行整理。

注意：B端產品與C端產品既有很多共同性也有很多很大的差異化，可以借鑒C端的設計規范，但是切忌生搬硬套C端的設計規范。

三、如何推給pm、推給設計團隊、推給研發團隊

團隊溝通其實是一門藝術，那需要如何做呢？

首先，寫一份設計規范的價值的提案給領導，爭取到足夠的資源，包含設計資源、開發資源。如果領導的主導參與，那這個事情就好推動多了。

然后，把設計規范的設計工作交給熟悉業務的設計師來做，通過業務提煉復用率高的典型元素，優先開發，最大化投入產出比。

搭建設計規范和我們日常處理工作需求類似，并非輸出一份文檔就結束了。我們還需要將做好的設計規范推廣給各個職能部門的同事包括設計小伙伴，PM和開發小伙伴的團隊內外，并且需要得到團隊內的一致認可才算是初步完成。

召開專門的設計規范會議，以清晰明確且有效的方式把詳細的內容傳達給各個相關人員，在一致認可規范的情況下，以達到內容的傳達到位。同時，這個時候，就可以依據開發人員的反饋，做落地的修改規范文檔。

利益點：提升協作效率，減少工作成本

在啟動設計規范的整理之前，內部宣講讓PM對于設計規范的搭建已經有了一個基礎的概念。然后爭取到更多的開發資源。否則PM不會分配資源給予時間去搭建整體的設計規范。

可以從提升PM與設計的效率和降低原型搭建成本作為切入點，通過組件庫以及通用模版的搭建，PM只需要極低的成本學習一下組件庫怎么使用，即可搭建高保真的原型界面。甚至完善好組件庫后直接不需要設計的參與，開發通過原型組件庫搭建頁面。

利益點：提升設計效率，減少人力損耗，保持體驗一致性

設計規范一般由團隊內小伙伴共同制定，基本上已經對規范的優勢達成共識。因此主要講講如何更好在團隊內部使用規范。

團隊設定主要負責維護的設計人員，其他人員在設計時候，通過Sketch Library 共享組件庫可以直接調用組件，并建立更新日志規范項目流程提升效率，定期維護的時候其他人員統一告知負責維護的設計人員，統一定期修改更新升級維護。

利益點：封裝組件，更少的更改，提高驗效率，縮短研發流程

需要研發團隊認可設計規范，前期前端的參與是必不可少的。

在制作規范時設計師了解了前端開發的一些簡單原理，前端開發也能及時了解設計師的想法，大家不再是各司其職而是串聯起來共同協作，當規范確認下來前端就不會頻繁改動組件，而且在有限的項目時間中。設計規范的統一極大縮短了設計和前端開發所需的時間，為后面的項目爭取了空間。

一套完整的規范包含內容是非常多的，難以在1個版本迭代里面修改完。

因此可以采用敏捷開發的思想，小步迭代快速推進，將設計規范的覆蓋放在每次迭代過程中。設計師需要將自己作為設計規范這個項目的產品經理，針對現有的需求進行拆分，并排出優先級分版本迭代進產品里面。

可以依據從大到小的原則進行優先級排序。對產品設計風格影響大的先排，影響小的后排。

比如：設計準則＞框架布局＞組件＞控件＞場景。

設計規范的制定不單單是對于設計師，在嵌入版本里面要隨時與產品和開發多溝通，以便達到更好的落地效果。

四、最后：關于設計師的個人成長

接近1.5萬的文字梳理，感謝你看到了最后。接近尾聲了，制定及梳理設計規范對于設計師來說個人成長有哪些方面呢？我個人覺得可以從這幾個方面來說；

通過整理規范，需要收集目標用戶，使用場景、前期調研、產品功能梳理等眾多資料，這期間我們需要去發現信息以及整理信息。龐大的信息收集，那對于個人的收集整理信息的能力是一個很好的提升，同時對產品會有更全面的認識。

將收集好的信息進行分類整理，這要求需要一定對邏輯性。在設計基礎框架時合理對分類可以協助我們處理好每個控件對層級，這項能力無論實在工作還是日常中都有著巨大對好處，可以幫助我們從一堆繁雜的事物中“提綱挈領”，換言之就是“化整為零”，做減法，提取出最關鍵對因素。

將信息歸納整理好后，需要對全局進行思考，全局的設計及交互都需要考慮到位，比如什么情況下適合跳轉頁面，什么情況下適合給與用戶彈窗。

大體符合什么交互原則。除了對大體交互需要考慮到位，細節上也不可以忽視，比如異常情況，極端情況該如何去處理，組件之間該怎么去配合等。在日常工作中我們也可以逐漸有意識去培養此類技能，對項目全局思考的越多，那么對整體項目對把控能力也就越強，與他人合作也會越顯得專業。

在整個推廣設計規范的過程，就是提升溝通表達能力的過程。另外，整理設計規范時，難免會遇到模凌兩可舉棋不定的時候。此時可以尋求向上或者向下的資源尋求幫助，具備良好的表達能力能迅速幫助我們將問題闡述清楚，表達能力是設計師需要具備的重要技能之一。

我們每次在求助他人或向他人匯報，都需要在全面復盤問題過后做到心里有數，將問題自己復述一次是否有漏洞或者沒考慮清楚的地方。長此以往你表達的事情會更清晰，別人也更容易聽懂你說的事情快速理解內在邏輯，那么說服別人推動工作的難度也會越小。

同事對自己的邏輯思維，表達能力都是很好的鍛煉。這里總結了幾個工作中與上下游溝通的小技巧希望能幫助到小伙伴們：

在開始與他人溝通之前我們需要搞清楚我們溝通的原因與對象。

原因里面包含：

對象里面包含：

當然在溝通時還需要考慮方式和語氣，這些都需要好后斟酌。如果遇到情緒不太好的開發，這個時候反倒我們更不能將情緒激化，一般這些情緒化對態度過一會都會消散，可以采取冷處理等情緒過后換一種方式溝通看看。

五、總結

很高興你看到了這里，努力成長的你并不孤單，最后我們來復盤一下吧～

文章開頭我們梳理了設計規范的概念理論，包含：設計規范的常規理論概念、為什么要制定設計規范、為什么要制定自己的設計規范，什么階段適合建立設計規范。

第二部分，我們在開始準備整理設計規范要明確知道設計規范包含的框架內容。

第三部分，整理了現在市場上的常規的第三方組件庫，文章末尾有大廠設計規范領取喲！

第四部分，詳細的梳理了b端設計規范的框架內容及注意點。

第五部分，基于組件庫在設計規范的重要性，單獨把組件庫拎出來詳細分析了組件庫。

第六部分，將規范當作一個項目去執行落地，設計規范的用戶群體就是團隊的內部人員，讓用戶高效獲取信息是規范本身存在的意義，在設計規范時需要及時溝通確保落地實現，并針對用戶角色不同進行定制。

最后，分享了一下做設計規范對個人的一些能力提升，包含收集信息能力，歸納總結能力，全面復盤能力，表達能力，溝通能力等。

本次的這里就結束了，希望可以對大家有幫助。

本文由 @三原設計 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash ，基于 CC0 協議

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