界面設計規范漫談

　　一、為什麼要寫設計規范?設計規范是為誰服務的?

　　談這個話題之前，我們先了解一下什麼是設計規范?設計規范是指對設計的具體技術要求，是設計工作的規則。 一般包括總體目標的技術描述、功能的技術描述、技術指標的技術描述，以及限制條件的技術描述等。

　　那我們為什麼要用設計規范?第一，可以讓我們清楚項目的規則，以減少犯錯誤的機率;第二，加強團隊之間的合作，責任明確，提高工作效率。第三，鍛煉我們整體全面的思維能力。

　　規范最終是為項目服務的。我們所做的一切都是為了優化項目，提高我們的工作效率。但是，設計規范也是一種設計團隊文化。最終受益的不止是項目，還有我們自己。當我們形成這種文化，我們會配合的更默契;我們不需要在工程師加班的時候，一定留守在那裡陪著;我們不需要在調別人設計的源文件時，一遍一遍的詢問。當你不再因為別人的事情而加班的時候，心情是否好一些呢?

　　設計規范滲透在整個軟件工程裡。不同的工程模型對規范的要求也不一樣，並非詳細全面的設計規范就是最好的，因為規范是要有生存環境的，小公司的快速開發適合變通，大公司的瀑布模型適合嚴謹。如果不考慮自己本身的工程模型，而一味的追求全面，詳細，其結果不但不能真正幫我們提高工作效率，反而會因為過多的其它作業而延誤項目周期。

　　規范要有概括性和引導性，不應該扼殺設計師的創造力。我曾經見過一份圖標的設計規范：必須要45度角側視角度。我覺得很好笑，完全沒有必要這樣限制嘛。我們可以這樣規范：要有統一的視角，統一的倒角，顏色數量不要超過三種，統一的材質等等，這樣即可以統一圖標的風格，又可以引導設計師。

　　二、設計規范分哪些種類?都有哪裡內容?

　　1、產品級戰略方向規范

　　最穩定的設計規范，適應於長時間不變更的內容。大至可以分成二大部份：

　　第一部分：整個公司產品的設計方向。比如：是使用公司中VI定義作為我們的主產品色，還是在某種限制上隨意發揮?整體風格以硬朗的表達方式還是圓潤一些?怎麼打造和延續一個品牌的氣質，以增強用戶的歸屬感等等。

　　第二部份：達成共識的，恆定不變的內容。比如基本控件的設計規范，基本交互的規范，文檔書寫的規范等等。

　　2、項目中單個設計規范(交互規范，視覺規范)

　　是項目中最為詳細的規格說明書，整個項目都是按照這些設計規范完成的，也是最後測試評審的依據。該規范被細分為N多份不同的方向。比如：流程說明;交互模型;交互規范;圖標設計規范;界面設計規范;界面實現規范;控件設計規范等等。這些內容應根據每個公司軟件工程的模型不同而有所變化。比如：瀑布模型軟件工程的側重點可以細致而全面，但這些只適用於大公司，能承受較長的項目周期的公司;而使用極限編程的側重點在流程說明，交互模型和項目需求變更上;還有一些不使用軟件工程的小公司，在定義的時候，側重點則在界面的設計規范和實現規范上。大家在定義的時候還是要根據自己公司的實際情況出發，真正做到優化自己的工作即可，這一點會在"如何定制設計規范"中詳細說明。

　　3、接口的輸出規范

　　這裡是指我們輸出至工程師的文件規范。我們需要輸出什麼樣的內容才可以幫助我們減少和工程師的溝通摩擦，我們的工作范圍在哪裡?記得自己剛來現在這家公司的時候，有一個很不錯的設計師抱怨說，這個坐標我已經告訴過他十幾次啦，每次他都說自己忙，沒空改，現在老大說我們設計的界面有問題，我們設計師做事不認真，其實這個責任根本不在我。我想了一下，這確實不是他單個人的問題，是我們的輸出接口沒有規范，沒有細化，從而造成范圍不清楚，責任不明確。如何避免呢?我們需要去定義輸出規范，定義我們需要提供什麼樣的實質的內容給工程師，比如坐標圖，效果圖等。在這個過程中，在提高工程師工作效率的同時，大量的減少這種摩擦的發生。

　　接口的輸出規范大至可以分為以下幾個方面：需要提供的元素定義，比如：切圖，坐標圖，效果圖，流程圖，架構圖，文檔等;切圖的規范，比如：圖片格式，圖片共用部分的劃分，切圖的位置，多種狀態等;文件命名的規范;文件夾的存放分類規范;文檔書寫的規范;等等。

　　4、計文檔的管理規范

　　當多個設計師相互配合完成一個項目的時候，設計文檔的管理規范就顯的尤其重要。我們來想象幾個場景：場景一，你需要調用一個同事設計好的界面裡的子模塊，打開PS的源文件一看：哇，幾百個圖層，無文件夾管理，無命名。場景二，同事請假了，臨時要用一個他設計好的界面，打開他的電腦，找了一個小時沒有找到，火大呀，感覺自己重新畫都畫好了。場景三，老大跑過來找你要某個文件，就站在你身後，你找來找去就是找不到，那個急呀。我想這三個場景應該是大部份設計師都經歷過的，還記得當時的心情嗎?

