本篇（原型篇-下）主要內容：
原型圖標註，畫開發看得懂的圖
同一個頁面展示所有的交互狀態
頁面跳轉關係圖（不要做孤立的設計）
流程圖，梳理業務邏輯
一、原型圖標註，畫開發看得懂的圖
首先明確原型圖標註是給誰看的，誰最關心原型標準呢？一般而言，開發和設計最關心原型圖標註，開發最關心的是邊界條件、頁面跳轉關係，而設計最關心有頁面和功能遺漏，如反饋狀態和空頁面。畫出功能的所有交互狀態，清晰地顯性化表示交互狀態是作為交互或產品的基本功。一個好的標註滿足以下幾個條件：
標註點的含義，發生的事件
用梳理所有對象和邏輯關係、狀態
模塊化區分和標記
定義好每個標註點的含義和事件
在做交互稿標記之前，定義規範好每個標記的含義，形成統一的規範，使得團隊成員易於理解。如，我比較喜歡用水滴表示標註的功能，用圓圈+箭頭的形式來標識頁面跳轉關係。
用腦圖梳理所有對象和邏輯關係、狀態
下面的原型圖標註以在餓了么商家詳情頁結算訂單為例，先用思維腦圖梳理功能狀態，這樣能避免遺漏一些邊界條件。
模塊化區分和標記
梳理好狀態后再在原型圖上寫產品用例，每個功能做成一個模塊，有利於往後的維護和迭代，例如下面是餓了么的訂單結算功能
二、同一個頁面展示所有的交互狀態
很多的開發和設計，很多耐心看原型圖上的各種標註，特別是時間一長，標註就非常多。如果是做版本的迭代，一要做好標註的版本區分，讓他們第一眼能看到當前版本要做的事情。如果是特別是複雜的功能，盡量在一個頁面上顯示出所有的交互狀態，避免在看原型圖時遺漏。有時候測試驗收階段的很多坑，各種狀態一樓，其實是由於前期沒有做好標註引起的。
下面以微信消息列表頁為例（梳理思路用腦圖是一個好習慣），先用腦圖畫出所有的狀態，補齊所有交互狀態，後面再畫的時候效率會高很多。
如下圖，為微信消息列表頁所有交互狀態的列表呈現：
三、頁面跳轉圖（不要做孤立的設計）
頁面跳轉圖，從用戶的視角，系統化看流程的合理性。頁面流程圖有助於梳理頁面之間的關係。交互設計師或產品經理在工作中，很容易把一個功能做成「孤島型功能」，即這個功能跟其他功能建立聯繫，跟其他功能是孤立的關係。
如在「美啊教育」中要增加一個評論功能，那麼評論機制應該怎麼與現有系統對象建立聯繫？在分析這個問題之前先看看評論和教程的關係，如下圖：
教程中可以看到相關評論，評論系統與教程之間已建立聯繫，但只是單線的關係。
我們再看看美啊這個產品中，還有什麼對象是可以跟評論建立聯繫的？假如，為了刺激用戶去評論，我們可以用積分獎勵的方式，當用戶評論教程后，可以獲取一定的積分，即教程-積分通過評論建立了聯繫，跟現有的積分兌換優惠券、商品也是有聯繫的，仍是於是建立了用戶-教程，教程-積分，用戶-積分的關係，整個積分體系不再是孤立的功能。
用戶-教程
用戶去評論教程
教程的得分可以幫助用戶篩選出更優質的教程
教程-積分
通過評論教程可以獲得積分
積分可以免費兌換觀看教程
用戶-積分
積分可以刺激用戶去評論
用戶用積分可以獲取商品，如優惠券等
於是整個評論體系的頁面關係圖為（補充了部分可能存在的需求）：
四、流程圖，梳理業務邏輯關係
畫流程圖示產品經理的基本功，產品需求，也是流程上的需求。畫流程圖的目的有以下幾點：
確保產品流程的合理性
有效傳達需求
檢驗異常分支
在畫流程圖過程中，切勿遺漏異常狀態，產品經理一般比較關心主要流程，可是開發同學在寫代碼時，要做條件邊界判斷，這個條件邊界即為異常情況。測試同學在寫測試用例時，要窮盡所有的場景，包括正常場景和異常場景，否則出了問題，是要背鍋的...為了避免開發和測試同學不斷詢問你邊界條件，最好在交付交互稿之前用流程圖梳理出來。
常用的流程圖分為單向流程圖和泳道圖（涉及到多個角色），單向流程圖一般描述單一角色完成某個任務的整體過程，如登錄註冊過程、支付流程、填寫資料等。
流程圖包含以下內容：
事項：用戶要完成什麼任務
角色：分別會有哪些人會參與到流程中
信息傳遞：信息在整個過程中是如何傳遞的
異常：有哪些異常情況，如何處理
如快手的登錄註冊流程，先來梳理思路：
事項：用戶要完成快手的登錄註冊
角色：普通用戶
信息傳遞：在觸發登錄註冊框時，獲取用戶的註冊信息，檢驗手機驗證碼，關聯通訊錄數據，獲得第三方登錄數據
異常：最近登錄過該如何處理？手機號無效該如何處理？手機號已註冊該如何處理？
泳道圖
除了要明確事項、角色、信息傳遞、異常等內容，在畫複雜的泳道圖之前，要明確參與角色，再梳理出不同的角色要完成的任務，各個角色之間的交接，整個流程的階段劃分。
如天貓的退貨流程圖作圖思路：
1.明確角色
參與角色有：買家、系統、賣家、客服
2.各個角色要完成的任務
買家：買家收到商品不滿意，可以在天貓上發起退貨，填寫退款申請。如果賣家同意退貨，買家可將商品寄到賣家的收穫地址，寄送方式可選擇自行寄件或者上門取貨。如果賣家收到貨后，拒絕退款，買家可以申請客服介入。
賣家：處理買家退款申請；如果訂單滿足退貨條件，將退貨地址發給買家；賣家收到商品；退款給買家。
系統：判斷買家收穫狀態；檢測買家的退款申請的原因、金額等，生成退款記錄；判斷是否平台先墊付退款；將賣家地址發給買家；系統將買家上門服務申請發送給合作的物流公司；變更退款狀態。
客服：客服介入，判斷雙方責任
3.角色交接
買家將退款申請發送給系統，系統發送給賣家，賣家處理退款申請，賣家將退貨地址發送給買家，買家寄件給賣家，賣家收貨退款。如賣家拒絕退款，買家申請客服介入，客服處理買家或賣家的責任。
4.階段劃分
為了方便理解整個流程，小編把流程分為5個階段：
買家發起退貨申請
系統處理買家申請
買家寄件給賣家
處理退款
整個泳道圖如下：
第五部分的「功能模塊化，可複製」已進化成「交互設計規範」，過年後小編獻上~
當然不會忘記大家的福利啦~
回復關鍵字「axure教程」，可獲得一份axure視頻教程
回復關鍵字「成功創業」，可獲得一份「7大行業成功創業計劃書」