起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識宏觀角度：原型圖的交互說明該怎么寫
原型圖的交互說明是針對原型圖內容元素的解釋文字，可以從宏觀和微觀兩個層面展開分析，本文結合圖例主要說明宏觀角度輸出交互說明應該注意的地方。
原型圖的交互說明是針對原型圖內容元素的解釋文字。
清晰準確的交互說明能夠起到以下作用：
- 減少交互設計師與產品上下游人員的溝通成本
- 提升協作效率
- 避免項目返工延期
原型圖交互說明的輸出，可以從宏觀和微觀兩個層面展開分析。
宏觀角度是指輸出交互說明應該注意的事項，以及應用組件化思維提升輸出交互說明的效率。微觀角度是指單張原型圖應該包含的交互說明的具體內容。
本文結合圖例主要說明宏觀角度輸出交互說明應該注意的地方。
宏觀層面
1. 交互說明的文字要簡短精煉
這里有個坑大家注意。
估計很多交互設計師和我一樣在實際項目中有這樣的困惑：產品需求文檔里的功能點邏輯描述已經相當全面，還有必要再次寫到原型圖的交互說明里嗎？
這里我們需要明確：只要在交互說明里把有關交互的主場景和各種狀態作簡要描述即可，開發人員如果有困惑會仔細查看PRD的。
如上圖是PRD中關于Banner功能的描述，那么在交互說明中只需要提取出以下幾點：
- 用戶點擊Banner圖跳轉至對應頁面；
- Banner圖少于2張時，不進行自動輪播，也不展示翻頁點；
- Banner圖大于等于2張時，進行自動輪播，且展示對應圖片數量的翻頁點；
- Banner圖最小張數為1，最大張數為5；
- 用戶可左右滑動切換Banner圖片，同時Banner每隔5秒自動輪播無限循環。
2. 頁面元素的交互說明
頁面元素的交互說明主要由以下模塊構成：元素基礎設置、交互動作、跳轉邏輯、限定極限值、狀態及狀態之間轉換的描述。
如下圖，仍然以上面的Banner功能點舉例說明：
3. 頁面內容盡量使用符合邏輯的真實數據
避免使用XX符號或者無關聯的數據替代，這樣寫出的交互說明貼近真實場景，容易產生代入感，使閱讀者清楚明確。
如下圖，搜索默認詞、導航tab切、以及內容文案都給的是上線后的真實數據。
4. 交互說明考慮內容元素的特殊狀態
包括極限值/錯誤提示/判斷規則等，要在交互說明中明確指出。
如下圖1，同一個頁面中標題出現普通狀態與極限狀態；如下圖2，上傳文件的不同狀態給出相應的文案提示并解釋說明。
5. 交互說明的排版布局要有助于閱讀
交互說明有多種排版布局方式。
比如：原型圖內容元素標上數字放置在上方，對應的交互說明放置在原型圖下方；或者原型圖在左側，交互說明在右側，有的設計師也會把元素和對應的交互說明用連接線連起來。
因為不同的排版布局方式各有利弊，所以具體采用哪種布局方式要根據所做項目的情況，以及開發人員的閱讀習慣而定。
如下圖是我平時習慣的輸寫方式：
6. 頁面之間邏輯跳轉的關聯性需要交代清楚
比如點擊某個按鈕，跳轉到哪個頁面，可以在交互說明中寫清楚標號或頁面名稱。
7. 交互說明組件化
類似于設計的控件庫，我們在項目中寫交互說明寫多了就會發現，既然元素可以調用控件庫快捷使用，那么該元素的交互說明也可以歸類入庫，在需要的時候直接拿出來根據具體情況調整使用。
比如上面提到的“Banner圖交互說明”，就可以保存一份在交互說明庫中，等后續畫原型圖再需要時，直接調取出來根據情況微調即可。
這樣做的目的：使用時快捷調用，修改時快捷修改。
8. 頁面交互說明建議平鋪直述，不建議使用動態效果
原型圖的動態效果適合頁面跳轉的演示，但不利于交互說明的呈現，會給視覺設計師和開發造成閱讀困擾。
9. 交互說明應該依據具體情況不斷調整完善
如果業務和產品臨時調整需求，或者交互評審后需要對原型稿進行修改，則交互說明也要進行相應的修改。
另外，項目在進展過程中如果發現交互說明有遺漏現象，則需要隨時補充完善。
微觀層面
單張原型圖交互說明的具體內容，其實和交互自查表的內容是相關聯的。
可能包含：特殊場景、操作與反饋、頁面狀態、數值限制條件、功能、流程、文案、動效、控件、彈框等。這塊后續梳理了再給大家分享。
作者：Viksea，微信公眾號：Viksea（ID：viksea-ux）
本文由 @Viksea 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議。
有用
我現在都是畫好原型 在原型的右邊直接文字說明 再用線頭連接 ，這樣做有什么弊端呢，作者你的這種方式很好，不過頁面層級過多，是不是不太時候在同一個平面敘述連接？
1.你的這種輸寫方式也沒問題，這個主要是依據不同公司開發的閱讀習慣，以及自己的習慣決定，不同方式沒有好壞之分。2.頁面層級如果過多，尤其是子流程比較復雜的情況，確實不適合同一個頁面平鋪直敘，我的習慣是將子流程單獨建一個子頁面寫明。這樣只要在主頁面中說明到某某頁面查看詳情即可。
對比這些說明我就寫的有點粗糙了，有些地方也沒有考慮到，寫的很棒，值得學習！
??
期待微觀層面
這些方法基本都有使用，個人認為最難的是項目實施過程中需求變更的實時補充完善。
是的，如果變動比較多，意味著修改也比較多。所以我暫時想到建立交互說明組件庫的方法，盡可能的提高修改效率。
動態加關鍵指標和靜態加標注個有優略。具體看環境吧。不過這細致和效果值得學習。我都是比草圖強不了多少加標注哈哈。
是的，要根據項目要求，出圖目的等具體決定形式。
請問“某某的尺寸/某某的字數限制，由視覺決定”是每個公司慣用的說法嗎？會不會讓UE或UI覺得這是坑？
不會，起碼我所在的項目沒有因為這些背鍋的。一般交互說明中指明最大范圍限制由視覺決定，然后視覺依據不同屏寬決定限制條件，還要考慮不同尺寸屏幕的適配，為了盡可能提升開發效率，一般對極限值采用相同的判斷機制。這些在后期灰度測試時，也是需要交互和視覺設計師共同跟進的。
問一下，怎么保存交互說明庫比較好，有線上的嗎
這部分我也在搜集整理中，暫時沒有很好的模版。。。
有可以用的嗎？就是看到新知識想get一下，就隨意推薦幾個就行
直接放母版里
已關注 哈哈 ~ 多多交流 ??
??
在實際開發過程中，交互設計師更看重原型稿，所以希望在原型圖上進行標注，他好明白這里采用什么樣的樣式；但是對于開發來說，他們希望直觀的看到每個頁面的功能點，這樣的話他就會很好的知道怎么寫接口，所以程序員們希望得到的是一份word文檔或者是excel表，這不是權衡的問題，在實際工作中，我為了降低工作的重復，我會在原型上做好交互，不詳細做批注，但是在word文檔和excel中會寫的非常仔細，經驗之談
相比于word或excel，程序員應該更喜歡看原型圖。一般程序員理解需求的流程是：故事講解(了解需求整體情況）–>>看原型圖及圖中標注的需求說明（對功能效果有個感性的認識）–>> 在技術架構底下，寫功能，查文檔（或原型或word,目的在于查看細節規則的定義等） 。
??
是的，我司的程序員對于我做的原型圖就經常不仔細看，最后在開發過程中某個功能點沒有被開發到這個鍋怪到我的頭上，現在我每做一個新功能都會原型圖附上word，這樣都有備案，省的再過來責怪我?？戳宋恼缕鋵嵰舶l現自己的原型圖標注確實沒有做好，我還需要多學習
其實這個要根據不同公司工作流來決定：有的公司開發是從產品經理的需求文檔中獲取功能點信息，所以原型圖的交互說明只需要說明有關交互的部分就可以了（很多公司開發連原型稿的說明都不會看，大事小事都找產品，這時候產品就干的比較辛苦了）。還有的公司開發會仔細看交互稿，但我認為附上word有點超出交互職責范圍了，也多余消耗交互設計師精力。我認為最好的方式是：開發拿著需求文檔和交互稿對比查閱，基本就完善了所有方面。
不同環境使用不同方法吧。除了特定 標注外，研發更喜歡看到實際效果進行動態設計，而不是基于靜態加大批量標注。只要幾個關鍵指標即可。prd我就沒見幾個看過的，看了也還是繼續問哈哈。
一般中小型企業都是這樣，直接看原型。什么word prd統統不看，看了就等于 浪費時間
我一般是把業務流程、功能描述和交互一起做到原型圖上
大型公司就不一樣了，他們要求比較嚴格， 為得是項目交接順暢（人員更替或產品迭代維護都需要用到的）。如果是要給外包公司開發的話，那就比較苦逼了，每一個細小的點都要寫上去，哪怕是大家都知道的點。
感謝分享
期待微觀層面的詳細說明。
還想學習的就是主要是針對特殊情況的了解學習，常規上整個流程還行，總是對于特殊情況、異常情況會有遺漏。
你提到的是特殊狀態的頁面及說明，我一般會把這種情況單獨拎出來說明。總會遺漏是交互自查的問題，做完交互稿最好對著交互自查表走查一遍，查漏補缺。
我也是用的這種方法，樓主的有些標注方式我沒使用，還是值得我借鑒的，謝謝~
希望說說較為深入的原型規范技巧。???
你指的哪方面呢？如果是畫原型圖規范技巧可翻看我之前的文章。如果是原型圖交互說明的規范，除了本篇從宏觀角度分析之外，還有微觀角度“原型圖交互說明的具體內容”，這個后續有空梳理了會再次分享的～～