原型，是產(chǎn)品經(jīng)理日常生活中必不可少的一樣?xùn)|西，畫原型、講原型，每天幾乎占了一個產(chǎn)品新人50%的時間。如何做好這件事情，成為了每一個產(chǎn)品新人心中的困擾。本文作者就以自身一年多以來的實習(xí)經(jīng)歷，來總結(jié)一下如何做好一份令大家滿意的原型。

一、過于追求樣式特效

剛開始實習(xí)的時候，上級會分配到一些新功能需求，往往會需要去從0-1去畫原型。

這個時候為了完成好任務(wù)，向上級展示自己的原型能力，此時就會花大量的時間去想，我的原型究竟要怎樣去設(shè)計，配什么樣的顏色，然后找來一堆的競品，再結(jié)合自身產(chǎn)品的設(shè)計調(diào)性，將所有的頁面都配好了顏色。

經(jīng)過一段時間的努力后，一份自己看上去“酷炫到爆炸”的原型就這樣設(shè)計出來了，并且自我感覺非常良好，感覺沒人會設(shè)計得比我更好看了。

這個時候拿到上級面前展示，會出現(xiàn)以下情況：

你的上級比較忙，粗略地看了一下：

設(shè)計方面基本ok，但是漏了XXX功能和一些細(xì)節(jié)的描述，需要回去補充一下，補充好就可以跟UI進行溝通了。

然后拿到UI設(shè)計師面前講解，UI心里：你這家伙怎么把顏色全填上去了，這樣我怎么設(shè)計啊。況且這顏色搭配的也太丑了吧，簡直就是干擾我的設(shè)計思路。這個實習(xí)生還是太年輕了，就愛搞這些花里胡哨的，難不成還想把我們UI的工作給干完了。

你的上級比較有空，并且很認(rèn)真去研究你的原型方案：

功能設(shè)計上基本沒什么問題，但是作為一名產(chǎn)品經(jīng)理，不應(yīng)該花太多的時間去搞UI層面的工作，你只需要把你的功能、邏輯設(shè)計好，就足夠了，顏色盡量不要去配。這些都是有UI的設(shè)計規(guī)范的，回去可以把顏色都去掉，產(chǎn)出一份線框圖原型即可，把元素、控件檢查清楚是否有漏掉的。

你看，由于你花太多的時間去做UI層面的工作，導(dǎo)致有些功能的描述并不夠詳細(xì)，這樣UI同學(xué)和開發(fā)同學(xué)會很難開展工作的，回去繼續(xù)修改下，修改好再給我過一遍，然后就可以跟UI進行溝通了。

然后將改好的原型拿到UI設(shè)計師面前講解，UI心里：這個實習(xí)生弄的原型還不錯，各個方面描述的也挺清晰的，終于遇到一個靠譜的產(chǎn)品了，設(shè)計起來輕松多了。

可以看出，作為一名產(chǎn)品新人，其實設(shè)計原型時樣式并不需要太復(fù)雜，只需要產(chǎn)出一份線框圖就已經(jīng)足夠了。難的地方而是在于如何把功能、邏輯描述清楚，讓UI和開發(fā)更易懂。

盡管在我們眼里設(shè)計得多么好看炫酷的原型，在別人眼里也許就是一個四不像的東西。因此，沒必要過于追求樣式和特效，這并不是產(chǎn)品經(jīng)理核心的工作，能用幾句話描述清楚的交互動作，也沒必要去弄復(fù)雜的交互動效。

二、如何畫好原型

一般如果做的是C端產(chǎn)品，團隊中都會有專門負(fù)責(zé)UI設(shè)計的同學(xué)，此時作為一名產(chǎn)品，需要產(chǎn)出的原型就不需要太過于高保真，完成一份比較完善的線框圖即可，當(dāng)我們明確了需求之后，要開始設(shè)計原型了，我們可以這樣去做：

1. 畫原型前需準(zhǔn)備的東西

1）將需求內(nèi)容整理為腦圖

無論需求是出自于產(chǎn)品自己，還是其他需求方，當(dāng)我們確認(rèn)要做某一個需求后，就應(yīng)該將需求的內(nèi)容整理為一份腦圖，以發(fā)散的思維去考慮每一個功能點具備哪些內(nèi)容，以便畫原型時參照。

2）畫一份頁面流程圖

我們首先清楚需要設(shè)計的分別有哪些頁面，將頁面都列出來之后，標(biāo)注好頁面之間是如何跳轉(zhuǎn)的，檢查跳轉(zhuǎn)無遺漏后，初步的頁面流程圖可以已經(jīng)算完成了。在畫頁面流程圖的時候，不需要去考慮美觀的問題，甚至手寫在草稿紙上也是可以的。畫頁面流程圖的目的是讓我們提前想好要設(shè)計什么頁面，在真正畫原型的時候可以邊畫邊核對，防止漏掉頁面。

3）手繪/用axure畫一份原型草圖

為什么需要先畫一份簡單的原型草圖呢？

