產(chǎn)品經(jīng)理前期經(jīng)過對產(chǎn)品的分析研究，頭腦里漸漸形成了產(chǎn)品概念。概念的東西，畢竟只是想象和抽象的。

要生產(chǎn)出面向市場的產(chǎn)品，最終還得落實到實處，于是，產(chǎn)品原型就成了實現(xiàn)概念的產(chǎn)物。

有了產(chǎn)品原型，產(chǎn)品經(jīng)理和團隊成員的溝通就有了共同的頻道，研發(fā)們根據(jù)產(chǎn)品原型逐一實現(xiàn)需求，測試們根據(jù)產(chǎn)品原型逐一驗證需求是否真正實現(xiàn)。個人認(rèn)為，結(jié)合Confluence、Jira里的產(chǎn)品需求，加上產(chǎn)品原型，已經(jīng)足夠形成完整的產(chǎn)品需求文檔。

從無到有，從MVP開始

如果給我1個小時解答一道決定我生死的問題，我會花55分鐘弄清楚這道題到底在問什么。一旦清楚它到底在問什么，剩下的5分鐘足夠回答這個問題。

——愛因斯坦

MVP，即最小化可行性產(chǎn)品，其作用是采用最小的代價，快速在市場驗證想法的可行性。因此產(chǎn)品最初的原型設(shè)計，按照《精益創(chuàng)業(yè)》的說法，就是以實現(xiàn)MVP為目的的。

大體的思路是，圍繞用戶需求里優(yōu)先級最高的、能解決用戶痛點、形成閉環(huán)的需求，來設(shè)計產(chǎn)品最基本的功能和流程。

但是在動手繪制原型之前，應(yīng)該先系統(tǒng)性地想想，產(chǎn)品未來3~6個月，或者6個月到1年的產(chǎn)品形態(tài)是怎么樣的，從MVP開始，怎樣進化到未來的形態(tài)。

如何思考MVP

這里，我虛構(gòu)個例子，為了驗證某種訂閱服務(wù)的在線Web產(chǎn)品（命名為FastX吧）是否可行，在設(shè)計MVP原型的時候，應(yīng)該只考慮實現(xiàn)這個服務(wù)所需要的、最簡單的、但必須是完整的閉環(huán)。

如此一來，基本功能就必須包括了用戶賬號（不然用戶如何訂閱），服務(wù)的核心流程，用戶支付（用戶付費了才能使用服務(wù)）。

用戶賬號可以自行開發(fā)，也可以接入第三方賬號，看具體需求；用戶支付，分國內(nèi)國外用戶，看產(chǎn)品面向的用戶。至于服務(wù)的核心流程，一般而言，應(yīng)該是用戶登錄、服務(wù)流程、流程結(jié)束的過程。

服務(wù)流程可能有3種，流程1、流程2、流程3，每一種的步驟也可能有區(qū)別，我們先考慮最常見的流程1，該流程有3個步驟。這樣的話，產(chǎn)品FastX的服務(wù)流程應(yīng)該是這樣的：

用戶登錄——選擇流程1——步驟1——步驟2——步驟3——流程結(jié)束

通過以上分析，我們確定了FastX MVP的組成部分、核心流程、行為閉環(huán)。

用戶場景下的MVP

產(chǎn)品經(jīng)理最重要的是洞察用戶，在設(shè)計原型過程中，個人的體驗是，代入用戶的角色（好吧，我知道很難）去審視設(shè)計的每一步。

把自己當(dāng)成小白用戶，去想象當(dāng)一個用戶在使用產(chǎn)品時，他們的心理、認(rèn)知處于什么狀態(tài)，他們的視覺焦點和操作行為，是否符合設(shè)計的預(yù)期。

因此確定了MVP后，開始制作原型之前，通過納入用戶角色的思考，我們還需要進一步深入FastX服務(wù)流程的思考，即，用戶在真實場景下，是怎么使用產(chǎn)品的，可能會遇到什么問題，遇到問題后，產(chǎn)品該怎么跟用戶交互。

可以從預(yù)期行為、異常、邊界限制、默認(rèn)值考慮。

1、預(yù)期行為

用戶使用流程1的時候，可能有幾種路徑。如果流程復(fù)雜、路徑多，有時候需要畫流程圖描述，以免遺漏某些細(xì)節(jié)。

接著思考每一種路徑下，用戶操作的每一個步驟下，信息的指引和交互的反饋，以幫助用戶順利結(jié)束流程。如果服務(wù)涉及到工作流，還要考慮狀態(tài)的類型以及轉(zhuǎn)化的條件。

