△ iOS kit 同樣的，前端開發也會在開發過程中形成組件庫，避免代碼重復編寫。最經典的例子就是Bootstrap，就職于 Twitter 的一個設計師和一個工程師創造了這個廣受歡迎的前端開發框架，里面包含了按鈕、輸入框、模態框等網站需要的各種組件。 △ Bootstrap 也就是說，不僅設計師需要一套完整的設計規范，開發者也同樣需要一套組件庫及文檔。將二者結合再產出規范，將會提升設計師和開發者的協作效率。此外，由于設計師和開發者的思維不同，制定時相輔相成，制定出的規范將更加完整且更具有實用性。 那么這樣一套設計規范該怎樣做呢？前段時間我司網站改版，就制定了一套這樣的規范，我們給其命名為Musikit。現在我回顧一下整個過程，希望能給你帶來一些思考。 △ Musikit △ Musikit首頁 一、設計師在初步設計中制定一些基礎規范 產品文檔交付之后，設計師就開始進行整體風格把控，并制定一些基礎規范，比如字體使用、字號層級、基本色調等。這些東西完成之后，設計師就會開始具體頁面的設計。不考慮特殊頁面（專題、活動等），此時必定需要諸如按鈕之類的基礎控件，那么設計師就會對其進行提取。 當控件具有一定數量時，一個基本的設計規范就有了雛形。在此階段設計師不用考慮太多全局的東西，不能因為規范限制思維，只需要順著思路往下做，遇到公共控件提取出來即可。
二、前端開發加入，對控件進行擴展 在設計師進行到上述狀態的時候，前端開發就要加入了。前端開發在此時可以對設計師的設計稿進行技術評估，對控件進行擴展補充。比如，設計稿中評論區回復按鈕有兩種：回復和取消。設計師考慮到了使用不同樣式區分不同功能，但是沒有考慮到按鈕的狀態：鼠標移上去時、點按時及按鈕禁用時。
△ 回復按鈕和取消按鈕 因此，前端就對其進行了補充，完善了按鈕的不同狀態。 △ 按鈕的狀態（行為） 同時，注意到該頁面設計稿中還有一些比較大的按鈕，考慮到按鈕尺寸也是變化的，我們一致討論決定將按鈕擴充到五種尺寸：高度從20px到60px每個相差10px。 接著我們又初步確定了三種不同顏色以滿足當前設計情景，這樣，一套按鈕組件就基本完成了。在此過程中前端開發需要及時了解設計師的想法，憑借以往經驗對控件做出一定的擴展。當然也無需過于全面，以通用場景為主，特殊場景再作考慮。 三、設計師和前端開發的“輪回戰” 后續設計及開發過程中，設計師和前端就需要按一定頻率相互溝通反饋，重復第二步過程，共同完善這一套規范。 隨著組件增多，我們先對其進行了簡單分類，按照復雜程度簡單的分成了部件和插件。 △ Musikit導航 部件是經常使用的一些簡單控件，比如按鈕、輸入框、表格、頁碼等等。這些東西大多比較簡單，沒有太多交互，只需要CSS樣式就可以實現。 而插件則比較復雜，通常包含一些復雜交互，也包含一些基本部件。彈出提示、模態框、表單提交等就是插件，他們不僅需要CSS樣式還需要JS來實現交互。 接下來的過程，設計師和前端開發都需要一定的敏感度，在工作過程中注意哪些東西是可以作為部件或作為組件的。比如我們在登錄注冊彈出層的設計及開發過程中就注意到了發送短信驗證碼是可以作為一個組件的，因為不僅這里需要用到，賬號綁定手機等場景也需要它。 △ 發送短信驗證碼 有些組件可能很復雜，要適應多個場景，前端開發就需要找設計師了解以后可能會怎么用，哪些屬性不能寫死要作為一個配置項等。我們在最初設計模態框時，將其寬度寫死了，后來設計師新出的設計稿中模態框出現了不同的寬度，我們就及時將模態框的寬度調整為可配置項。 △ 模態框 四、形成文檔 一般的設計文檔，是設計師制作的圖片存檔。既然這一次前端開發也參與了，我們就把設計規范做成了網頁，并增加了代碼部分。 △ 代碼部分 這樣一來，設計師和前端都可以進行參閱，而且這些控件還是可以交互的，清晰明了，簡單易懂。 我們將這些東西放在了主站下，并對訪問權限做了限制。考慮到有些代碼很長，而設計師有可能會有代碼恐懼癥，我們增加了一個角色切換按鈕，切換成設計版時會隱藏代碼。 △ 角色切換 結語 改版第一階段完成后，Musikit就上線了。相信有了Musikit在第二階段的工作過程中大家的效率都會提升，但是這套設計規范遠遠沒有完成。這個過程中，設計師了解了前端開發的一些簡單原理，前端開發也能及時了解設計師的想法，大家不再是各做各的而是真正協同起來，這也許是共同制定設計規范的最大收獲。
