在充滿“互聯網+”這個詞的時代里，產品經理這個職業已經成為這個時代的熱門職業。所以在這樣的一個時代里出現很多各行各業轉做產品的“產品新人”。我也是其中一個！那么作為產品新人在剛入門產品這個行業的時候，工作中接觸最多的就應該是PRD文檔，和畫產品原型圖了。

有些公司因公司需求可能不會要求寫詳細的PRD文檔，而是直接將產品的需求規則寫在原型上面，便于技術、設計等人員使用。因為對于程序猿哥哥們一邊看文檔一邊看原型操作起來不是特別的方便，增加了開發人員的操作時間成本。因此產品新人如何“正確”的輸出一份產品原型變得極為關鍵。下面說一些關于我自己在一年內產品工作中畫原型上遇到的一些小問題和總結。

流程清晰，草圖先行

我不知道大家有沒有過這樣的尷尬經歷？當需求確認后，直接打開Axure開始著手畫原型，畫到一個頁面的時候，就在那抓腦袋停下來想下一個跳轉頁面的布局問題。想著想著，畫差不多了，又感覺似乎之前有些地方的流程和邏輯有點不正確，又需要從新確定一遍流程…..。這樣斷斷續續的畫原型，可以暫定是效率低下的表現，這樣的表現還會影響你自己對后續做產品工作的一個心態。

首先我們的明確一個觀點：軟件只是一個“幫助你實現的工具”，它并不會使你的結果變得多么的神奇。

這個觀點讓我自己在做任何事情的時候都會習慣去先畫一個草圖，如需要用到軟件的時候才會使用。就像考試數學一樣當一個人還沒有絕對把握把正確答案填上去的時候，都需要經過多次的草稿計算。產品原型設計也是一樣，在邏輯和流程確定好之后，需要你先用草圖快速的將頁面畫出來，將每一個頁面中需要放入的一些元素快速組合表現出來。這樣做的好處就是：它不會一開始就把一些細節性的東西在草圖階段就考慮進來，比如說我這個字體放多大合適，這個按鈕放左邊好還是右邊好。當出現邏輯錯誤時，也可以快速將其修改?！皽p少糾結，提升效率”。

相同文字、樣式統一

對于產品新人在初次畫原型的過程中，文字樣式的統一也是容易犯錯的地方。同樣的一段文字，在不同的原型頁面出現時可能是不一樣的內容和不一樣的表達意義。例如：在一個訂單詳情頁面中，這個“金額”的文字表示“訂貨總計”，而在訂單列表中你將它改為“下單金額”。

這樣的錯誤其實只是一些小細節的問題，但是對于程序猿哥哥們來說他們只會執行你最終的需求，所以他們會按照自己的理解去開發，開發完成后你才發現結果和實際需求是不一致的。當這樣的問題出現時其實就已是要“更改需求”了。

在互聯網企業中產品因更改需求被程序猿噴成狗的例子經常發生，所以心理承受能力有限的童鞋盡量避免犯這些小錯誤。當然對于這些小毛病也是有一些解決方案的，比如萬能的“母版”??！多使用“ctrl”C+“ctrl”V！等等?！胺彩露嘧⒁饧毠潯?/p>

實際場景中的真實數據

我自己在從事這一年的產品工作中，遇到過兩次這樣尷尬的場景。當產品上測試環境后發現真實數據比想象中的多出幾十倍，頁面放不下，打開頁面加載速度超級慢的情況。并且更可怕的是你還沒在需求原型中備注說明要求“分頁加載”。

在這個時候你就會為你畫原型的大意來買單了，你會跪求程序猿哥哥們幫你改需求，跪求都還得看臉色。想想這個場景，是不是都害怕了！如果你不想這樣就不要偷這個懶，在畫原型的過程中盡量使用現實場景中會出現的真實數據，并且合理的將這些數據進行歸類。在進入需求評審前，可以多次模擬自己的產品操作流程。最簡單的方法就是拿一份準備好的真實數據，對著你的原型走一遍大流程看看是否能走通、是否還有遺漏的地方。

清晰明了的文件夾

在我們公司產品進入需求評審前，我們都會提前2小時將產品的原型發出來給技術人員們先看看原型，然后才進入需求評審。這樣做的目的是為了在會議前給大家一點時間來了解一下會議的基本內容會議中就可以減少一些溝通的成本。

所以遞交一份文件架構清晰的產品原型也是非常有必要的，因為對于程序猿哥哥們來說，有些相同的頁面都是可以重復利用的，所以在原型文件中，一些沒必要的頁面都可以隱藏掉。比如“查看”頁面，和編輯頁面內容都是一樣，沒有必要單獨畫一個“查看”的頁面，只要你備注清楚就行。（當然這個也因公司而異）。

還有一點值得注意的就是，畫錯了的頁面千萬不要直接刪掉。因為有些東西說不定就是一時沒想明白就做了錯誤的舉動，如果你沒保存紀錄直接刪除后在想找回時，你就得從新開始畫了。

為了避免這種情況的發生，因此我個人習慣還是做個備份的文件夾“作廢”，將所有刪除的頁面都放在這個文件夾中，當有需要的時候在去里面找出頁面。這樣做不僅可以節省一些不必要的時間，也可以看到你在原型制作過程中原型更改的紀錄。如果原型更改紀錄過多也會證明就是你在原型之前的工作沒有做到位。

本人自身也是個剛入行小一年的產品小白，以上內容均屬個人遇到情況，如有表達錯誤或表達不夠清晰的地方還請各位輕噴。

本文由 @傻白田 原創發布于人人都是產品經理。未經許可，禁止轉載。