這次我要談的是規范而不是產品設計。一直都在說設計需要規范，各大公司團隊都有自己的規范，也會不斷地更新和制定新的規范，但是執行難，效率低，力度弱卻是規范的弊端。Angela提出了“理想設計規范的三條狀態”，她指出規范的作用是滿足使用者需要、滿足協作需要以及提高團隊效率，但是通常這些是制定者的理想，卻是執行者的痛苦。

　　規范越復雜，流程就越復雜，執行起來就越困難。為什么會缺乏執行力？反過來想想，是不是我們制定的規范缺乏用戶體驗，讓執行規范的“用戶”感覺很難用。所以我提出來，要把規范當作產品來設計。

　　先分析一下現狀。

　　現在的規范不外乎時間上的控制、流程上的把握、人員上的配合以及看上去的可行性。所以規范不是來制定某個設計需要多少注釋和說明，而是讓使用者能夠有更多的時間關注更重要的東西，能夠讓協作來的更加輕松甚至是能夠提高整個團隊的效益比。如果你的規范是要求你的產物需要用綠色框來做標注，那么請停止，你的規范只會讓使用者叫苦，卻不會給團隊帶來太大的效益比。

　　再從執行方面來講，規范是制定容易執行難。通常管理者和制定者不是同一個人，所以管理者會忽視制定者的主要意圖，最后使規范荒廢掉。之前提過的DQA的角色，TA是控制質量和效率的重要角色，TA是規范的執行者。但不是有了DQA我們就高枕無憂了，而且實際上DQA的角色對于很多公司來講是一種負擔，很多公司都把DQA的責任交給了設計總監，畢竟是總負責人，即有權又有能力。也就是說在沒有規范的時候，設計總監就是規范！但我覺得把規范應該交給人文環境進行控制，而不是某個人來親自執行。就像國家的禁塑令，在推出前很多人報以懷疑的態度，但是現在你去超市看看，大部分人都拎著自己的袋子，你還好意思去買塑料袋嗎？這就是人文環境的影響。

　　最后現在的規范有一大塊是關于文檔等的記錄。至少我就有很多文檔模板，而且在做每件事的時候都會想到在文檔里面應該怎么記錄。周報日報一大堆，說是記錄你所做的事情，但是回頭看看，寫了也就寫了沒有什么大的作用，最后久而久之就慢慢荒廢了。文檔要用的恰當好處，有些實在無法描述的說明還是需要進行相應的溝通，就好比網站的某些功能實在沒法使用的時候還是需要客服電話，如果這時硬要用戶去發郵件描述并安靜等待的話，用戶肯定會發瘋。規范不是需要刻意記錄的文檔，大部分文檔是在執行規范時的產物，類似于日志一樣，只有部分輸入輸出物必備的文檔才是需要去關注的。

　　現在我再次提出，把規范當作產品來做。通過分析使用人群和應用場景，對其進行投入產出比的配置規劃，并且合理設計流程上的體驗，在規范上線之后有效地制定升級包的計劃和遠期規劃，以此來得到對執行者有更好體驗的規范。

　　那么我們來試試看吧！拿我們的團隊作為背景來進行規范的設計。

　　一、分析用戶群

　　按照橫向維度分，使用人群主要有產品設計師、視覺藝術家、內容策劃師、前端開發工程師、用戶測試員以及團隊管理者，外圍人群包括產品業務經理、需求分析師、系統分析師、系統開發工程師、項目經理、測試工程師、系統平臺發布管理員等等。

　　按照垂直維度分，可分為被動接受（新手）、被動接受并有反饋（熟練）、主動執行（精通）、主動執行并推動產品升級（高級）、全力推行并負責升級（管理）。

　　二、應用場景

　　主要有業務相關項目、自發項目、日常需求三個。

　　三、需求分析

　　工作中每個角色間都有互動的關系，但并非是如下圖的垂直傳遞互動。

圖 1-1 垂直傳遞互動的關系

　　角色間的關系應該是互補的形式，下圖是在業務相關項目下的范例：

圖 1-2 互補型的互動關系

　　圖中藍色文字是互動的內容，藍圈是UED團隊的開發核心，紅圈是業務方，黃圈是系統地層，橘圈是測試及產品發布服務。

　　從上圖可以看出在完成一個項目，產品設計師是產品的核心，也就是說產品設計師是最終產品的決定者，TA除在完成本職任務以外，還肩負著協調和執行各方角色工作的任務。所以從規范來看，應該從產品設計師入手，并且散發到和每個觸角的互動中去。

　　下面簡單分析一下團隊里面的產品設計師角色需求如下：

　　1、根據項目（需求）的大小來靈活控制輸出物；

　　2、能夠及時了解發展規劃方面的行為動向；

　　3、輸入物的格式能夠成為設計師的資源而不是阻礙；

　　4、輸出物可以讓其他角色一目了然，盡量減少溝通的成本；

　　5、在申請資源的同時希望能夠及時落實并得到資源的反饋；

　　6、能夠清晰明確項目的進展等相關情況；

　　7、對于產出物可以得到合理的評價體系支撐；

　　8、對產品的遠期有規劃和標準執行方案；

　　9、其他。

　　四、流程設計

　　這一步在傳統的產品設計中是主要部分，當然在設計規范時也是最重要的部分，它決定了最后規范如何被執行，也預見了規范在執行時所遇到的問題和解決辦法。

　　這里要做的就是把產品設計師的互動流程進行規范。分為三大塊，分別是產品業務項目、自發項目、日常需求。

　　1、產品業務項目：

　　由業務方發起的互動中需要包含一些市場數據和業務分析以及期望值，有明確的產品規劃和目標，最后需要有BRD和詳細產品描述資料。

　　接著在產品設計師的互動中，需要明確設計資源和時間點，明確產品內容、視覺以及前端的需求，并有能夠直接指導開發工程師來完成產品概念的指導文檔。最終要得到可用性評估測試的反饋和改進方法，以及產品規劃方向的標準制定。

　　2、自發項目：

　　由產品設計師自主發起的項目，在與業務方互動時，主要是得到一些現有數據，并且得到一些業務支持，在和其他角色合作時與產品業務項目時類似。

　　3、日常需求

　　由需求方發起的日常需求，互動時需要雙方遵守傳遞統一化的方式，并且在和前端、視覺、內容策劃互動時，主要是確定資源和時間點的問題。

　　這里的流程沒有細講，主要是把關系和內容簡單的整理了一下，在設計具體規范時還需要細化每個點的流程，特別是遇到問題的解決方法。

　　五、原型設計

　　這一步就是實施規范的撰寫，方法有很多，但是我建議先從全局的出發，通過發散思維和流程設計的結果，再慢慢細化每個環節。除了文檔以外，規范還需要角色間的培訓和認知，并由管理者統一進行意見反饋和收集。

　　六、測試

　　也就是規范的試運行，盡量不要大面積使用，會使執行者產品疲倦感，最好使用AB test進行測試，得到較好的測試用例。

　　七、上線

　　經過一系列的反復測試和修改，最終的規范就發布上線，并由管理者來監督規范的執行情況，但管理員并不是來執行規范的主要角色，執行規范的永遠是使用規范的“用戶”以及相應的人文環境。

　　通過產品設計的方法出來的規范是符合個性化團隊需求的，它也會像很多互聯網產品一樣成為每個公司團隊獨特風格的產品。百家爭鳴只是第一步，最終的目的是希望能夠在眾多產品化規范中有一個能夠成為整個行業的規范，把難執行的規范從封閉的團隊中釋放出來，讓更多的人參與并得到行業標準解決方案才是產品化規范的最終目的。