頭條楓林網
文章摘要： 規範裡要寫什麼 如何寫 如何推動規範落地 一、如何確定內容列全 針對自己情況進行縮減 2. 寫 確定優先順序 確定規範書寫格式 逐步對單個內容進行整理與書寫
從一開始的立項到現在落地上線，可以說是從零開始進行 APP 全部細節的梳理並且規定規範，這一路走過來還是能總結出很多心得，本文將分為3個部分，闡述如何從0到1建立設計規範。
目錄
- 如何確定內容，規範裡要寫什麼
- 如何寫
- 如何推動規範落地
一、如何確定內容？
這裏我總結了三步：
1. 確定目標使用者、使用者目標、設計目標
根據不同的用途和目標，不同的團隊對設計規範的制定是不一樣。比如爲了指導與規範全球第三方開發者進行設計和開發，Google 建立的 Material Design 覆蓋面廣，每個元件細節寫得非常細緻。Ant Design 則是直接做出了元件，方便直接進行呼叫。有些國內設計團隊的規範則是主要描述常用控制元件和色值。因此我們需要確立使用者目標和設計目標，這樣才能確定我們的規範側重點是什麼，需要做成怎麼樣的形式。
在這裏我列舉了自己撰寫規範時的使用者與目標：
2. 模範大平臺，先列全
一個規範裏面的東西是很多的，那麼我們究竟需要做什麼呢？假如一開始我們沒有方向，找一個，列一個，這樣我們很容易疏漏很多情況。在這裏我採用的一個辦法是：首先熟讀 iOS，Material Design規範，並且模仿他們，在腦圖中，把規範中應含有的所有內容羅列出來，羅列一個大綱。
這裏我列舉當時自己做的一個腦圖大綱，覆蓋了主流規範中的所有細節，大家可以進行參考並模仿：
3. 針對自己情況進行刪減
列完齊全的大綱後，我們需回顧設計目標，對大綱裡的內容進行刪減。（比如在元件、模式這些地方，可以對著自己的 APP，進行挨個尋找，看自己的 APP 當前是不是運用了這個元件，沒有的話就進行刪減。）
在這裏我列舉了針對自身 APP 的情況刪減後的大綱圖：
二、如何寫
進過了以上的三步，我們基本得出了要寫什麼的框架了，接下來就是如何寫規範的階段。
這裏我總結了3步：
1. 確定優先順序
我們可以通過版本迭代計劃+價效比+重要性（該元件在頁面出現的場景次數以及當前的不統一對 APP 體驗影響程度）這幾個維度分別確定每塊內容的優先順序和分工。基礎的、必要的、高性價比的放在第一期，複雜的向後放，隨著產品的迭代，我們的規範也會越來越完整。
同時需要留意版本規劃，瞭解即將要做的功能或即將要改版的頁面。我們可以提高這裏面牽涉到的控制元件、元件等內容的優先順序。龐大複雜，牽涉到很多頁面的，我們可以先降低其優先順序：比如全域性提示框的規範，toast 的規範。
同時，我們也需常與開發溝通，爭取把可複用性高、元件日後變化幅度少的元件做成開發元件庫。
2. 確定規範書寫格式
我們制定的規範本身也是設計的交付物，假如每個設計師都按照自己的喜好來編寫規範，那麼這個規範本身也會變得不規範，規範自身保持一致性是提高規範閱讀效率的一部分。
我們可以迴歸我們之前制定的使用者目標和設計目標來制定我們規範的書寫格式。規範的使用者群是誰，主要想達到什麼作用，是通過文件展示還是網上展示，確定了這些問題後，就可確定規範的詳細程度、主要的展示形式（比如前文說到的 Ant Design 和 Material Design）。
這裏我的思考點是：假如規範寫太多字就會變得很臃腫，沒有人喜歡慢慢仔細的閱讀你寫的規範，所以我們應該做到寫得簡明扼要，再輔以例子說明（根據開發的習慣，都是喜歡直接看例子，看標註）。
我的書寫格式是：先寫描述這個元件是什麼，再列舉出現的場景，然後編寫互動規則，最後給出視覺標註+例子。
3. 逐步對單個規範進行整理與書寫
當確定了要寫什麼東西和格式之後，我們開始進入到細節，對每個內容進行整理，制定規範了。
通過對每個內容制定規範也是有方法的：
下面我通過整理「列表」這個規範來講解：
收集出現的所有的場景
當一個產品已經趨於成熟，這個元件出現的場景就會非常多，比如對話方塊，toast，列表這些元件出現的地方很多，需要我們自己仔細地體驗產品，把所有頁面都找出來。
提取共性，歸納分類
我們需要分析每個頁面的特點並且把相同特點的頁面歸納一起，眾多的頁面場景就能整理成幾個典型的種類，然後只需對這幾個典型的種類進行定義和描述即可。
在列表中，我分爲了大封面列表、小封面列表、使用者列表、單行列表
編寫規則
在分類好後，我們可以對每個種類編寫規則，在這裏我們需要描述好每個種類有什麼特點或屬性，什麼時候場景下適用，並且給出標註和例子，方便閱讀者理解。
多與組內成員討論修改
在制定好初稿後，我們可以與組內成員宣講下自己制定的規範。多從別人的角度出發，確保你編寫的規範是否易懂，是否包含了全部的情況，是否容易執行落實。
三、如何推動規範落地
寫完內容後，最重要的一步就是推動落地，規範要真正有人用才能體現價值。
1. 幫助推動規範落地的小建議
制定規範推進進度表
表格裏面應該包含規範制定的優先順序，分工進度，分工人員，並且確定每一期進度的交付時間，開會討論的時間，作為負責人，也可以適時提醒成員每次的開會時間。
編寫過程中多與其他成員討論，達成一致性共識
制定規範後，與部門其他人員進行宣講，灌輸概念，針對如何更好的落實進行討論調整。在設計中都不可能一次就完美，我們需要不斷的在修改中逐漸完善。
規範建成後放在網上
同步在網上，方便部門內的其他成員能隨時檢視和團隊成員對規範的更新修改、同步。
強制性制定規則要求團隊成員執行
有明確的懲罰機制和要求才能更好的執行，不然在規範制定後很容易健忘此事。
規範保持持續的更新迭代
規範推動落地後並不是完全了事，要根據產品的迭代，保持規範的更新。
這整個制定規範的專案中，還是有不少反思的地方，值得我們深思和注意。
2. 深思和注意
切記不要為設計規範而做規範
規範最重要的點是能推動落地，能確確實實改善產品，達到統一性。因此我們在設計規範時，並不需要「高大上」術語，給出一大堆的設計理念用來提升設計檔次。而是真正的迴歸到我們的設計目標，針對目標使用者制定規範，做到簡樸、易懂、能落地。
沒人願意閱讀長篇文字
我們應該儘量控制文案長度，做到通俗易懂即可。
要時刻圍繞我們的目標做規範
比如，我這次做的規範中有一項是去工具化，在制定控制元件中，空白頁面中就會加入很多趣味化的設計。
靈活變通
規範只是適合大多時候的場景，對於一些規範中沒有包含或者不符合規範的場景，我們可以靈活變通，積極創新或者是補充新的規範（前提是與組內積極溝通，達成共識）。
總結
再來回顧如何從0到1建立規範。
1. 確定內容
- 確定使用者目標和設計目標
- 模仿大平臺，列全
- 針對自己情況進行縮減
2. 寫
- 確定優先順序
- 確定規範書寫格式
- 逐步對單個內容進行整理與書寫： 收集全部情況 、 分類歸納 、提取共性，編寫規則
3. 推動
- 制定規範推進進度表
- 編寫過程中多與其他成員討論
- 把規範建成後放在網上
- 強制性制定規則要求團隊成員執行
- 規範保持持續的更新迭代
歡迎關注「TCD設計中心」公眾號：
圖片素材作者：Tran Mau Tri Tam ✪