因為作為一名產(chǎn)品新人，畫出來的原型是基本不可能直接拿出去開需求評審會的。在開評審會之前，必然需要給自己的leader過一遍，一份好的原型，對新人來說通常都要經(jīng)過三番五次的修改才能產(chǎn)出最終稿。

如果一開始就花了大量的時間去畫了一份非常詳細(xì)的原型，那么需要修改的時候，就非常慘了。你會發(fā)現(xiàn)改著改著跟你原來的畫的有著天壤之別，跟重新畫一份一樣。

因此，畫草圖的目的就是更方便我們?nèi)バ薷?，?jié)省下更多的時間。當(dāng)我們拿著草圖在我們的leader、需求方處討論時，及時收集好需要修改的地方，當(dāng)草圖符合他們的要求時，我們就可以參照著草圖來畫出一份最終版的原型。

2. 正式開始畫原型

1）梳理界面元素

當(dāng)我們設(shè)計一個頁面的時候，必然具備大量的元素，此時就要我們仔細(xì)地去檢查、梳理頁面的元素布局。

此處以京東APP中我的訂單“全部tab”舉例進行分析：

頁面頂部：返回鍵、搜索框、篩選功能按鈕、消息中心按鈕。

頁面中上方（訂單狀態(tài)）：全部tab、待付款tab、待收貨tab、已完成tab、已取消tab。

頁面中上方：常購清單跳轉(zhuǎn)圖片。

頁面中下方（商品信息）：商品來源賣家名稱、商品狀態(tài)、刪除按鈕、物流信息文案、物流信息最新更新時間、商品圖片、商品名稱、商品價格、輔助功能按鈕（賣了換錢、查看物流、評價曬單、再次購買）。

2）梳理點擊情況

在APP的頁面中，大部分的元素都是可點擊的，此時我們需要考慮的就是每一個元素點擊的情況是怎樣的：

• 點擊是否可以跳轉(zhuǎn)，跳轉(zhuǎn)什么頁面。
• 跳轉(zhuǎn)的頁面是已存在頁面，還是新頁面。
• 點擊后元素樣式是否改變。
• 點擊后的跳轉(zhuǎn)是否可逆。
• 元素是否需要配置埋點，方便日后統(tǒng)計埋點數(shù)據(jù)。

3）列舉異常狀態(tài)，并給出解決方案

每一個功能在一些特殊的條件下都會出現(xiàn)異常的狀態(tài)，導(dǎo)致頁面無法正常地展示給用戶。因此在設(shè)計的時候，我們就要盡可能去考慮有可能出現(xiàn)的異常狀態(tài)，并給出對應(yīng)的解決方案：

• 無網(wǎng)絡(luò)：固定元素依然展示，自定義變化的元素（如商品信息）不展示，頁面提示用戶網(wǎng)絡(luò)出現(xiàn)問題。
• 訪問次數(shù)過多，服務(wù)器過載：頁面告知用戶加載不出來的原因，提示用戶稍后嘗試或繼續(xù)刷新等待。
• 未登錄狀態(tài)：如果用戶此時是未登錄狀態(tài)（游客），那么就要去分析該頁面是否需要提供給游客進行瀏覽，如上方的訂單信息頁面，是無法展示給游客進行查看的，因為未登錄是無法與平臺之間發(fā)生交易行為，此時需要提示用戶進行登錄/注冊，并提供入口引導(dǎo)用戶操作，當(dāng)用戶登錄/注冊后，還需自動跳轉(zhuǎn)回原頁面。

這幾種是比較常見的異常狀態(tài)，還有很多的異常狀態(tài)需要我們?nèi)ヌ崆翱紤]，甚至有些是在上線后我們才發(fā)現(xiàn)到，發(fā)現(xiàn)后需及時去尋找解決方案。平時在工作中也可以積累一個“產(chǎn)品異常情況庫”，將平時遇到的情況都記錄好，下次在考慮異常狀態(tài)時可以拿出來進行核對。

4）轉(zhuǎn)換角色，體驗功能流程

雖然我們按照已有的流程圖去畫好原型了，但這僅僅是站在產(chǎn)品的角度去設(shè)計產(chǎn)品，而產(chǎn)品上線后是給用戶去使用的。因此當(dāng)我們設(shè)計好原型后，特別是比較大的功能需求，我們應(yīng)轉(zhuǎn)換成用戶的角色去體驗產(chǎn)品。以一個普通用戶的使用習(xí)慣去使用功能，使用過程中觀察是否有難用、反人類的功能設(shè)計.如果覺得自身體驗產(chǎn)品比較難發(fā)現(xiàn)問題，可拉上身邊的同事一起體驗。

三、如何用好原型

1. 撰寫需求文檔

在項目協(xié)同管理產(chǎn)品廣泛被使用的現(xiàn)在，tapd、禪道等協(xié)同軟件已經(jīng)可以起到傳統(tǒng)word等需求文檔的作用了。因此，我們需要將畫好的原型，結(jié)合在線上需求文檔中，一份合格的需求文檔，應(yīng)具備以下內(nèi)容：

