作者：Jocelyn醬
本文在PMCAFF社區發布（www.pmcaff.com），轉載請註明作者及出處。
在做產品的這幾年，總會有人來問我：
我想做一個軟體，我該怎麼畫原型圖？
我剛轉行做產品經理，我該怎麼畫原型圖？
隨著帶產品新人經驗越來越多，一遍遍糾正新人在畫原型圖中的缺點，陸續就沉澱了一套通俗易懂的方法。
希望未來還有人問我相同問題，我可以用這篇文章解答TA的相關問題。
一、動手之前
進行用戶使用的app產品設計，一般在正式畫app的界面前要確認以下信息，這些信息和界面息息相關，千萬別偷懶，我建議新同學們直接動筆記錄回答，在界面設計中反覆回來查看。
（1）用戶來這個產品/你要設計的功能 是幹嘛的？你為用戶提供了什麼價值？這個價值真的是用戶所需要的嗎？
（沒有價值、價值不是用戶需要的，或者需要這個的用戶數很少，建議降低優先級，去想更核心的功能）
（2）你認為這個產品/你要設計的功能 和市場上同類app差異化是什麼？共同點又是什麼？你認為你進行的需求設計在哪些方面和競品要有差異化？這種差異化是否與產品給用戶核心價值相關？
（如果差異化不成立，不建議天馬行空的浪費研發成本，這種差異化的存在可能是：產品定位不同、產品目標群體差異等
（3）確認你設計產品/功能的目標用戶。調研和了解這群人的畫像。
（功能的用戶畫像不一定是產品的用戶畫像，比如直播間家族用戶群可能是公會用戶為主，而非app所有人）
（4）確認你設計產品/功能用戶核心任務。張小龍說：一個產品只能有一個主線功能。
所以，判斷自己這個產品/要設計的這個功能 主線的用戶任務是什麼？
好的，以上想明白了。你在產品設計/功能設計上的背景是想明白了。
這裡建議產品實習生等新同學主動和上級溝通明白這些邏輯，要不然設計出的原型圖就是靠自己想像的背景畫出來的。
二、開始設計產品
開始設計產品，錯誤做法：
一上來就打開軟體，開始畫圖。邊畫圖邊想這個頁面要什麼功能、什麼信息。
這會導致你的原型圖走偏，和你要設計這個產品/功能的目的不一致，也不能系統的顯性出產品/功能的差異點。
所以，我建議複雜的產品/功能設計還是多花點時間在前期的思考上，把畫圖留在最後。
接下來我列一下畫圖之前要寫出的內容，其中部分內容也會在標準的需求文檔中體現。（需求文檔結構我在文末列出來給大家哈！）
1、用例圖
用例圖類似圖中這種。（圖片來源於網絡）
用例圖包含：角色、幹什麼事/任務
【價值】：幫助你整理你的設計中需要涉及到的角色（普通用戶 or 運營人員 or kol ）。尤其是梳理需要運營後臺設計的功能，這個賊好用。
2、流程圖
流程圖是C端設計中常用的。（圖片來源於網絡）
我經常用的是用戶任務流程圖。寫清楚用戶在產品/功能中主要完成任務的流程。
【價值】：會幫助你梳理設計中所需要的功能、需要判斷的關鍵信息（如登錄與否，是否已有×數據），不同關鍵背景用戶完成任務流程的差異。
當然，app設計還會用到「業務流程圖」，業務流程圖是為了讓產品經理更清楚產品底層的流程，和其他業務模塊交互情況。
比如：
一個內容發布的用戶任務流程圖是：用戶點擊發布按鈕，判斷是否登錄，編輯blabla，點擊完成按鈕。
一個內容發布的業務流程圖是：用戶發布內容，內容進入第三方平臺自動化鑑定，鑑定完到運營後臺，運營人員審核。
業務流程圖如下：（圖片來源於網絡）
在畫原型圖之前，用到用戶任務流程圖比較多。
在進行模塊和業務設計之前，用到業務流程圖比較多。
C端需求文檔根據需求複雜度和具體功能可以選用不同流程圖
3、信息結構圖
信息結構圖是用來說明：
產品頁面或者產品某個內容有什麼具體信息欄位的。
我舉個例子：
如果我需要設計一個電商商品的模塊，我需要思考商品都有哪些信息欄位，比如：商品封面圖、商品名稱、商品評價等。我考慮首頁需要推薦商品，所以商品的信息架構中我會加入「是否編輯推薦」這個欄位。
但同時，我需要輸出一份C端商品詳情頁面的信息結構，讓別人來幫我設計商品頁面原型圖。那麼我不會把「是否編輯推薦」這個欄位寫上去，因為我不希望C端顯示出來。
我還需要設計一個商品列表頁面。商品列表頁面中每個商品露出的信息欄位一定是在商品的信息欄位中的，也會少於C端商品詳情頁顯示的信息。因為列表位置有限，我只能挑選更核心的欄位拿出來展示。
總結就是：頁面的信息結構整理的只是當前這個頁面能看見的信息。有一些信息欄位是存在，但不在這個頁面展示，或者是在使用但用戶沒看見的。
產品從0-1的過程中，我們更需要設計模塊，和具體內容的信息欄位。
成熟產品的功能/頁面需求，梳理的更多是頁面信息結構。比如：微博的內容有很多信息欄位，如果讓你設計一個微博內容站外分享打開的H5頁面，你會挑選哪些信息展示呢？會新增哪些信息呢？
【頁面信息結構的價值】
讓你更關注於目標用戶在特定場景下需要的信息。
如果一開始就上手畫圖，邊畫圖邊思考這個頁面需要什麼信息，容易被圖中的排版幹擾，忽略場景下用戶最需要的信息欄位。
所以，頁面信息結構的輸出過程，更像是讓你梳理明白內容的所有信息欄位，結合用戶特徵和場景篩選出你這個頁面最需要的信息欄位的過程。
新手產品可能一開始難抽象思考信息結構，那也可以邊畫圖邊思考。不過我建議畫圖後，再審視下頁面信息是不是用戶需要。
4、原型圖
終於到原型圖這一步。
上面我們梳理了：產品/功能價值、目標用戶畫像、核心任務、競品差異化、用戶用例、用戶任務流程圖、頁面信息結構。
基本可以確認：需要幾個頁面，不同頁面的功能點是什麼、頁面除了功能按鈕，還需要展示的信息是哪些。
那開始排版吧！
排版可不是排列組合的事情，我們是需要解決：
（1）用戶第一眼感受和認知是什麼、
（2）用戶看了頁面後是否優先獲取了自己最想知道的信息，是否足夠吸引用戶查看？或者幫助用戶解決問題？
（3）核心任務的操作是否可隨時隨地找到。是否符合用戶交互習慣。
一般來說，我們會借鑑用戶感知類似的產品界面設計，也會在自己想體現的核心差異化上做創新。
這個需要大家多分析競品和多練習啦～
附錄：需求文檔格式
我列一下標準的需求文檔的格式。基本C端的功能設計需求、新的產品模塊設計都適用。
其他技術類需求、B端需求就自行辨別哈。
（1）人員分工
確認自己需求所需要的人員資源，後期團隊確認後，添加到具體人名，方便團隊成員查閱和責任到人。
常用的角色有：產品負責人（就是自己）、技術負責人、客戶端、前端、服務端、AI、設計、測試、運營
（2）需求背景
講清楚這個需求是如何產生的。把自己的思考邏輯寫清楚即可。比如發現了什麼用戶的什麼需求沒被滿足。
如果有量化數據，也建議加上，說服力更強。
（3）需求目的
自己需求的主觀目的，比如提升什麼、改變什麼、解決什麼
（4）需求目標
需求最終考量是否達成目的的量化數據，也可以作為自己需求的北極星目標。
（5）核心邏輯
向團隊解釋你做這個需求方案為什麼能達成需求目的。
這裡是要說明白自己方案的思考邏輯，同樣達成目的的多種方式裡，為什麼採用了這個方式方法。
（6）用戶任務流程
不解釋了，看上面具體說明。
（7）需求詳情
需求詳情包括：
需求項目——哪個功能點、哪個頁面
需求原型圖
需求說明——結合原型圖說清楚自己的具體需求，包括什麼信息欄位，欄位從哪裡產生的，欄位格式，欄位特殊說明；功能需求、特殊情況說明、特殊提示。
（8）運營需求
配套的運營需要幹的事情。
一個好的產品經理是縱觀全局的，不是生完孩子就啥也不管了，那你的功能可能永遠都跑不出來。
（9）埋點
埋點需求是提給DA或者研發的，不同團隊要求不同。
埋點的目的是：讓自己後期能監測到關注的功能的用戶情況，方便繼續迭代和發掘問題。
（10）需求變更記錄
我用過幾次，主要是記錄自己的變更記錄。方便其他成員查看。但是簡單的功能我基本沒怎麼用過。畢竟我感覺口頭溝通後，直接改需求詳情更好。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺「網易號」用戶上傳並發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.