　　設計文檔的管理規范挺重要的，它不論是團隊合作還是個人，都能很有效的提高工作效率。一般包含以下幾點內容：文件的存放，比如：工作文件目錄的分類，本機的存儲模式，服務器的存儲模式，資源文件的存儲等;文件的命名，比如：切圖的命名格式，源文件的命名格式，需要輸出的架構圖的格式，多版本的命名格式等;源文件的管理，比如：圖層的命名，分件夾的分類，源圖的處理等;文件的變更管理(版本管理)等。

　　三、如何定制設計規范?

　　定制規范不是某一個設計師的職責。現有的中小企業老板在受到外界影響下，總是這樣下達一個命令：某某設計師，請把我們公司的設計規范寫一下，什麼內容，什麼方向一概不講，我個人認為這種方式是完全錯誤的。規范的定制並非只是上行，更要下行。取得上司支持的同時，更要得到同級和下屬的接納，這份規范才有意義，才有執行的力度。在戴維邁爾斯的社會心理學裡講過：態度依從行為。全民參於有利於提高全部設計師的積極性，加強承諾後的執行力才會更高一些。

　　中國一直在講中庸之道，什麼是中庸?就是要取平衡點。物極必反，過量的行為並不是達到目的好方式。記得周陟說過一句話：小細節改變大流程。我灰常的贊同這句話，任何公司的改制都不應該全盤否定而重新定制，就像一艘大船想要轉彎也要走一個拋物線，如果一定要急轉彎，那就要有能力去承受翻船的可能性。沒有最好的規范和流程，只有最合適的。別人的東西看著再好，那未必適合自己。微軟的規范好嗎?騰迅的流程好嗎?如果你只是一個五人以下的設計團隊，那就堅決不要采用他們的流程，否則繁雜的工序只會延誤項目周期從而拖死這家公司。

　　以上講這麼多，無非是告誡大家不要盲目的去抄襲別人的規范和流程。在明確了自己當前公司的設計規模和流程體系之後，根據實際情況定制出有助於項目和設計團隊合作的規范，這才是最有意義的。那麼，我們要該如何定制規范?在這裡，我把自己的經驗和大家分享一下，做個參考：

　　1、由上到下。從流程上來講，我們必須要先取得上司的支持，再和同級或下屬共同定制。我們有很多規范需要設計師和工程師共同完成的。舉個例子，切圖文件的命名規范，如果只是設計師按照規范命名，而工程師做不到的話，那最終工程的切圖資源一定還是亂做一團，很難定位想要的圖片，結果這份規范就失去了意義。取得上司的支持很重要，他是規范執行力度的一個保障。

　　得到上司的支持以後，我們開始列出大致的方向和范圍，開始和同級或者下屬進行討論。毫無目標的討論是沒有意義的，所以一定要有范圍，比如，今天我們只討論輸出的規范。我們需要交付給工程師的都有什麼?切圖，坐標圖，效果圖，架構圖，還需要有什麼呢?我們的切圖目錄該如何存放?等等，大家暢所欲言，在會議時就要定下大家的建意和想法，總結整理，最後大家簽名。給上司過目之後簽名，這就是一份生效的規范了。

　　2、由團隊到個人。先定制團隊合作的規范，再定制個人操作上的規范。

　　團隊合作的規范很重要，規范定制的好，很容易提高工作效率。比如說源文件的管理規范，在多個設計師相互配合一個項目的時候，如果每個人設計師都有自己的風格和管理方式，那將會是一種災難。每個人在相互調用文件時，都要找對方詢問N遍，次數多了，雙方都不會有好心情做事，您是否經歷過這樣的場景而深有同感呢?個人操作規范相比團隊的要輕一點，自己管理的混亂影響的是個人的效率，做不完自己加班，但不會影響到整個團隊。但是，如果團隊溝通不好，那就一起加班吧。所以，團隊合作上的規范一定要先做好，再去規范個人的操作。

　　3、由大入小。先定制大的設計方向，再定制項目中單個詳細的說明。

　　我們在設計產品的時候，一定要有設計方向，有一個統一的產品設計規范。像蘋果的產品，迅雷的產品，騰迅的產品一樣，不論他們出了什麼樣的新產品或者新軟件，大家都能感覺到這就是他們公司出的，這就是我說的大的設計方向。現在是品牌的年代，我們必須要有這樣的一份規范來建立我們的品牌氣質。但是，這份規范不可能定義某個界面應該使用什麼樣的文字或者使用多大的字號這種細小的問題，這明顯不適用於所有項目。那麼我們就需要針對每一個項目都要寫一份規范，來定義這些細小的問題。單個詳細的規范是從屬於大的設計方向的，是大的設計方向上的一個分支。大的設計方向一般短期不會改變，單個詳細的規范說明，我們可以專門定義一個模板，在每次項目開啟時填上即可。 所以，我們需要先定義大的方向，再定制項目中單個詳細的說明。

　　4、由交互到視覺。先定制交互規范，再定制視覺規范。我想這個不用我多說啦，大家都明白的。交互永遠都是走在視覺的前端，視覺是在交互的基礎上做產品效果。如果交互沒定義就開始定義視覺，我想多半也是廢紙一張啦。

　　文章來源：藍色理想