交互設計師如何畫出專業的原型圖？

來自專欄 設計

首先，我們要明確原型圖是畫給誰看的，通常是以下幾類人：開發、部門領導、UI設計師和測試，一個完善的產品流程離不開著幾個角色。

開發通常最關心的是有多少功能，功能的複雜度怎麼樣，邊界條件是什麼，異常情況怎麼處理等。設計師通常關心元素之間的關係，排版和布局。而跟主管彙報，由於主管的事情是很多的，他們通常最關心功能整體的流程、原型的易讀性，以及價值體現。而測試則關心產品需求用戶，輔助他們寫測試用例，以及是否窮盡考慮到各個場景。

那麼，怎麼樣的原型圖才算是專業的原型圖呢？小編總結了工作以來畫原型圖的經驗，總結出了以下經驗。

一. 清晰的視覺層次

突出重要元素，弱化次要元素

頁面是由元素組成的，這些元素包括線、顏色、按鈕等，要做到層次清晰，就要把重要的元素進行強化，次要的元素進行弱化，比如可以通過顏色的飽和度來突出重要元素，通過面積突出重要元素等，引導用戶聚集視覺焦點到重要的元素上。如下圖，通過對比顏色和區域面積的大小，來突出重要元素。

格式塔原理

將相關的元素組織在一起，讓用戶知道這些元素在任務、數據和工具上是相關的，通常用位置表示。相關的元素位置上相近，不相關元素用空間隔開。如下圖，第一個圖為反面例子，信息距離上下一致，用戶無法區分中間的信息是屬於上方還是下方。第二張圖是airbnb的截圖，紅色線框部分明顯與下方隔開一定距離，在視覺上體現為跟上方相關。

二. 視覺流結構

什麼是視覺流？

視覺流是指視覺焦點形成的軌跡，由於眼球生理結構限制，人眼在某時刻只能產生一個焦點。人的這一視覺特性使得人的視線運動通常表現為點到點的跳躍式掃描（saccade），而不是平滑移動。人在閱讀時，一行通常包含4～7個跳動――定位（jump-fixation）的動作，注視持續時間為200～600ms。 因此用戶在對界面持續關注後會留下一系列的視覺焦點，這些視覺焦點的軌跡稱為視覺流（visual line）。

平穩的視覺流結構能幫助用戶快速理解邏輯路徑，減少用戶的認知成本。平穩的視覺流有兩個原則：

• 視覺焦點不宜過多。
• 視覺焦點的路徑邏輯盡量簡單。

如下圖，同為軟體教程詳情頁，左側的視覺焦點過多，視覺流向路徑複雜，而右側的視覺流向路徑簡單，容易理解。

三. 功能預見性

看到一個功能，就知道該功能如何使用，稱為功能預見性。

如，lofter底部導航欄在改版前，只用圖標表現功能，沒法清晰知道每個圖標的含義。改版後，用「圖標+文字」，直接解釋每個圖標的含義，減少認知負荷。

如下圖，為途虎養車某個門店的評價截圖，該門店提供三個服務，分別是輪胎、保養、美容和安裝，紅色方框內為各個服務的得分。當第一次進入這個頁面，默認「輪胎」評價高亮紅色，其他為灰色，潛意識裡不知道點擊是可以切換查看對應評論列表的，即切換查看功能感太弱。

四. 視覺的焦點為信息的焦點

每個頁面都有一個核心功能，這個核心功能不應該被其他功能所覆蓋，特別是當功能越來越多、越來越複雜時。那我們怎麼判斷頁面上哪個功能是信息的焦點呢？如果針對競品調研，頁面上顏色飽和度最高，或者功能佔據區域最大的即為頁面的核心功能，即信息焦點。當設計自家產品功能，要從主流用戶的主流場景，或者功能的商業價值、使用頻率等維度進行分析，一個頁面的信息焦點不宜過多，過多會影響視覺流的穩定。

