起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識用戶體驗設計之路（三）：原型是設計的表達
上一篇文章，我們主要溝通了，需求與界面之間存在著距離，這個距離就是設計規劃階段。當越過這段距離，就來到了我們產品經理最為熟悉的環節—原型設計。
原型是承載著我們設計思想的產物。今天，就讓我們系統地來總結一下，抽象的設計思想，怎樣才能夠更好地通過具象的原型表達出來。
一、內容回顧
大家還記得設計規劃階段的內容步驟嗎？讓我們先來簡單回顧一下吧，因為原型設計是建立在設計規劃的基礎之上，今天的許多內容都與上一期的知識緊密相關。
- 根據需求來設計相關的信息和任務，通過組織信息結構、引導用戶完成任務得到一系列相關聯的界面草圖；
- 然后細化草圖為具體界面，在這個過程中考慮如何讓用戶輕松、愉悅、高效地瀏覽和操作；
- 最后，我們要賦予界面一些魔力，讓用戶難以忘記使用產品的體驗。
二、原型的意義
追根溯源地去探究一些本質的東西，才能夠讓我們在所有的抉擇面前進行理性地判斷，而不是依靠生物的本能反應，或者只是簡單地執行命令。
今天的第一個話題，讓我們先來探究一下原型的意義之所在。
1. 重要性
原型可以說是我們產品經理最主要的產出之一了，尤其是對于初級產品經理來說，畫原型，或許占據了自身工作的大部分時間和精力。
但歸根結底，原型只是我們設計思想可視化的呈現。從這一層面來說，原型本身并沒有那么重要，重要的是我們的設計思想，是每一次設計決策的過程。
畫原型的工作，就好比將橙子榨成橙汁的過程，如果把畫原型當做我們主要工作的話，那我們只不過是一個榨汁的“工人”，這種“工人”是隨時可以被替換的。
而設計決策的過程，就好比我們通過用戶調研，能夠判斷出用戶更喜歡的是橙子，而非蘋果，進而我們接下來要榨的是橙汁，而非蘋果汁。這才是產品經理安身立命的根本之所在。
2. 必要性
既然原型并沒有那么重要，那我們還畫它，或者說耗費精力來畫好它有什么意義呢？
雖然原型本身沒有那么重要，但它卻是必要的，其必要性存在于兩方面。
一方面是因為再好的設計思想，也需要合適的載體去呈現，不然只是空洞的想法，即使這個想法再好，再驚世駭俗，恐怕也會讓人覺得虛無縹緲、難以落地。
另一方面是因為，在實際工作中，原型會流轉于業務部、設計部、研發部等各個部門，它是項目開發的標準和依據。如果表達不清晰，那么在各個環節的流動過程中，就可能出現“蝴蝶效應”，對項目造成極大的影響。
結論：原型本身并沒有那么重要，重要的是我們的設計思想；但原型又是必要存在的，它是項目開發的標準和依據。
三、原型的內容
生活中，我們會經常提及一個詞語：“換位思考”。
原型既然是一個在不同人員之間流轉的產物，那我們不妨也從傳遞者和接收者的不同角度來梳理一下，傳遞者想要傳遞一些什么樣的信息，以及接收者想要接收一些什么樣的信息。
1. 傳遞者
關于“靜態的界面樣式”，以及“動態的操作效果”，我們在上一篇文章中已經溝通了“信息擺放原則”、“任務引導原則”以及“捕獲用戶放心的八種方法”。
另外，在之前的文章《以“封裝”的思維，來做原型》，也做過專門性的總結。
我會在本文結尾處加上相關鏈接，大家可自行查閱。
這里呢，我們需要重點溝通一下第三個方面：“隱藏的邏輯說明”。
（1）限制：包括范圍值、極限值。
范圍值：主要指數據的取值范圍。比如下拉菜單、篩選按鈕等，我們在原型上需標注清楚它們的選擇范圍。
極限值：主要指數據的顯示范圍。比如，文本框的一行最多可以顯示多少字數，超過這個字數時，是換行，還是用“…”顯示。
（2）狀態：包括默認狀態、常見狀態、特殊狀態。
默認狀態：主要指默認顯示的文字、數據、選項等。比如搜索框中通常默認展示查詢條件“請輸入xxx?！?/p>
常見狀態：主要指對于某一個模塊，經常遇到的一些狀態。比如積分模塊，常見的狀態包括未登錄狀態，登錄后未簽到狀態，登錄后已簽到狀態。
特殊狀態：主要指非正常情況下的樣式、文案、說明等。比如數據加載失敗時，界面展示背景圖，并加上文案提示：“加載失敗了，下拉刷新試試吧”。
（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地建立自己的組件庫，倒不如從互聯網界現有的組件庫中，篩選出適合自己的，來的更加直接與高效。
我也在自己公眾號內的“資料分享”模塊，分享了自己的原型組件庫，如有需要，可自取。
好了，以上就是今天的全部內容了，對于原型，或許每一個產品經理也都要經歷三重境界吧：“看山是山，看山不是山，看山還是山。”
今天的分享，可以看到，我們目前處在“看山不是山”的境界當中。希望有朝一日，我們也能夠“看山還是山”。
下一期讓我們繼續聊一聊原型評審那些事兒，不見不散。
相關閱讀
#專欄作家#
曉莊同學；公眾號：曉莊同學產品筆記，人人都是產品經理專欄作家。智慧校園領域的B端產品經理。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
有一點小小的不同意見，原型當中一定要把一些業務規則進行標注嗎？從客戶角度來說，原型是最直觀輸出的東西，客戶在瀏覽的時候不會在意那些業務規則、數據范圍等細小的東西，他們只是看看流程、屬性、界面展示是否符合自己的要求，在前述都得到認可的情況下，一些細節的業務規則是后續要一一確認的事情。本來可以很簡潔的界面呈現給客戶，加上各種各樣的標注后反而凌亂且不易讀。從研發角度來說，原型是研發過程的參照標準之一，僅僅作為可視化界面的標準，很多復雜的業務邏輯判斷還是要通過文字進行精準描述，僅通過原型界面的標注，空間有限，說不清道不明的東西太多了，并且界面的標注東一塊西一塊，容易遺漏，倒不如文字一條一條將所有的邏輯判斷、數據范圍、權限控制等業務規則精準表達。
你這個回答也沒錯。
但對與錯是要放在特定的環境當中，就比如你說的第一種，如果原型的交付對象是客戶，那肯定不用太多細節的東西。但很多時候，原型的交付對象都是開發吧，如果是開發，那就需要了。
第二種情況，如果是大項目，那也沒問題，還得配一個專門的幾十頁甚至上百頁的PRD。如果是敏捷迭代的，一周一個版本的小項目，那PRD都可以沒有，直接原型+標注的形式確實是ok的~
感謝曉莊老師回復。哈哈哈哈哈，敏捷迭代的情況，我現在是結合禪道，在每一個拆分的需求里面把需求描述、規則什么的寫清楚。也是個辦法