基礎的設計規范，包括基礎組件、配色規范、頁面模板、頁面間距等底層基礎內容，在基于我們對設計規范有一定程度的了解下，是可以湊湊時間快速做出來的。本文作者分享了用4天時間構建一套可用的設計規范的方法，希望能給你帶來幫助。

我最近指導小伙伴在做和自己也同步在深思的事情，有關“如何快速輸出一套可用的設計規范”的事兒。

關于設計規范是什么，一定不用我多說你也知道，它是每一個產品必不可少的東西（C端B端都需要）。但設計規范上不封頂，既可以延伸至設計體系，也可以大到設計生態，當然反向的，也可以只是一堆組件。

今天，我不說設計體系、設計生態，因為一上升到這個高度，可不是快速能做的，需要好好規劃、長期沉淀與執行，我的新書，會詳細講到這部分。

今天，只說基礎的設計規范，包括基礎組件、配色規范、頁面模版（少量）、頁面間距等底層基礎內容。這些內容，在基于我們對設計規范有一定程度的了解下，是可以湊湊時間做出來的，大約4天的樣子。

當然，這里不包括評審和反復調優的時間，只是我們去做的時間。

那4天怎么用呢？

第0.5天，團隊內部選擇一套開源組件庫。

第1.0天，著手了解開源組件庫設計邏輯。

第1.5天，了解服務產品的調性，及明確設計規范框架。

第2.0-3.0天，依據前面的準備，修改開源組件庫相關屬性、調整與設計組件，及核心搭建頁面模板。

第4.0天，整理修改點，并自我反向補充和調整。

01 第0.5天

要做產品了，沒有設計規范怎么行呢？所以，得趕緊準備起來呀。找上團隊一起來看看使用哪個第三方開源組件庫合適（牢記，如果自己從0到1構建，那是4天完不成的哦）。

我之前梳理過《B端常用9大開源組件庫集合（必備收藏）》這篇文章，里面提到了非常常見與常用的組件庫。團隊選哪個組件庫都沒關系，主要是要符合產品、業務、技術等發展的需求。

比如，團隊一直就用Ant Design的，那么新產品使用Ant Design在技術架構上就比較好，避免多技術棧導致組織內部相關產品無法良好的集成。

再比如，團隊希望產品出來的視覺效果是比較好的，那么可以用ArcoDesgin。喜歡vue架構的，就選element，其的vue能力比較成熟。

02 第1.0天

完成了開源組件庫的選擇后，就要簡單了解下開源組件庫的設計邏輯了。

由于我們一般使用開源組件庫，不會對其交互進行大改，而是只對其可視化部分進行調整，如顏色、間距、字號大小、容器方圓角等。

因此，我們需要對樣式屬性的構成簡單進行了解，這里的簡單是指能服務于你構建設計規范即可，更深入的可以等后續在慢慢了解。

比如，本次規范決定只調整顏色，其他一概先不動，那么就先對開源組件庫的色彩屬性進行了解，看看如邊框這種的顏色都分別賦值到了哪些組件上。

如：

• border-color-base賦值到a、b
• border-color-light賦值到c、m
• border-color-lighter賦值到d、r
• border-color-extra-light賦值到j、l
• border-color–dark賦值到v、k

大致了解清楚后，那么優化起來也相對方便些。

03 第1.5天

接下來，就要展開做了。那么在做之前，還得了解服務產品的調性，不同調性決定了產品的主題色、插畫風格等內容。

比如，醫療系統適合綠色，給人專業、安全的感覺；也適合橙色，給人溫暖、貼心的感覺。銀行系統，適合紅色，給人豐收、美滿的感覺。人工智能類產品適合科技藍。

確定主題風格后，便可以展開主題色的調整，以及圍繞主題色的其他色的調整。當然，產品調性也會影響組件方圓角等內容。

接下來，需要構思下實際做的時候，應該如何一步步展開，即明確設計規范框架。切記不可一上來就咔咔咔開干，這不僅說明我們思路凌亂，也會讓后期返工嚴重。

我的經驗是，在真正動手之前，先把具體要做的事情的框架搭建出來，比如，是框架A這樣子呢？還是框架B這樣子？當然，這么做并不是無緣由的，而是要在限制條件下（如時間、技術、能力），盡可能最大化價值，包括設計、產品、技術等方面。

不過如果框架涵蓋范圍一旦太大，那可能4天完不成，所以我們要根據實際情況調整。

04 第2.0-3.0天

一切準備就緒，就要開干了——修改開源組件庫相關屬性，及核心搭建頁面模板。

這里屬于細節部分，需要有修改思路和耐心，一點點的改下去。遇到一些需要驗證的點，需要反向去驗證下。

比如我們覺得開源組件庫某顏色不合適，那么到底要怎么改呢？一方面需要盡可能使用開源組件庫中給出的顏色屬性范圍，另一方面要看下搭配在我們的產品中效果是如何的，切不可直接改個自己覺得好看的顏色。

還有，搭建頁面模板，適合把最最最重要的先弄了。比如頁面模板有表格頁、詳情頁、工作臺、結果頁，那是不是這4天里面就把它們一股腦兒都做了呢？其實不然，我們適合迭代去做，先將非常高頻的做了，再做低頻使用，但對全局性來說，也比較重要的界面。

05 第4.0天

到這里，基本本次要做的內容都做了，接下來就是要整理我們在開源組件庫上的修改點，并自我反向補充和調整。這一步有助于給到團隊干系人成員時，他們能清楚設計規范的現狀和原狀態，那么他們在使用中也會心中有數。

我清晰的記得，小伙伴給我看了完成的設計規范后，我就給他提了一個小優化點：“給一些常用顏色補充一個對應的應用庫?！比绱?，協作者就可以知道顏色都用在了哪些地方，而不是對著一堆顏色不知所以然。

后來他告訴我，這個太有效了，雖然他沒有做完整，但有了初稿，也可以解決一部分問題。

06 最后的話

我經歷過從0到1搭建一套屬于企業維度的設計規范，賦能企業級產品使用。

因此，如果依賴開源組件庫構建設計規范，相對來說還是輕松一點的，不論是在時間、精力、設計、技術等的投入上。

記得從0到1構建的時候，我們需要考慮每個組件的交互方式，及關聯組件的統一交互模式，這是一件費腦費力的事情。還要考慮使用者的基本特征（年齡、習慣等），他們在消費設計規范的時候，是處于什么場景，哪種狀態。

好啦，今天就和你聊到這里了，希望今天分享的“4天構建一套可用的設計規范”能給你帶來一些啟發，我們下周見啦。