如下圖，圖1為《風起長林》中的劇集截圖，圖2為點擊後的效果，圖3刻意把進度條拖動方塊變小。我們先來分析進度條的使用場景：查看進度、快進、拖動進度條。當把進度條變小，如圖3，進度條不再成為信息的焦點，視覺效果被弱化，用戶在查看進度、快進時要自己看才能看到當前進度，拖動滑塊時要小心翼翼才能點中。

再看一個生活中真實的例子，有一天點了外賣，配送員說已送達，於是去公司的前台找（前台有很多外賣），找了三遍沒有找到，第四遍終於在僅剩2份沒有人拿的外賣中找到了。

如下圖，我們先來做個場景分析，去找外賣，一般人大多數情況時尋找自己的名字/電話，可是這份外賣單子把騎手的姓名和電話號碼列印得很大，客戶（我）的名字沒有列印，只留了一個小小的號碼，造成了很難找到，然而我又不會刻意去記住騎手名稱和電話。

五. 把簡單留給用戶

複雜度守恆定律（Law of conservation of complexity）由Larry Tesler 於1984年提出，也稱泰斯勒定律（Tesler』s Law）。根據複雜度守恆定律，每個應用程序都具有其內在的、無法簡化的複雜度。

無論在產品開發環節還是在用戶與產品的交互環節，這一固有的複雜度都無法依照我們的意願去除，只能設法調整、平衡。在交互設計中，體現為把複雜留給系統，盡量把簡單的界面呈現給用戶。

如，我們在百度上搜索圖片，輸入關鍵詞—點擊搜索—出現圖片，整個過程是一個非常簡單的過程，即白盒部分是非常簡單的。黑盒部分，在用戶輸入關鍵詞後，系統進行需求識別，識別出來大量圖片，然後將些圖片繼續排序，檢索出用戶最可能希望看到的圖片，然後才會顯示出來，用戶看到的結果系統往往需要進行大量的計算。

比如，你在家裡點外賣和在公司點外賣，無需每次都定位和選擇收貨地址，系統會自動檢測你當前的地理位置，從而給出合適的收貨地址。但是快遞的收貨就不一樣，有可能在家裡下單，收貨地址選為公司，或者在公司下單，收貨地址選為家裡，這個時候就不能根據用戶當前的地理位置進行自動選擇出收貨地址。

其他的還體現為默認給出分類、選項、填空內容等，由輸入變為選擇。顯性顯示用戶最關心的信息，比如在美團上點了外賣，很多人很關心外賣的送達時間，會好幾次進入訂單詳情查看，美團乾脆直接把送達情況展示出來，無需進入詳情頁查看。

根據《簡約至上》，可以大大簡化頁面上的功能。

1. 刪除

• 關注核心功能：增加價值始於改進核心體驗。
• 砍掉殘缺功能：不完美的功能不如不要。
• 刪除掉可能對用戶帶來負擔的細節，如干擾的文字、可有可無的選項。
• 排定功能優先順序：產品的價值不是由功能的多寡來決定的，而是看能否滿足用戶的最高優先順序目標。
• 刪除干擾項。
• 選擇聰明的默認值，減少用戶選擇。
• 避免視覺混亂，讓用戶保持專註。

2. 組織

• 分類。
• 利用網格，呈現頁面布局。
• 利用大小、位置、分層、色標等進行實際組織。
• 關注用戶的期望路徑，而不是邏輯。

3. 隱藏

• 隱藏不常用但不能少的功能。
• 漸進展示：展示核心功能，隱藏擴展功能。
• 階段展示：隨著用戶深入界面而展示相應的功能。
• 適時出現，不打擾用戶，隱藏的目的不是為了藏，而是更好的展示。
• 讓功能方便找到，不能藏得找不到。

4. 轉移

• 把複雜性轉移給擅長的一方，如用戶、後台系統、其他設備。
• 創造開放式體驗，降低用戶受到的約束。

六. 考慮到邊界條件

