前面的文章，我們主要溝通了，需求與界面之間存在著距離，這個距離就是設計規劃階段。當越過這段距離，就來到了我們產品經理最為熟悉的環節—原型設計。
原型是承載著我們設計思想的產物。今天，就讓我們系統地來總結一下，抽象的設計思想，怎樣才能夠更好地通過具象的原型表達出來。
內容回顧
大家還記得設計規劃階段的內容步驟嗎？讓我們先來簡單回顧一下吧，因為原型設計是建立在設計規劃的基礎之上，今天的許多內容都與上一期的知識緊密相關。
- 根據需求來設計相關的信息和任務，通過組織信息結構、引導用戶完成任務得到一系列相關聯的界面草圖；
- 然後細化草圖為具體界面，在這個過程中考慮如何讓用戶輕鬆、愉悅、高效地瀏覽和操作；
- 最後，我們要賦予界面一些魔力，讓用戶難以忘記使用產品的體驗。
原型的意義
追根溯源地去探究一些本質的東西，才能夠讓我們在所有的抉擇面前進行理性地判斷，而不是依靠生物的本能反應，或者只是簡單地執行命令。
今天的第一個話題，讓我們先來探究一下原型的意義之所在。
重要性
原型可以說是我們產品經理最主要的產出之一了，尤其是對於初級產品經理來說，畫原型，或許佔據了自身工作的大部分時間和精力。
但歸根結底，原型只是我們設計思想可視化的呈現。從這一層面來說，原型本身並沒有那麼重要，重要的是我們的設計思想，是每一次設計決策的過程。
畫原型的工作，就好比將橙子榨成橙汁的過程，如果把畫原型當做我們主要工作的話，那我們只不過是一個榨汁的“工人”，這種“工人”是隨時可以被替換的。
而設計決策的過程，就好比我們通過用戶調研，能夠判斷出用戶更喜歡的是橙子，而非蘋果，進而我們接下來要榨的是橙汁，而非蘋果汁。這才是產品經理安身立命的根本之所在。
必要性
既然原型並沒有那麼重要，那我們還畫它，或者說耗費精力來畫好它有什麼意義呢？
雖然原型本身沒有那麼重要，但它卻是必要的，其必要性存在於兩方面。
一方面是因為再好的設計思想，也需要合適的載體去呈現，不然只是空洞的想法，即使這個想法再好，再驚世駭俗，恐怕也會讓人覺得虛無縹緲、難以落地。
另一方面是因為，在實際工作中，原型會流轉於業務部、設計部、研發部等各個部門，它是項目開發的標準和依據。如果表達不清晰，那麼在各個環節的流動過程中，就可能出現“蝴蝶效應”，對項目造成極大的影響。
結論：原型本身並沒有那麼重要，重要的是我們的設計思想；但原型又是必要存在的，它是項目開發的標準和依據。
原型的內容
生活中，我們會經常提及一個詞語：“換位思考”。
原型既然是一個在不同人員之間流轉的產物，那我們不妨也從傳遞者和接收者的不同角度來梳理一下，傳遞者想要傳遞一些什麼樣的信息，以及接收者想要接收一些什麼樣的信息。
1. 傳遞者
關於“靜態的界面樣式”，以及“動態的操作效果”，我們在上一篇文章中已經溝通了“信息擺放原則”、“任務引導原則”以及“捕獲用戶放心的八種方法”。
另外，在之前的文章《以“封裝”的思維，來做原型》，也做過專門性的總結。
我會在本文結尾處加上相關鏈接，大家可自行查閱。
這裡呢，我們需要重點溝通一下第三個方面：“隱藏的邏輯說明”。
（1）限制：包括範圍值、極限值。
範圍值：主要指數據的取值範圍。比如下拉菜單、篩選按鈕等，我們在原型上需標註清楚它們的選擇範圍。
極限值：主要指數據的顯示範圍。比如，文本框的一行最多可以顯示多少字數，超過這個字數時，是換行，還是用“...”顯示。
（2）狀態：包括默認狀態、常見狀態、特殊狀態。
默認狀態：主要指默認顯示的文字、數據、選項等。比如搜索框中通常默認展示查詢條件“請輸入xxx。”
常見狀態：主要指對於某一個模塊，經常遇到的一些狀態。比如積分模塊，常見的狀態包括未登錄狀態，登錄後未簽到狀態，登錄後已簽到狀態。
特殊狀態：主要指非正常情況下的樣式、文案、說明等。比如數據加載失敗時，界面展示背景圖，並加上文案提示：“加載失敗了，下拉刷新試試吧”。
（3）操作：包括常見操作、特殊操作、錯誤操作、手勢操作。
常見操作：主要指正常操作時得到的反饋狀態。比如分頁控件，常見的“鼠標懸停”、“鼠標按下”的效果。
特殊操作：主要指一些極端情況下的操作。一般用戶不會這麼操作，但是一旦遇到極端情況，還是要想好應對措施，因為對開發人員來說，不管是正常的還是極端的操作情況，他們都要去編寫對應的代碼。比如類似於微信的功能，用戶添加自己為好友時該怎麼辦。
錯誤操作：主要指用戶操作錯誤時的情況。首先我們應當根據防錯法則，儘量避免用戶出現錯誤。如果有些錯誤無法規避，或者是遺漏了，比如庫存數量只剩下5件的時候，用戶購買時輸入了數字6，這時應該怎麼辦，需要在原型上說明清楚。
手勢操作：主要指用戶使用移動產品時的操作方式。常見的手勢包括點擊、滑動、拖動、放大、縮小、長按、雙擊、橫掃、搖晃等。
（4）反饋：包括提示、跳轉、動畫。
提示：主要指操作後，系統反饋給用戶的文字說明。比如在手機號的輸入框中，輸入了非11位的數字，這時需給出提示信息“格式輸入錯誤”。
跳轉：主要指點擊某個鏈接後，頁面跳轉到哪裡。原型上需註明跳轉時是“原頁面刷新”還是“新頁面打開”。
動畫：主要指用戶操作後，系統通過動畫的方式反饋給用戶。尤其是對於沒有專業交互設計師的團隊來說，產品經理和前端工程師應該共同承擔起這部分工作。
Axure中提供了9種常見的動畫：逐漸、向右滑動、向左滑動、向上滑動、向下滑動、向右翻轉、向左翻轉、向上翻轉、向下翻轉。
2. 接收者
對於接收者來說，除了傳遞者提供了三方面內容以外，還需要了解“修訂記錄”、“信息結構”、以及“任務流程”。
（1）修訂記錄
產品的設計並非一蹴而就的，通常需要通過多次的評審與修改，尤其是對於大型的項目而言，更是如此。有可能每一次更新迭代的內容，還需要牽扯之前內容的改動。
那麼對於接收人來說，更願意明確地看到哪些地方進行了修改，然後重點關注這部分內容就可以了。這個時候修訂記錄就顯得非常有必要了。
修訂記錄通常包含內容如下：
注：對於版本號，我個人的習慣是，評審通過的版本用一級標題表示，例如“v1.1”；對於過程中完善細節的版本，用次級標題表示，例如“v1.1.1”。
（2）信息結構和任務流程
而對於信息結構和任務流程，是我們在設計規劃階段的產物。對於接收人同樣也是需要從整體到局部地來理解產品的設計。不然的話，一頭扎進細節當中，免不了會陷入盲人摸象、管中窺豹的誤區。
原型的技巧
在我們畫原型時，有這樣四條技巧或者說是注意事項，可以提高我們在工作協同過程中的效率。
1. 利用明暗對比與字號大小表達主次關係
界面中哪些元素需要重點展示，或者是哪些信息需要突出呈現，我們可以通過顏色的明暗對比與字號的大小對比來進行表達。
2. 不要把色彩呈現考慮到原型當中
此項內容與第一條的表達並不矛盾。因為這裡的色彩，主要是指視覺效果的色彩。
專業化分工的目的，是為了提高生產效率。作為產品經理，如果也去考慮色彩呈現的話，結果無非是既沒有UI做的專業，又限制了UI的思維。
原型圖，最好是灰白相間的。其中就算是包含色彩，也是邏輯層面的色彩，例如用戶點擊錯誤，出現紅色的提示信息，這個是需要我們在原型中進行表達的。至於這個紅色的色號是多少，甚至是到底用不用紅色，這個仍舊是由UI進行決策。
3. 重要的信息在第一屏進行展示
最重要的內容，尤其是操作按鈕，一定要在第一屏內展示完，否則用戶第一眼看不到，就有可能放棄這個頁面。
這裡給出一個數據供參考：在1024像素 x 768像素的分辨率下，第一屏高度可定為600像素。這裡能夠讓我們感受到第一屏展示的內容即可，至於具體像素的把控，當然還是UI設計師的專業領域。
4. 儘量使用真實符合邏輯的數據內容
界面上的文案隨便填充，僅做示意用，這對產品經理來說可能會覺得很正常，但是把這些內容交付給UI或者開發時，就有可能產生諸多疑問。
例如購物結算的界面設計中，如果界面數據隨便填充，比如“單價”、“優惠”、“數量”、“合計”四個字段下的數據隨意填充，就有可能讓開發對於幾項數據的邏輯關係產生誤解。
結語
文章結束之前，讓我們再多聊一個話題吧，也就是原型的規範或者是說標準組件庫的問題。
規範性能夠給我們帶來的好處不言而喻。
- 對於用戶來說：一致的風格，能夠形成鮮明的產品特徵，增強用戶粘度；
- 對於團隊來說：降低了培訓成本，使新人也能夠快速地融入到工作當中；
- 對於自己來說：避免重複勞動，減少犯錯幾率，大大提高工作效率。
如果你所在的團隊，或者是你自己，還沒有建立原型規範或者是標準組件庫的話，那就從現在開始行動吧。
在當今社會，知識的應用性或許比創造性更加重要，從0到1地建立自己的組件庫，倒不如從互聯網界現有的組件庫中，篩選出適合自己的，來的更加直接與高效。
我也在自己公眾號內的“資料分享”模塊，分享了自己的原型組件庫，如有需要，可自取。
好了，以上就是今天的全部內容了，對於原型，或許每一個產品經理也都要經歷三重境界吧：“看山是山，看山不是山，看山還是山。”
今天的分享，可以看到，我們目前處在“看山不是山”的境界當中。希望有朝一日，我們也能夠“看山還是山”。
閱讀更多 PMTalk產品經理社區 的文章