用戶預(yù)期行為通常是我們設(shè)想的、用戶使用產(chǎn)品的理想情況，從起點A開始，到終點Z結(jié)束，一路經(jīng)過B、C、D，每個步驟下如何操作，都在我們的期望中。

2、異常

設(shè)計原型時，這類情況是更需要考慮的。因為不管產(chǎn)品經(jīng)理如何共情，畢竟不是用戶，更何況處于驗證產(chǎn)品階段，很多用戶的行為根本無法預(yù)測。因此設(shè)計的時候，要盡量預(yù)設(shè)各種異常，以及相對應(yīng)的處理方式。

回到剛才例子，我們預(yù)設(shè)用戶的路徑是從A開始，經(jīng)過B、C、D、到Z結(jié)束。

但如果用戶不這么來，在C的時候，返回到B、A，又折回到C，這個時候，整個流程涉及的狀態(tài)和信息將怎么變化？

又比如說，用戶到了D，然后就把瀏覽器關(guān)閉了，等他下次登錄的時候，能不能看到之前的這次流程？如果能，需要怎樣引導(dǎo)用戶進行后續(xù)的操作？

另外要注意的是網(wǎng)絡(luò)情況，網(wǎng)絡(luò)慢、與服務(wù)器連接中斷之類的情況等。用戶使用產(chǎn)品時，尤其是一個流程進行到一半的時候，遇到這些情況，產(chǎn)品該如何表現(xiàn)？

優(yōu)雅降級是一種處理方式，即功能優(yōu)先，去除多余的UI信息展示，以保證服務(wù)能夠繼續(xù)。

一種是信息的漸次展示，只顯示當(dāng)前用戶操作需要的信息，等用戶需要另外的信息時，再逐漸顯示給用戶。

另一種是實時保留數(shù)據(jù)，這樣的話不管網(wǎng)絡(luò)狀況如何，總能保留用戶最新的數(shù)據(jù)，但也因此加重服務(wù)器的壓力。

3、邊界限制

一個提供服務(wù)的在線產(chǎn)品，同一時間能夠承受的服務(wù)數(shù)量是有限制的，即時是只服務(wù)單一的用戶，也需要考慮所能提供的邊界值。

MVP階段，只能同時滿足有限的幾個用戶，但要預(yù)留大并發(fā)量的情況下如何應(yīng)對，以便程序員們做好技術(shù)選型。

涉及到文檔上傳的，要考慮文檔格式、大小、頁數(shù)等的限制，超過這些閾值，產(chǎn)品應(yīng)能友好告知用戶，而不是直接一來就404。

免費用戶和付費用戶，權(quán)限是有區(qū)別的，除了要明確告知用戶，更進一步的，當(dāng)免費用戶因為權(quán)限不足而導(dǎo)致流程沒法進行下去時，要考慮引導(dǎo)用戶后續(xù)操作，等等。

4、默認(rèn)值

設(shè)想MVP時，很多時候，產(chǎn)品經(jīng)理總會構(gòu)想已經(jīng)有了很多用戶、很多數(shù)據(jù)的場景，卻往往忘了一個剛剛發(fā)布的產(chǎn)品，一個用戶都沒有的情況下，整個產(chǎn)品的信息設(shè)計會是怎么樣。

我們經(jīng)常說信息列表，展示用戶的歷史行為記錄，里面會有各種信息，時間、行為、狀態(tài)、操作等，但如果用戶還沒開始使用產(chǎn)品，僅僅是注冊進來的，那么他看到的信息列表，會是什么？

默認(rèn)為空是通常的方式，但可以更近一步，設(shè)計一個“推”的動作，誘使用戶說：開始使用吧！這樣會不會更好？

比如一個社交產(chǎn)品，用戶關(guān)系是核心。作為產(chǎn)品的第一個用戶，如果進去后只看到空蕩蕩的頁面，會是什么感受？所以很多產(chǎn)品會詢問是否導(dǎo)入通訊錄，又或者給用戶推薦幾個值得關(guān)注的人等等。

結(jié)語

以上，是產(chǎn)品經(jīng)理動手制作原型時需要考慮的種種，具體產(chǎn)品有不同的細(xì)節(jié)點，但大的思路就是通過原型，迅速開發(fā)出MVP，以驗證產(chǎn)品概念的可行性。

MVP一旦推出市場，必須是可用的，而不是一個半成品。這就要求產(chǎn)品經(jīng)理在構(gòu)思MVP原型時，不但要考慮用戶正常的使用操作，還要考慮各種異常、邊界限制和默認(rèn)值。