產品經理或者交互設計師，在做功能時，很容易遺漏一些邊界條件，出現遺漏的原因，主要是在設計功能時只考慮到了主流場景，只做了主流場景下的設計，異常場景或者邊界條件很難考慮到。這裡教大家一個小技巧，寫產品需求用例。在構建產品架構雛形時，用例往往能起到幫助確定功能界限的作用。

用例包括以下內容：

• 用例名稱：此產品/功能的名稱
• 用例編號： 此產品用例的編號
• 角色：操作/執行該功能的角色
• 簡要說明： 最簡化的內容對該需求功能的描述
• 前置條件：執行該功能的前提條件
• 後置條件： 該功能執行完畢後的結果條件
• 主事件流：該功能角色所執行的主要正常過程
• 異常和分支事件流：該功能角色所執行的次要異常過程

如在一個圖片素材網站下載圖片的用例：

如果不寫產品用例，很多人可能只考慮進入詳情頁—點擊下載按鈕—下載成功這個流程，很容易遺漏用戶未登錄狀態下的提示，無許可權下載該圖片的提示，甚至是圖片下架後無法下載圖片的提示。

六. 原型圖標註，畫開發看得懂的圖

首先明確原型圖標註是給誰看的，誰最關心原型標準呢？一般而言，開發和設計最關心原型圖標註，開發最關心的是邊界條件、頁面跳轉關係，而設計最關心有頁面和功能遺漏，如反饋狀態和空頁面。畫出功能的所有交互狀態，清晰的顯性化表示交互狀態是作為交互或產品的基本功。一個好的標註滿足以下幾個條件：

• 標註點的含義，發生的事件
• 用腦圖梳理所有對象和邏輯關係、狀態
• 模塊化區分和標記

定義好每個標註點的含義和事件

在做交互稿標記之前，定義規範好每個標記的含義，形成統一的規範，使得團隊成員易於理解。如，我比較喜歡用水滴表示標註的功能，用圓圈+箭頭的形式來標識頁面跳轉關係。

用腦圖梳理所有對象和邏輯關係、狀態

下面的原型圖標註以在餓了么商家詳情頁結算訂單為例，先用思維腦圖梳理功能狀態，這樣能避免遺漏一些邊界條件。

模塊化區分和標記

梳理好狀態後再在原型圖上寫產品用例，每個功能做成一個模塊，有利於往後的維護和迭代，例如下面是餓了么的訂單結算功能。

七. 在同一個頁面展示所有的交互狀態

很多的開發和設計，沒有很多耐心看原型圖上的各種標註，特別是時間一長，標註就非常多。如果是做版本的迭代，一定要做好標註的版本區分，讓他們第一眼能看到當前版本要做的事情。如果是特別複雜的功能，盡量在一個頁面上顯示出所有的交互狀態，避免在看原型圖時有遺漏。有時候測試驗收階段的很多坑，各種狀態遺漏，其實是由於前期沒有做好標註引起的。

下面以微信消息列表頁為例（梳理思路用腦圖是一個好習慣），先用腦圖畫出所有的狀態，補齊所有交互狀態，後面再畫的時候效率會高很多。

如下圖，為微信消息列表頁所有交互狀態的列表呈現：

八. 頁面跳轉圖（不要做孤立的設計）

頁面跳轉圖，從用戶的視角，系統化看流程的合理性。頁面流程圖有助於梳理頁面之間的關係。交互設計師或產品經理在工作中，很容易把一個功能做成「孤島型功能」，即這個功能跟其他功能沒有建立聯繫，跟其他功能是孤立的關係。

如在「美啊教育」中要增加一個評論功能，那麼評論機制應該怎麼與現有系統對象建立聯繫？在分析這個問題之前先看看評論和教程的關係，如下圖：

教程中可以看到相關評論，評論系統與教程之間已建立聯繫，但只是單線的關係。

