之前花了三篇小文（鏈接在文末），講述如何提升設計師設計作品的內在含金量，今天，我們將重點聊聊如何提升設計作品的外在專業性——交互文檔的呈現形式。

形式感的重要性

交互文檔是交互設計師傳達自己設計理念和具體方案的載體，相當于設計師的一張名片。踏入職場后，面對面的在場交流和討論，是塑造設計師個人氣質及專業魅力的主要方式。

在非在場交流時，交互文檔則替代我們，流通在各項目成員之間，成為體現我們專業素養的一張名片。誠然，大多數時候，我們都會通過在場的設計評審，向大多數項目成員講述我們的設計方案（設計形式考究的交互原型，可以給我們的在場交流，提供更多視覺張力和提示，輔助展現清晰的設計思路和成果，從而讓我們的設計傳達更有說服力）。

然而，根據《艾賓浩斯遺忘曲線》，2天以后，大多數項目成員其實只能記得其中27.8%的信息量。況且，還經常會有部分項目成員，因為各種特殊原因未能參加設計評審。那么，當我們不在場的時候，如何讓我們的名片（交互文檔）代替我們本人，彰顯我們的設計理念和設計的專業性呢？

今天，我就和大家一起來聊一聊交互文檔的形式感設計?？纯慈绾瓮ㄟ^一份交互文檔，在未見其人的情況下，只見其“形”，就彰顯我們設計師的設計理念和專業性！

艾賓浩斯遺忘曲線圖

形式感的必要性

在設計界，有一個經典的“美即適用”原則，這個對于所有終端產品界面設計都適用，對于我們的交互文檔亦是如此。畢竟人都是視覺性的動物，實驗心理學家赤瑞特拉的大量實驗證實：人類獲取的信息83%來自視覺，而第一印象的形成只需要3秒，如果在這短短的3秒內，給我們潛在的“用戶”留下專業的印象至關重要。

作為一名體驗設計師，設計方案的可用性、易用性是設計的基礎。對于我們的交互文檔來說，用戶其實有兩類：最終使用設計的終端用戶，以及圍繞設計落地執行的項目成員。

一直在宣貫以用戶為中心的我們，在為最終用戶創造優質體驗的同時，也需要花點時間，給我們的直接用戶提供良好的使用體驗。

交互文檔在項目團隊中的價值

交互作品的生命周期

在講形式感之前，我們先來看一下交互作品的生命周期圖譜，區分幾個概念。

交互作品的生命周期圖譜

在項目初期的設計發散階段（春筍期），比較提倡用設計草圖溝通，大家可以迅速的繪制多種可能的方案，然后匯集起來對比評估各種方案的優缺點，篩選出一兩個相對優秀的方案及方向進行深入，奠定設計的基調和目標。

交互草圖經歷的時間可長可短，主要用戶是產品經理和組內設計師，簡單的設計，可以直接在原有的交互文檔上略做調整，直接跳過草圖和線框圖繪制階段。大的項目草圖期則相對較長，因為大家會用較長的時間來討論、思考和醞釀，設計方向在調整，設計靈感也總在不經意間涌現，設計草圖在大家的腦中和筆下飛速的迭代。

在項目沒有結束之前，誰都無法阻擋新方案草圖的誕生。（在項目進入開發期，新繪制的草圖已經明確不能本期采納，但依然有下個版本繼續迭代的希望，設計永無止境，相信永遠會有更好的設計在等待被挖掘，這是一個非常正向的循環）草圖繪制，會在貫穿整個項目周期，用戶基本是產品和組內設計師。

這個階段，草圖的形式并不重要，它只是輔助設計師進行快速表達的一種方式，在某些人眼中，它可能都稱之不上是“圖”。

在隨后的設計深入階段（成長期），主要的產出物是設計線框圖，通過簡單的線框圖，讓大家聚焦在大的結構及流程上，保證流程的簡潔性和頁面結構的層次性。設計線框圖經歷時間相對較短，主要用戶依然是產品經理和設計師。

當草圖方案收斂以后，設計師開始按照設計模型，設計原則，平臺規范，產品規范等，運用和突破設計組件，進行產品流程設計和布局設計。這是一個考驗設計師基本功力的階段，不同的設計布局體現了設計師對產品的理解及對設計原則的綜合運用水平。建議設計師可以反復斟酌，多做嘗試，直至找到最佳的布局方式。具體設計原則，可參考《設計師專業表達·法則篇》。

當設計線框圖經歷了設計評審，集各家之訴求于一體之后，交互產出物就步入了成熟期，設計師會再次仔細審視每一個元素，每一個字段存在的必要性和呈現的合理性，像導演一樣，為每一個演員（元素）安排合適的位置，服裝及表演（布局，樣式及交互反饋），避免矛盾和遺漏，以保證整體產品風格的一致性和每一次操作反饋的流暢性。