• 需求背景：需求背景可以用幾句話簡單的表達(dá)一下，告訴各方你這個需求是來源于哪里？為什么要做？做了之后能解決什么問題？
• 期待上線時間：產(chǎn)品經(jīng)理可以根據(jù)開發(fā)迭代周期，定下一個預(yù)估的上線時間，讓研發(fā)人員心里有個底，能夠合理去安排資源。
• 修改內(nèi)容：需求文檔盡管在開完需求會后也會存在修改的情況，產(chǎn)品經(jīng)理需將每一次修改的內(nèi)容概括到此處，讓項目組成員能及時知悉。
• 需求描述：如果在原型上已經(jīng)把功能描述、交互細(xì)節(jié)備注的非常完善了，那么原型就是你的需求描述，只需把原型存為圖片，放在需求文檔上即可，也可提供axure的鏈接，讓研發(fā)人員點擊即可。

2. 召開需求評審會

當(dāng)需求文檔完善好，leader評審沒問題了。此時就可以拉上UI、研發(fā)、測試同學(xué)一起召開需求的評審會議，作為會議的發(fā)起人，需要時刻注意以下這些要點：

• 提前傳達(dá)信息：在需求會召開前，需提前1~2天拉好群，并將需求文檔發(fā)到群里告知項目組成員，如果發(fā)現(xiàn)問題能提前改好。
• 有邏輯地去講原型（需求文檔）：很有可能一個需求會涉及到多個頁面，在向項目組成員講解原型前，應(yīng)提前將原型進行歸類，按照頁面邏輯的順序去講，這樣做的目的是方便自己講得通順的同時，也讓項目組成員能更好地理解需求。
• 記錄要點，迭代需求文檔：在需求會中，大家可能會提出非常多的疑問，無論疑問是當(dāng)場解決，還是之后再解決，都要將問題和解決方案記錄下來，在會議后將修改的內(nèi)容迭代到需求文檔中，文檔補充完成后，需在群里告知項目組成員需求修改的內(nèi)容。
• 確定項目排期：一般在需求會的最后，產(chǎn)品需要跟各方確定項目的排期：UI什么時候給到設(shè)計圖、服務(wù)器什么時候給到接口、前端什么時候完成頁面的開發(fā)、測試是否能在上線前完成等等。

3. 原型存檔，及時復(fù)盤

成為一名產(chǎn)品新人后，自己做的原型會變得越來越多，對于原型文件，分門別類是非常有必要的?？梢悦總€月歸類為一個文件夾，也可以一個項目歸類為一個文件夾，原型的命名可以寫得更加規(guī)范:“原型名字”+“版本號”+“時間”（例：我的訂單V1.0_0609）。

每一次完成的原型，都是我們寶貴的財富。一些可重復(fù)使用的組件、設(shè)計規(guī)則，我們可以抽離出來獨立保存，當(dāng)重復(fù)設(shè)計的時候，可以盡量減少我們自身的工作量。

四、常見問題

1. 原型丑、慢、有問題

很多人會問到：“我原型畫的好丑怎么辦？”、“我原型畫的好慢，經(jīng)常被別人催”、“同事總說我設(shè)計的原型有問題”等等的一系列問題，如何解決？

其實我認(rèn)為這是一個熟能生巧的過程，畫的丑，就多觀察別人設(shè)計的優(yōu)秀案例，培養(yǎng)自己的審美；畫的慢，就多練，多畫，畫多了，速度就自然提上來了；設(shè)計有問題，就多參考行業(yè)內(nèi)的優(yōu)秀產(chǎn)品，分析別人設(shè)計背后的邏輯和目的是怎樣的，參考借鑒，再結(jié)合自身產(chǎn)品特性去設(shè)計。

2. 團隊中無UI設(shè)計師

這種情況大多出現(xiàn)在一些做B端產(chǎn)品的團隊，團隊中無UI設(shè)計師怎么辦，這個時候UI的工作就落到了產(chǎn)品的頭上了。現(xiàn)在網(wǎng)上有大量原型設(shè)計的模板，例如Ant Design、Element UI等平臺上的一些設(shè)計案例、模板我們都是可以去借鑒的，在別人的基礎(chǔ)上修改，也是一種不錯的辦法。

五、總結(jié)

最后，筆者想說的是，作為一名產(chǎn)品新人，我們應(yīng)該以正確的態(tài)度去看待原型，我們沒必要把原型過于妖魔化。市面上有很多關(guān)于如何設(shè)計原型的課程，多學(xué)點是沒錯的，復(fù)雜的交互、動效會了固然更好，但不會也不用過于擔(dān)憂，畢竟在實際工作中，效率是非常的重要的。

我們做原型，目的就是為了向項目組成員更好地傳達(dá)需求的信息，需求明確，項目才會進展得更順利。因此，把原型設(shè)計得“詳細(xì)”，比“美觀”是更加重要的。因為上線產(chǎn)品的背后，是UI、研發(fā)同學(xué)一步一步照著你的原型去做，你出錯，必然導(dǎo)致最終出來的產(chǎn)品也會出錯，所以重視原型細(xì)節(jié)，是我們每一個產(chǎn)品新人都需要去關(guān)注的事情。

本文由 @Silence 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Pexels，基于CC0協(xié)議