我們再看看美啊這個產品中，還有什麼對象是可以跟評論建立聯繫的？假如，為了刺激用戶去評論，我們可以用積分獎勵的方式，當用戶評論教程後，可以獲取一定的積分，即教程—積分通過評論建立了聯繫，跟現有的積分兌換優惠券、商品也是有聯繫的，於是建立了用戶—教程，教程—積分，用戶—積分的關係，整個積分體系不再是孤立的功能。

用戶—教程

• 用戶去評論教程。
• 教程的得分可以幫助用戶篩選出更優質的教程。

教程—積分

• 通過評論教程可以獲得積分。
• 積分可以免費兌換觀看教程。

用戶—積分

• 積分可以刺激用戶去評論。
• 用戶用積分可以獲取商品，如優惠券等。

於是整個評論體系的頁面關係圖為（補充了部分可能存在的需求）：

九. 流程圖，梳理業務邏輯關係

畫流程圖是產品經理的基本功，產品需求也是流程上的需求。畫流程圖的目的有以下幾點：

• 確保產品流程的合理性。
• 有效傳達需求。
• 檢驗異常分支。

在畫流程圖過程中，切勿遺漏異常狀態，產品經理一般比較關心主要流程，可是開發同學在寫代碼時，要做條件邊界判斷，這個條件邊界即為異常情況。測試同學在寫測試用例時，要窮盡所有的場景，包括正常場景和異常場景，否則出了問題，是要背鍋的……為了避免開發和測試同學不斷詢問你邊界條件，最好在交付交互稿之前用流程圖梳理出來。

常用的流程圖分為單向流程圖和泳道圖（涉及到多個角色），單向流程圖一般描述單一角色完成某個任務的整體過程，如登錄註冊過程、支付流程、填寫資料等。

流程圖包含以下內容：

• 事項：用戶要完成什麼任。。
• 角色：分別有哪些人會參與到流程中。
• 信息傳遞：信息在整個過程中是如何傳遞的。
• 異常：有哪些異常情況，如何處理。

如快手的登錄註冊流程，先來梳理思路：

• 事項：用戶要完成快手的登錄註冊。
• 角色：普通用戶。
• 信息傳遞：在觸發登錄註冊框時，獲取用戶的註冊信息，檢驗手機驗證碼，關聯通訊錄數據，獲得第三方登錄數據。
• 異常：最近登錄過該如何處理？手機號無效該如何處理？手機號已註冊該如何處理？

泳道圖

除了要明確事項、角色、信息傳遞、異常等內容，在畫複雜的泳道圖之前，要明確參與角色，再梳理出不同的角色要完成的任務，各個角色之間的交接，整個流程的階段劃分。

如天貓的退貨流程圖作圖思路：

1. 明確角色

參與角色有：買家、系統、賣家、客服。

2. 各個角色要完成的任務

買家：買家收到商品不滿意，可以在天貓上發起退貨，填寫退款申請。如果賣家同意退貨，買家可將商品寄到賣家的收貨地址，寄送方式可選擇自行寄件或者上門取貨。如果賣家收到貨後，拒絕退款，買家可以申請客服介入。

賣家：處理買家退款申請。如果訂單滿足退貨條件，將退貨地址發給買家。賣家收到商品，退款給買家。

系統：判斷買家收貨狀態；檢測買家的退款申請的原因、金額等，生成退款記錄；判斷是否平台先墊付退款；將賣家地址發給買家；系統將買家上門服務申請發送給合作的物流公司；變更退款狀態。

客服：客服介入，判斷雙方責任。

3. 角色交接

買家將退款申請發送給系統，系統發送給賣家，賣家處理退款申請，賣家將退貨地址發送給買家，買家寄件給賣家，賣家收貨退款。如賣家拒絕退款，買家申請客服介入，客服處理買家或賣家的責任。

4. 階段劃分

為了方便理解整個流程，小編把流程分為5個階段：

• 買家發起退貨申請。
• 系統處理買家申請。
• 賣家處理退貨申請。
• 買家寄件給賣家。
• 處理退款。

整個泳道圖如下：