交互文檔自此步入成熟期（直到設計改版，被新的交互文檔所取代）用戶包括組內設計師和所有項目成員。因為前兩個階段我們設計原型的用戶都是專家型的（產品經理和設計師），而且設計也都還處在一個快速變化的狀態，這期間追求形式感，反而會影響設計的效率和質量。

所以，我們只針對成熟期的交互文檔來談形式感，用穩定的形式感來彰顯交互文檔的專業性和一致性。

交互文檔的形式感

任何一份文檔，首先要有一個精確的產品名稱，讓大家可以通過名稱快速查找和定位文檔。如果名稱模糊，很有可能后期都無法找到對應的文檔，或者需要打開文檔查看具體內容后才能明確文檔范圍，我自己以前也經常遇到這樣的問題，感覺非常的影響效率和心情，后來我就強制自己按照業務線+功能+關鍵變化的方式命名交互文檔。

自從采用這種方式后，我感覺自己查找文檔的效率大大提高，（因為做的項目比較多，經常需要在不同項目中切換，最新的項目可能會同時存在于桌面、iCloud和下載文件中，所以常常通過imac的flash flight功能檢索文件）。采用這種命名方式后，我可以通過文件類型、業務線，功能和關鍵變化多個維度去索引文件，基本不會有找不到文檔和多次打開文檔對比的煩惱啦。（據我觀察，很多設計師都有將最新文件隨手放桌面的習慣，經?？匆姶蟠蟮娘@示屏被滿滿的文件所占據，我自己也是這樣，但積累一段時間之后，我就會統一對桌面的文件進行分類歸檔處理，以保證歷史文件依然可以按類索引）eg：外銷-V6.0首頁、搜索、設置改版- 首頁宮格名站合并版。

打開文檔后，首先是交互文檔的標題欄，建議顯示品牌logo和業務線名稱。這樣在對內外交流的時候，可以快速了解文檔的出處及所屬的業務線。隨后顯示項目名稱、及設計文檔相關的項目人員，包括產品/運營，交互設計師和視覺設計師。這樣對文檔功能及設計有疑問的同學，可以找到對應的同學進行溝通確認。

eg：

交互文檔標題欄

正文第一部分，建議顯示設計分析，eg：

交互文檔設計分析

大家在討論產品功能設計時，總是會追問What-Why-How，了解功能是什么，為什么要做，怎么做。交互文檔，作為產品功能設計的可視化文檔，也需要首先回答這幾個問題，以了解設計的背景、目標和設計理念，方便其他項目人員更好的理解設計。

也許有同學會質疑說，有些資料在PRD中都有了，還有必要在交互文檔中累述嗎？我的回答是有必要。站在設計的角度來說，易取原則是一個基本的設計原則，如果了解你的設計，還需要翻看PRD文檔來輔助，那交互文檔的完整性和可用性都是不合格的。

之所以將設計分析放在第一項，還有一個原因是因為經歷了草圖期和線框圖之后，設計分析內容基本不會再發生變化。而設計細節仍然會持續完善和迭代，所以在交互文檔中，會把相對穩定的內容放置在一起，相對變化的內容再根據相關性組織顯示。

提前撰寫設計分析，可以幫助我們理清并審視設計思路的合理性，當我們在場闡釋設計時，可以提示我們，讓我們的表達更完整，更有條理。當我們不在場時，簡潔的設計分析，可以幫助項目成員更好的理解設計、認可設計，并輔助完成衡量指標的研發。衡量指標的提前確認，可確保設計上線之后有據可看，后續的設計有據可依，以完成數據驅動設計的閉環。

設計分析之后，是可選的【交互流程】模塊，當功能流程比較復雜，跳轉頁面或分支狀態比較多時，我們為了保證交互文檔的可讀性，在【交互設計】模塊會將主流程、分支流程和異常狀態拆開進行描述，這樣可以把每個頁面的細節描述得非常清楚。

但同時，也打亂了所有頁面之間的關系，如果遇到這種情況，我們會在設計分析之后，補充一個【交互流程】模塊，在這個模塊里，將所有的頁面、操作及判斷邏輯融合到一起，方便項目人員理解所有頁面之間的邏輯關系。

交互流程圖

正文的第二大模塊是修訂記錄，修訂記錄的意義在于：告知研發測試最近變更的內容，方便其了解變更內容，并快速定位。

