在日常工作中，您是否也有過因為沒有規范的文檔，而出現的文件找不到、或交接時信息錯漏等頭疼現象？本文將分享一些關于完整的設計規范系統的搭建方法，（主要針對于多端產品）希望對您有所幫助。
  1、建立背景
  2、“設計規范系統”是什么?
  3、如何建立
  4、如何使用
  首先，我們需具體分析目前所存在的問題方能對癥下藥。最直觀的方法便是從其使用性、內容結構兩個方面進行分析：
  1.1.使用性層面：
  各端規范大多是窮舉組件，少量標注，極少附有使用說明；每個組件的撰寫結構、順序不一致；每份文檔格式相對獨立；對于需同時進行多端設計的同學有可能會出現混亂；
  1.2.內容結構層面：
  各個平臺的風格差異過大；
  大多屬于歷史遺留問題，在初期規劃時，對產品調性的把控不周，致使風格差異甚大；
  組件的統一性、可復用性低；
  每個組件幾乎獨立存在，組件間缺乏聯系，各端倍數不明確，導致在多端產品線上，無法快捷跨平臺適配；
  團隊協同效率低；
  經常找不到文件，需要老同事幫忙；或是文件版本較前難以追溯；再者工作交接時，新同事很難快速了解；
  可持續發展性弱；
  研發團隊沒有建立組件庫的意識。大多數組件樣式單獨寫死，無法統一修改，全局改動需耗費較多成本。這也是設計師經常會遇到一種現象，僅需要全局改動某一個按鈕樣式，或者某一個組件樣式時，得到研發同學給到的反饋大部分時候都是“這個實現起來很困難”、“這個不好做”...
  個人工作效率低；
  調用資源時，經常需要去翻查以往的源文件然后復制粘貼到新文件里面，遇見文件大的可能還要卡上幾次。這種重復又無任何意義的操作著實浪費時間；
  缺乏文件管理觀念；
  文檔存儲不統一，歷史版本無整理；切圖命名不規范，增加開發陳本外。
  等等以上，這些都是日常得不能再日常的現象了。這些問題在產品快速發展的過程中將更加暴露的徹底且不可逆。如果您希望設計越來越好，值得信賴，就需要讓我們從頭開始，建立一份完整的設計規范系統來幫助我們的產品在成長中呈現規律且清晰的生長模式，可控制、可迭代。
  那到底“設計規范系統”是什么？需要具備什么特質呢？
  “設計規范系統”指的是用于推進各端的設計規范格式統一而建立的規范系統。在設計規范的統一格式基礎上，能更加快速的進行多端設計語言的統一。主要運用于多端產品線規范。完整的規范系統需要具備簡單易懂、結構清晰、倍數確定、異同明確等特質。
  典型的多端產品大多包含觸摸大板端、電腦端、網頁端、平板端、移動端等多平臺組合結構。對于這類多端產品，日常中，最繁瑣最耗時間且最沒有意義的工作不外乎就是適配工作了。擁有一套完整的規范系統可以更加有條理的設計，也讓工作更容易。
  建立一個相對完整的規范系統需包含哪些部分？可以從建立原因提取出關鍵問題點來作為整個系統的結構框架。分別為：設計手冊、資源庫、產品實時文檔、命名&存儲規范、使用說明。
  2.1."設計手冊"
  設計手冊即是目前慣使用的視覺規范；又可細分為設計語言、組件庫兩部分。
  設計語言一般包括原則性的說明（產品設計原則、通用原則、內容策略等）以及視覺元素（顏色、大小、字體等）的基礎定義。組件庫則可按照組件類型劃分為通用、導航、數據錄入、數據展示、反饋六種類型。設計語言的“視覺元素”與組件庫是整個規范系統最基礎的規范部分，也是最核心的內容。
  2.2."資源庫"
  資源庫則可以理解為日常工作中的切圖池。按照切圖的類型以及日常工作中資源的調配關系，可分為圖標庫、圖形庫、組件庫三部分。資源庫主要作用于日常工作中資源的切換或調取。傳統的資源查找、復制方式過于繁瑣，資源庫一鍵更改的快捷方式可大大提高設計效率。
  2.3."完整文檔"
  完整文檔指的是線上版本的視覺稿全文件。一般分為（sketch）源文件或輸出標注稿兩種。源文件一般可作為后續多版本拓展、內部協同、工作交接等作用，標注稿則可為設計走查等提供檢驗標準。
  2.4."命名格式"
  命名格式指的是在規范系統中建立統一的命名標準格式。在這基礎上方可建立規范化的文檔管理模式。比如文件存儲、資源庫的切圖資源、樣式庫等。
  2.5."使用說明"
  使用說明即是整個規范系統的基礎使用法則說明?？晒┬率挚焖倭私猱a品的整體設計語言，或在團隊協作中起到統一基礎準則作用。通常需要羅列說明的內容有：整體的各端倍數關系、通用字號、通用列表等基礎屬性、共性。
  在建立之初，需了解并明確元素與元素、元素與組件、組件與組件、以及組件與規范系統間的關系。
  原子設計
  2013年網頁設計師Brad frost從化學中受到啟發：原子元素結合在一起，形成分子，進一步結合并形成相對復雜的生物體。
  而宇宙中的物質最小單位“原子”則是由英國化學家/物理學家約翰·道爾頓提出，原子是一種最后的不可分割的物質微粒。進一步說明，原子是所有物質的基本組成部分，分子是兩個或兩個以上的原子通過化學鍵組合構成有機物，最終形成宇宙萬物。并且在已知宇宙中的所有事物都可以分解為一組有限的原子元素（化學元素周期表）。
  于是Brad frost將這個概念應用在界面設計中并提出了原子設計方法論（Atomic design）。由原子、分子、組織、模塊和頁面共同協作以創造出更有效的用戶界面系統的一種設計方法。
  原子是最基本和最小顆粒度的單位，在設計中以“元素”的形式存在，例如：顏色、文字、圖形、線條等；分子是由原子排列組合構成，在設計中以“組件”的形式存在，例如：標簽、按鈕等；組織是由原子、分子排列組合構成，在設計中以“模塊”的形式存在。例如：列表等；模板是由原子、分子、組織排列組合構成，在設計界面中以“原型圖”的形式存在；頁面是由模塊填充了內容后形式，也就是設計中的“視覺稿”。
  原子設計理論最大的價值，就是為設計體系、組件庫的構建提供思路和方法。從抽象到具象、由局部到整體，層級分明，充分發揮了設計元素的可復用性，避免重復生產，為設計師構建組件庫提供了清晰的方法論指導。且可隨著產品的不斷迭代，只需改變某些原子、分子的屬性或組合方式，便可使整個體系同步更新，易于擴展和維護。
  建立的步驟
  在明確所有關系之后，便可確定規范系統的制作原則：從小到大，從大到?。粚ふ蚁嗤c，定義倍數關系。所謂從小到大，從大到小的意思便是，從每一個端到整體產品，再從整體框架到每一個組件。保證每一個端，每一個組件都在框架內。
  3.1.確定設計手冊的內容；
  也就是確定視覺、組件庫中哪一些元素、組件是需要歸納到設計規范里面的。設計界面中構成的最基本元素一般有：顏色、布局（尺寸）、字體、分割線、蒙層、圓角半徑、陰影等，2個以上排列組合即可組合成組件。
  組件庫則是由元素（視覺）組合而成的組件，或由組件與組件排列組合構成模塊；可根據組件視覺屬性、操作屬性劃分為通用、導航、數據錄入、數據展示、反饋六種組件類型。
  組件庫中“通用”是屬于最基礎的的組件，是最基礎的元素進行最簡單的組合且是設計中幾乎各個界面都會經常運用得到的組件。而數據錄入中的“輸入框”、數據展示中的“列表”從結構上其實更亦似通用的基礎組件。很多組件、模塊都是在這基礎上進行二次組合而成。
  3.2.確定整體內容框架結構；
  “視覺”即是確定“視覺”元素、“組件庫”組件的撰寫維度有哪些?！耙曈X”部分是屬于最基礎構成部分，每個部分都是獨特的元素，因此每個元素的撰寫維度也盡不相同?？筛鶕總€元素的特點進行分析撰寫即可。
  色彩一般應用于背景、圖標、文字、分割線等場景，根據其具體使用場景以及顏色屬性可歸類為三種類型：中性透明色、中性實色、產品級色彩體系。文本、分割線、蒙層等這類型元素的使用場景較為多變，采用透明色值可以更加融合于背景，屬于中性透明色。圖標、背景則常為具體色值，屬于中性實色。而產品級色彩體系則主要有產品的主題色、輔助色、功能色等帶有產品特色的運用。另外也需注意作為背景色的動作用色，即normal、hover、click、disabled、focus等常用狀態用色。
  布局通常包括設計尺寸、基礎布局。需了解并明確各端的基本尺寸大小，再根據各端使用特性或交互特性定義其基礎布局。例如各端界面排布方式、窗口大小等。
  字體一般包含字體選擇、字號標準、文字顏色等信息。大多按照各平臺系統默認字體為基礎字體。常用字號可按照使用屬性劃分為五個區間：說明、常規、標題、大標題、特大標題。同時，根據各端常用字號梳理和統一標準用字。另外還需考慮文字在深淺背景上的用色。
  陰影、分割線、圓角半徑、蒙層等屬性相對單一，可按照簡單的按照類型、使用場景進行分析。
  “組件庫”中的組件都是由元素組合而成存在一定的共性。大體可從組件簡介、使用場景、交互說明、結構解說、尺寸、出現位置、動作解說等這七個維度進行分解。需注意通用單一、多平臺組件的框架差異。
  3.3.定義命名格式規范；
  可命名的大致分為文件存儲、資源庫的切圖資源、圖層樣式庫等三部分。文件部分主要為源文件、標注稿的文檔管理，通常用按照項目劃分、版本號作為子目錄名稱即可；切圖資源類型主要有三類：圖標、圖形、組件，其中，圖標、圖形可根據類型、功能模塊、自身屬性定義命名格式，而組件的命名則可根據設計手冊的框架作為主結構再根據組件特性定義。圖層樣式庫的內容是有賴于設計手冊中的內容而存在的，因此可依據設計手冊的框架為基礎，再結合實際使用定義命名結構。
  需注意的是所有命名格式都需使用“/”符號區分層級結構，除文件命名外。層級結構命名可使用中文，不一定非要全英文，畢竟大部分人并不熟悉英文，特別是一些專業名詞，只要是合理并且能清晰展示框架結構即可。在樣式命名上，也可適當標注相關屬性，如字號或字階區間等屬性，方便快速查看信息。
  3.4.根據已確定的內容、框架梳理產品各端基礎規范（設計手冊），并統一呈現格式；
  “設計手冊”源文件需按照已定義好的框架分為6個模塊，分別為設計語言（視覺）、通用、導航、數據錄入、數據展示、反饋。每塊內容按照統一的布局格式排布內容。頭部為主信息，包含名稱、設計尺寸倍數等。所有內容從上到下、從左到右分類排序。左側為文本說明區域，例如使用說明、微交互等，右側有樣式展示區域。
  3.5.創建顏色樣式庫、文字樣式庫；
  根據已定義好的內容建立。顏色圖層樣式需注意深淺兩種背景用色，以及常用背景色的動作用色，即normal、hover、click、disabled、focus等常用狀態用色。
  文字圖層樣式則按照基礎字階表、深淺色場景建立樣式庫。
  需要注意的是，樣式庫中的字體選擇，需考慮各個平臺設備的字體差異，以及日常工作中調取組件時更替字體的便利性。在協同工作環境中，選擇一個較為通用的字體作為組件庫的基礎字體更能提高效率。多方案的文字樣式庫，其制作與維護成本都較高，并且在實際運用中，使用者未必能及時替換對于平臺的字體，再者這種多方案的組件庫、樣式也違背了規范系統的初衷。
  在無法制定多方案樣式庫的情況下，只能提取各平臺共性進行折中選擇。眾多平臺設備中，IWB、android、win、web等慣用于Microsoft YaHei；IOS、Mac則是蘋果系，PingFang SC。而內部產品所承載的平臺大部分是IWB、android、web、win等平臺，再者IOS、Android共用一套視覺、Mac、win也共用一套視覺，則可視為使用Android、win為基準，故定義Microsoft YaHei為基礎字體。
  另外，需考慮當作為文本按鈕時的顏色應用是如何（normal、hover、click、disabled、focus狀態的顏色應用）。以及對齊方式、段落格式，目前sketch的文本樣式在實際應用中是沒辦法編輯文字的對齊方式、粗細、行高等屬性，所以需要把各個所需的文本屬性單獨建立為樣式組件。
  最后，考慮到實際的使用場景中，使用頻率較高，或者子級內容較為龐大，又或者子級多且內容單一，可以適當調整樣式的命名結構。例如，文本顏色，在實際的檢索中，更多的是關注的是其色值，而不是透明與否的性質，即可省略“中性透明色”該層級。
  3.6.建立資源庫
  資源庫本身是個sketch文件（sketch中的library或組件庫）。由于在規范系統中，不單單只包含組件，還有各種圖標、圖形等各種資源、各種樣式，避免“組件庫”跟框架中的組件庫混淆，故此定義為資源庫，也是為了能更好的理解整個框架結構。
  建立資源庫的好處在于可以即時同步更新新編輯內容。當你編輯資源庫里的某一個組件時，那么調用了該組件的其他sketch文件會收到組件庫更新提示，可以對新編輯內容進行預覽、對比和確認，使該文件中所有調用的組件同步更新到最新編輯版本，也可進行選擇性更新。
  利用已建立好的圖層樣式，創建資源庫。常見類型有：圖標、圖形、組件。把圖標、圖形建立為組件也是為了方便資源調取，提高資源的復用性。特別是圖形類資源，這類資源普遍為一次性消費，把所有的資源整合到一起后，在后續的工作中可當作為靈感素材庫，也可在項目緊急時快速獲取有用素材。
  在建立時，每一個元素需賦予已定義好的圖層樣式，才能在后續的運用中起到作用。其次，作為一份通用于多平臺設備的規范系統，需要考慮每個平臺之間的異同關系，并且有明確的倍數關系。后才可定義通用組件再可進行各端組件合并，或重新定義較為復雜的組件。
  在做觸摸大屏、電腦端、網頁端、移動端、平板端這幾個平臺的通用組件時，一定會十分的頭疼。常規的移動端多尺寸適配就已經夠各設計師撓頭了，何況現在各種類型的平臺設備，倍數關系不同不說，直觀視覺感受差異更是大，還需考慮可交互的動作展示效果。
  可以從各端的基礎屬性進行共性提取。從下表中可得知PC、web、pad1 x三端為相同倍數關系，命名為關系A；IWB與Moblie為相同倍數關系命名為關系B，關系A與關系B之間的差異為視覺階梯參數中，后者比前者高一個參數。另外，Pad、IWB、Moblie為相同的觸摸操作模式，需注意交叉關系中的部分組件展示樣式的差異性。
  再者，資源庫的內容展示排布需按照框架結構的類別進行歸納，并且帶有分類文字標明。通常在一個較為完整的資源庫文件里，組件的類型會十分的復雜且數量多。按照一定的順序、類別歸納整理排布，有利于后續進行迭代調整或者檢索時快速找到對應的組件。統一的排序方式也有利于組件之間的對比與校對。
  4.1.制定使用規則說明；
  在大部分公司里，規范經常都是處于被動又尷尬位置，不是做了沒人看，就是沒做就有人喊著要的；又或者寫完共享出去就完事，也不確定所有人是不是能夠完全明白規范里的所有內容等現象。這些其實都是團隊對于高效協作意識不夠所導致的。
  在規范制定完成后，需對規范內容進行核心部分提取并，盡可能的把基礎信息、通用信息等能讓人一眼便知曉規范的大致信息的內容提取出來作為規范的基礎準則且形成文檔形式。然后對內部團隊包含研發團隊進行一次且詳細的規范講解，快速的提高大家對規范認知以及熟悉度。這對于工作交接、團隊協作、甚至是多方案產品都是大大提高工作效率的第一步。
  4.2.了解并熟悉sketch中組件與圖層樣式的用法；
  了解是否為組件以及有無圖層樣式的差異；作為一個組件并且運用圖層樣式時，則可以快速在右側操作面板進行快速的更換組件、或者更換圖層樣式，比如顏色、文字屬性。且若引用的library有內容更新，則可點擊右上角的通知進行同步更新。
  如果只是普通的界面元素組合但運用了圖層樣式，除了不可快速替換組件以為，仍可以快速在樣式庫中更換屬性或者更新屬性信息。
  但若兩者均無，則需找到相關的屬性說明文檔再為此更換其屬性，操作起來較為繁瑣不說，多人協作時，內容的維護與更新的信息是無法即時同步的，需流水線式的更替，稍有信息不對稱的情況，就有可能出現內容不統一。
  資源庫的組件調用也是十分便捷，在頂部工具欄中的添加可進行快速的調取使用。如若是替換組件，則可選中組件才右側操作面板進行更替，或選中組件后右鍵選擇“替換”進行更替組件。
  4.3.記錄每一次內容更新記錄；
  詳細的記錄每一次更改的內容以及更改時間，如果允許，圖例說明是最好的呈現方式。把更新內容記錄下來不單是為了內容追溯、同步信息更是為后續迭代做基礎。
  4.4.定期維護完整文檔；
  完整文檔有很多種管理模式，但在維護前需明白，這本身便是屬于投入產出比低的工作。需根據團隊自身要求去維護，而不是無意義的為了做而做。
  關于維護的方式，在實踐一段周期后，發現以大版本為節點，或以版本周期為節點能更好的做好維護工作，如Vx.x.0、Vx.0.0。通常在這些版本周期大概為10個小版本并且長伴隨大改版或者大功能迭代，可以配合這類契機點進行文檔整合，事半功倍。
  在梳理好的文件里，可適當標明信息，例：v1.1.0（完整文檔）。
  規范是需要靈活運用的，不是把設計師框死，也并不存在絕對的對與錯，只有適合與否。
  部分落地稿
  本文轉自：小阿田的設計筆記