前言
這篇文章講的是如何製作一份產品、UI、開發、測試都喜歡看的交互設計文檔。文章內容主要是自己工作中用到的交互設計規範模板（axure版本），這套規範是自己總結出來的，但是構建的思維方法借鑑很多前輩大神的方法論，特別是淘寶U一點團隊所分享的公開課內容。
抱著他山之石，可以功玉的想法，結合自己公司團隊的工作特點，總結了一套交互設計規範。使用中，有些小收穫，分享出來，大家多多溝通，共同進步。
這篇文章的行文思路是，先說明交互設計規範準則是什麼、然後舉例說明交互設計文檔各模塊的書寫思路及踩過的坑，最後是一份可供下載的模板和組件庫。
一、交互設計規範化文檔的準則
1.1 為什麼要輸出一份交互設計規範
1、“設計有記錄、信息可追溯、交流有依據”。這個很重要、重要、要。一個產品的誕生不是你一個人幾天的事，它有多部門配合的寬度，也有多版本迭代的長度。一個交互設計師，如果設計不嚴謹挖了坑，早晚是要填的，交互設計規範或許可以幫你規避一些坑。
2、“在團隊中，信任真的是一切溝通的基準”。交互設計師，工作中除了解析需求，繪製交互稿外，更多的時候需要配合UI完善設計，跟進開發實現效果。如果你繪製的交互稿沒有那麼的完善，缺東少西，UI和開發就會慢慢對你沒有信任感。這個時候，你的其他工作也會很難開展。也不是說一份交互設計規範，就能讓開發對你產生信任，但是一份好的規範，能彌補你部分欠缺，提高你設計的正確性，同時一份好的規範文檔可以降低溝通和學習成本，展現你的專業化能力。
1.2 交互設計規範要求
1、符合自己的就是最好的。一定是根據自己公司工作流程，和上下游溝通後來確定自己的文檔應該包括哪些內容，哪些內容需要著重寫，哪些內容可以少寫，書寫的方式應該怎樣，團隊內行業內是否有共同的說法和寫法。畢竟規範的作用就是為了提高工作效率的。
2、擴展和更新。不同類型的項目，所涉及的控件，所使用的規範要求不同，要學著調整和更新自己的模板。
二、交互設計文檔各模塊的書寫思路和踩過的坑
先來一份交互文檔的目錄
圖2.1 目錄
2.1封面
開篇明義，文檔的基本信息概述。
版本編號：此文檔的最新編號；（一定要記得更新）
設計人員、開發人員、測試人員：表明文件流轉的下一級相關人員，方面溝通（如果涉及人員眾多，也可單獨列舉）
圖2.2封面
一份規範的交互稿不僅是對自己負責，也是對其他夥伴負責、對將來負責。
2.2文檔說明
交互文檔的目的就是為了上傳下達，將需求轉化可視化文檔，是一個過程性文件。所以，文檔的可閱讀性是衡量一份文檔好壞的一個標準。而文檔說明這個模塊就是為了給不同的文檔閱讀者相同的“世界觀”。
2.2.1項目背景與範圍
更完整的項目背景應該出現在產品需求文檔中，而交互文檔中書寫的目的有兩個，第一，如果項目小，沒有完整的產品需求文檔，這裡就是向各方人員傳達項目背景的地方；第二，加深整個項目組成員對項目的理解，看內容前，先有一個共同知識背景。
（書寫小貼士：書寫內容相當於用戶體驗要素中，戰略層、範圍層的梗概。）
圖2.3項目背景與範圍
2.2.2更新日誌
目的也是有兩個：第一，面向自己。工作是一個過程，完整的記錄更新日誌，方便自己將來查詢，同時，也方便和開發測試互撕的時候，亮證據；第二，面向開發、測試。整個開發過程漫長，協助方多樣，完整記錄，可以降低各方不必要的溝通成本。
（書寫小貼士：1、更新日誌，可以在交互文檔評審通過後，需求鎖定後，在開始書寫，設計過程中的更改可以不書寫進去（個人經驗）；2、書寫的內容要具體（寫的不具體，後續會有坑）；3、書寫中最好增加關聯鏈接，方便相關同事快速找到位置；4、同一個位置多次更改時，要標註最新內容）
圖2.4更新日誌
2.2.3設計進度計劃
進度計劃這種東西一般出現在項目工程表中，或者項目工程排期中（具體的可能根據不同公司，有所不同）。而交互稿中的設計進度排期的作用，和前面兩個一樣，一方面是給項目組成員一個共同的背景，另一方面，是自己設計過程的記錄。
（書寫小貼士：1、按照設計過程，可以大致分為需求整理、需求評審、交互設計、交互評審、UI設計、UI評審、開發、測試，根據自己情況進行劃分；2、個人經驗，此處的進度計劃不是整個項目很嚴謹的工程計劃，此處的只是設計師與相關同事溝通協商工作的一個梗概，以及自己的記錄，自己看的明白就行）
圖2.5設計進度
2.2.4評審記錄
區別於更新日誌，評審記錄主要書寫於設計階段。評審記錄主要分為內部評審（設計師（項目內交互和視覺）、UED負責人、UED相關設計師）和外部評審（設計師（項目內交互和視覺）、UED負責人、UED相關設計師、業務負責人（產品和需求方）、技術負責人、技術相關人、市場運營人員）
（書寫小貼士：1、一般都伴隨著會議記錄出現，我一般會書寫好以後，直接剪切當會議記錄）
圖2.6評審記錄
2.3、解析過程
解析過程是我認為最重要的一部分，是產生信任和思維可視化的地方。在進行交互設計原型繪製之前，一定要以目標為導向拆分自己的思維，並將“虛擬”的目標轉化為各種設計元素。
說簡單的點，這塊就是設計維度的需求分析。不同人可能有不同的分析方法和展現形式，不管怎樣的方式，只要能梳理自己思維幫助自己設計並且清晰的向自己夥伴傳達信息即可。
以個人經驗，根據不同類別的項目，不同大小的產品，需求分析的維度和角度都有不同。此處我就簡單說一下，我常用的一種需求分析方法。
以人為核心，以目標為導向的思維解析法
我們做設計，大到一個產品，小到一個頁面，在設計的時候都是有目的，也有需要達到的目標。目的可能來自於公司戰略，來自於市場需求，或者來自於money，不管來自哪裡，商業社會里，我們做產品肯定是有所圖。同時，我們產品服務的用戶，他們的特點有很多、所使用產品的環境有很多、用產品時的想法感覺也有很多、他們也有自己的對產品的追求和要求。而我們是設計師，不是藝術家，我們需要在有限的條件下，利用我們的才能設計最貼合用戶需求，最能產生商業價值的產品。這個過程就是下面這個需求分析推導的完整思路。具體內容，我就不再這裡展開解釋了，可以仔細看下圖。我針對各個具體環節做了一些簡單說明。將來如果有合適的、可對外分享的案例了，我可以詳細說明下。
（書寫小貼士：1、書寫形式可以多樣，只要能幫助自己理解需求、方便設計即可；2、需求分析可以有更詳細的文檔，交互文檔裡寫，還是那個目的，讓上下游看到，能達成共識；3、我文檔中列舉的其他幾種方法，只是一個例子，可根據具體情況使用）
圖2.7需求分析推導
2.4、頁面交互方案
頁面交互方案，也就是我們常說的那種交互原型文檔。具體如何寫，在這裡就不多說，具體業務具體討論。這裡只說下，在日常工作中，常見的幾種交互文檔書寫的思路方法，已經書寫的範圍和注意事項。
2.4.1流程圖
重要性就不多說了，很重要。另外，一定要在設計前梳理好流程圖（可以不完整），一定不要後續為了展示補流程圖，那樣，流程圖就不能起到它本身的作用了。如果你原來不是這樣做的，可以調整下思路。
（書寫小貼士：1、流程簡單可以繪製一個流程圖，如果流程多，建議拆分成各個子流程繪製；2、除了繪製功能流程圖外，建議可以繪製業務流程圖；3、繪製軟件多樣，可以axure，也可以使用第三方軟件。）
圖2.8流程圖
2.4.2信息架構圖
重要性也不說了，很重要。繪製信息架構圖，只是一個展現結果，如何繪製才是核心，方法就不在這裡展開。
（書寫小貼士：1、信息架構圖可以從功能--頁面--模塊--元素這樣的維度書寫；2、共通模塊可以並聯使用；）
圖2.9信息架構圖
2.4.3交互頁面
交互頁面主要有兩部分構成，一部分是頁面，一部分交互說明。
一個Axure頁面表達一個事效果最好，最受同事喜歡。什麼叫做表達一個事呢？一個事既可以指一個流程，也可以指一個頁面。
一個axure頁面表達一個頁面。
（書寫小貼士：針對核心頁面具體說明，至於頁面所關聯的子頁面和流程就在其他頁面表達。）
圖2.10一個Axure頁面表達一個頁面
一個Axure頁面表達一個頁面的多種狀態：
圖2.11 一個Axure頁面表達一個頁面的多鍾狀態
一個axure頁面表達一個流程
一個流程是指最小的一個子流程，子流程與母流程之間可以通過Axure文檔的樹結構表達
圖2.12 一個Axure頁面表達一個流程
2.4.4交互說明文檔
一份合格的交互說明文檔應該包括但不限於
頁面內容說明（數據來源，數據特點，內容類型，範圍，極值，排序規則等）；
交互反饋，狀態；
交互動效、視覺要求。
下面這個案例中，對頁面元素做了詳細說明，包括數據特點、計算規則、更新極值、特殊情況說明、狀態說明，視覺樣式說明等。
圖2.13 一份交互說明文檔
寫到這裡基本就算完了，其他內容就是針對不同產品的個性化需求，做不同具體設計說明。
三、神助攻
就像文中開頭所說的交互設計規範的目的是提高工作效率，降低溝通成本，提高設計質量；至於這“兩個提高一個降低”能否實現，除了規範外，我這兒還有兩件“法寶”。
一、定製化的組件庫。結合自己的工作特點，定製一個符合自己業務範疇，和工作習慣的組件庫，效率肯定會事半功倍。組件庫不是一蹴而就，而是自己根據業務特點和設計習慣，慢慢調試的。附件是我自己定製的一套符合自己設計特點的組件庫，大家可以在此基礎上修正調整。
二、團隊。團隊之間的默契，配合與協同，才是提高工作效率、降低溝通成本，提高設計質量的制勝法寶。
看我囉嗦了這麼多，我也有點不好意思，就奉上一份交互規範源文件和一份設計組件庫。供大家參考。多多溝通，多多交流。
閱讀更多 杜一筆記 的文章