（以前我們用axure繪制交互文檔時，會使用超鏈接/錨點的方式寫修訂記錄，點擊可以直接跳轉到相關頁面或模塊進行展示?，F在統一使用sketch以后，為了方便定位，我們會將修訂記錄及對應的更新的內容以相同的特殊顏色顯示，這樣二者之間的相關性可以通過顏色一目了然的配對，而不需要全部掃描，找到邏輯關系后再腦動確定修訂內容的位置）

修訂記錄

接下來是我們真正的主角——【交互設計】模塊，這個模塊的重點是交互的結構及細節描述。

如果流程簡單，所有流程頁面在繪制時不存在交叉和多個并列的情況，可以直接用一個流程進行展現。

如果流程復雜，很難在同一個流程中顯示所有的頁面及細節，建議將流程按照用戶任務分組，將每個任務拆解出來單獨按照一個流程進行展示。

拆解時，先顯示大部分用戶會經歷的正常流程（即主路徑），再顯示分支流程和異常分支頁面，以減少頁面本身的復雜性。（涉及到流程拆分時，就建議在前面配套展示交互邏輯流程圖，便于研發和測試了解所有頁面關系，也方便后期按圖驗收不遺漏）。當有任務分組時，應顯示任務標題，并在不同的任務之間適當的留白，讓大家可以通過標題和留白，快速的定位模塊。

簡單交互流程示意

流程介紹完畢之后，我們再來看看單個頁面的交互設計形式，如果在一個界面上只有兩三個元素說明，可以直接拉線指向要說明的對象，然后在線的另一邊標注具體描述交互細節即可。

這樣一一對應的關系對于了解元素及其交互細節最為直觀。但是，當一個界面有多個元素要說明時，如果直接拉線說明，可能會因為元素過于密集，使得另一側的交互說明無法完整舒適的顯示。這種情況下，建議按照頁面的布局順序，從上到下，從左到右進行編號，然后在頁面右側空白的地方按照編號順序，從上到下的撰寫交互說明。以和左側頁面元素更好的對應起來。

交互細節描述示意

交互文檔內容完成后，要注意調整各模塊/元素之間的樣式及間距，以保證相似模塊設計樣式的一致性和間距的一致性，通過外在設計的一致性烘托內在設計的專業性。建議將常用的交互元素和樣式都做成組件，方便統一調用和修改。正所謂磨刀不誤砍柴工，這個設計組件搭建過程可能會耗費一定的時間，但一旦搭建完成，后續使用的便捷性和效率都大大提升。

最后，再簡單聊一下【交互動效】。

靜態的交互文檔，對于描述動效來說，始終是不直觀和不友好的。對于交互動效的呈現，對程序員GG們最友好的提供方式，當然是通過動效軟件直接導出代碼，讓研發哥哥們直接嵌入代碼套用。

今年在ixdc主題峰會上，有幸聽到華為消費者BG軟件部副總裁——毛玉敏老師的分享，在華為內部，就有可視化的動效制作編輯軟件，設計師可以通過簡單的可視化的參數調整和模板得到想要的效果，然后導出給研發GG們。聽起來真是華為設計師們的福音，再也不用和研發GG們爭論動效的實現難度和細節調整了。我們公司的研發GG們也想要這樣的待遇，所以曾經給我們推薦了一款叫lotti的軟件，也能做到將動畫轉化成代碼嵌入，但依然要依靠復雜的AE軟件制作對應動效，并且按照特定的格式進行輸出，偶爾還會遇到導出代碼效果與AE中動畫不一致的時候，還得依靠設計師或者研發GG們手動調整。

動效json文件

能夠做到這樣代碼級的動效輸出，當然是最友好的。如果做不到，通常的做法是輸出一個視頻（可以自己設計，也可以錄制一個）給到研發GG。這是我們之前最常用的方式，畢竟APP內大多數動效其實還是比較簡單的，在設計時參數也都是設計師手動調節優化的，提供視頻的同時，可以把這些時間參數和運動參數一起提供，可以略微減少一些開發的難度。

動效標注文檔

當然，對于最為簡單和常規的出現/消失，漸變，平移，縮放等交互動效，也可以通過文本描述的方式進行說明，只要能和研發GG們達成共識就好。

交互文檔的形式感就聊到這里啦，你是否還有一些表現交互文檔形式感的設計，可以增強交互文檔的可用性和專業性呢，歡迎留言和我一起探討o(*￣︶￣*)o

相關閱讀

給你的設計加點“理”——《設計師專業表達·法則篇》&《設計師專業表達·數字篇》

給你的設計加點“據”——《設計師專業表達·數據篇》

給你的設計加點“面”——《設計師專業表達·形式篇》→本篇

給你的設計加點“料”——《設計師專業表達·細節篇》還沒動筆，爭取下周見，哈哈~~

本文由@悅悅兔 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議