經歷了漫長的產品設計流程，我們終于來到了最后一個環節，也就是根據之前梳理的產品流程來進行產品的界面設計了。
產品經理其實都知道，在這樣一個看重顏值的時代，一個賞心悅目的網站（或者移動APP）是多么重要。每一個產品經理，也都希望自己的創造的產品是與眾不同的，在茫茫的互聯網產品海洋里，能夠閃出耀眼的光芒，就好比每個人都希望自己是人群中獨一無二的那一個。嗯，這么說來，其實每一個產品經理的內心深處，都有著一顆文藝青年的心靈，也正是擁有了這樣一顆感受豐富、細膩的產品之心，才使得我們能夠對產品設計的細節有著更為透徹和深入的理解。
在大公司內部，通常來說不需要產品經理去進行具體的界面交互設計，多數是由產品團隊與UED團隊合作進行產品原型的設計，出具的交付物是產品原型和頁面交互圖，而產品經理則需要產出產品需求文檔（PRD文檔）。但是在絕大多數創業公司團隊里面，則沒有配置那么豪華的產品設計、交互設計團隊，常見的搭配往往是一個產品經理加上一個UI設計師，所以一般都是產品經理自己身兼交互設計的工作職責，輸出交互設計稿，也就是產品原型。
什么是產品原型
說的簡單一點，產品原型是設計方案的表達，是產品經理、交互設計師的重要產出物之一，也是項目團隊的其它成員（尤其是設計師、開發人員）的重要參考和評估的依據。
結合我們前面了解的知識，產品界面原型其實就是頁面級別的信息架構、文案設計、及頁面和頁面之間的交互流程，它是產品功能與內容的示意圖。
直接上幾個原型圖，可能會更加清晰明了，如下圖：
產品設計原型按照精細程度來分，可分為低保真產品原型和高保真產品原型、設計成品
低保真產品原型：
所謂低保真原型，其實是對產品較簡單的模擬，它只是簡單的表述了下產品的外部特征和基本功能構架，很多時候都是用簡單的設計工具迅速制作出來，用來表示最初的設計概念和思路。
比如用紙和筆進行的手繪，用畫圖軟件做出的簡單線框圖，都算是低保真產品原型。
這樣的原型圖有幾個好處：1. 可以快速產出：有時候一個需求的開發周期很短，低保真原型可以快速滿足同事的時間要求。2. 修改成本低：一個產品策劃很可能會被修改很多次，低保真的原型修改起來很方便。當然，低保真原型也會有幾個問題，比如交互細節不清楚，容易造成誤解等。
通常來說，一般只有時間比較緊迫，需求也比較簡單的時候，我們才會去產出低保真產品原型。
高保真產品原型：
高保真產品原型，則是高功能性、高互動性的原型設計，是忠實展示產品功能、界面元素、功能流程的一種表現手段。原型圖中無論是功能模塊的大小，還是文案設計甚至是所用的圖標、圖例、交互動作，都使用真實素材，或者說和最終UI設計師的產出非常接近，就算是高保真產品原型了。
高保真的好處：1. 便于梳理產品細節：制作高保真原型的過程中可以讓產品經理提前發現產品潛藏的各種問題，提前處理風險。2. 更容易讓其他成員了解產品設計：有時候簡單的線框圖無法讓別人想象出你要做的事情，也不清楚你要放的是哪幾個字段，而高保真原型就可以。
相對而言，劣勢就是制作周期比較漫長，涉及到產品流程的修改，那基本原型就得回爐重造一遍。
對于剛入門的產品經理，我一直建議有時間的話，還是盡可能多的畫高保真原型。因為在一開始產品設計經驗不多的情況下，通過設計一些高保真原型，對梳理自己的產品思維、了解產品設計是很有幫助的。對于已經入門很久的同學來說，則看需求的復雜程度和時間安排，比如產品的關鍵頁面是必然要用高保真原型去設計和梳理的。
設計成品：
設計成品在這里，你也可以理解為是視覺設計師產出的UI設計稿，也就是設計師對你的產品原型進行美化之后得出的作品。設計師會運用一定的設計規范，來將你的原型變成可以讓開發進行實現的作品。
在設計成品出來的那一刻，產品經理需要做的就是和設計師進行PK就好了，我們在這里就不再過多來描述了。
放上一張圖來比較下三種原型的區別：
原型設計工具
這里給大家介紹幾款產品經理常用的原型設計工具：
1、Axure RP ，推薦指數 ?????
Axure RP是一個專業的快速原型設計工具。Axure（發音：Ack-sure），代表美國Axure公司；RP則是Rapid Prototyping（快速原型）的縮寫。
Axure是產品經理的必備工具，其他的不多說了，去看看招聘網站上關于PM的招聘信息，基本所有職位描述里，都包含了這么一句“熟練使用Axure”，所以你懂的。
2、墨刀，推薦指數 ????
墨刀也是一款原型設計軟件，雖然可能功能沒有那么完整，相對來說對于一般使用也是足夠的，目前分為網頁版和客戶端，網頁版可以直接使用，客戶端其實也是網頁版的功能，一般來說會下載客戶端，使用過程中需要聯網。
墨刀想對來說有這么幾個優勢：1、簡單、易上手；2、支持團隊多人協作；3、控件什么的都是現成的；4、可以直接在手機上預覽；
當然缺點也很明顯：1、依賴網絡，網絡不穩定或者服務器不穩定的時候則沒法使用；2、很多交互功能不夠強大；
3、Visio 2013，推薦指數? ???
很多老牌的產品策劃人員、產品經理都使用過它來設計產品原型，算是線框圖專業戶，比較靈活，Office使用習慣接受程度較高。另一個好處是支持各種平臺尺寸設計。有些產品設計團隊從原先的Axure 調整至 Visio ，是因為Visio 可以更便捷地輸出標準大小的PDF文檔，方便在同事之間交流。
在學習伊始，很多剛剛入門的產品經理就熱衷于上網找網絡課程學習Axure等工具教程來學，樂此不疲；希望通過精通的工具使用能力展示來為自己求職或在交互學習路上的發展加一把力。然而這并不是重點，工具只是用來承載我們思想和內容的一個載體，所以沒有必要把太多的時間消耗在掌握工具技巧上，產品設計的內容才是真正需要用心去考量和思索的。
設計原型時需要注意的事項
通過上面的介紹，其實我們已經了解了，一個好的產品原型可以讓其他人迅速理解我們想要做什么事情，減少團隊溝通成本，并確保接下來要推進的事情沒有什么誤會。
產品經理在將原型圖畫好之后，往往會特別欣喜，恨不得立馬就讓全體團隊成員看到自己的設計成果。但是，這時候的原型圖通常是不完整的，很多場景、因素缺少考慮，小到一個按鈕的位置，字段展示、大到功能的流程設計、邏輯設計。如果你就輕易把這么一份不完整的原型交付給技術，不但技術會噴你，搞不好用戶也來噴你，甚至Boss也來噴你。所以，打磨好產品原型，盡量考慮各種場景、因素，設計原型時盡量細化分析，讓所有人從原型就能看到你的態度，是一件非常重要的事情。
總體來說，原型設計需要表達清楚這么幾個地方：
1、界面元素
什么是界面元素，比如文字，下拉框，按鈕，圖標、圖片等等這些都屬于界面元素。我們在運用原型設計工具（如axure、墨刀、visio等）設計產品原型的時候，需要明確界面上的元素是什么，如何展現，鼠標移動或者點擊上去是怎樣的效果。
2、數據邏輯
這一點往往也是非常多創業團隊和新手產品經理容易忽視的。比如一個直播列表界面，上面有三個tab，分別是關注直播、熱門直播、最新直播，那么最新直播是基于怎樣的數據邏輯獲取的，你就需要在你的原型設計上進行說明了。當然，最新直播的數據獲取邏輯是比較簡單的，也許你不和研發人員說明清楚，他們也能知道是按時間倒序排列；但如果碰到稍微復雜一點的數據邏輯呢，就比如剛剛說的關注直播的數據獲取，是獲取關注的機構的直播呢，還是獲取個人的直播呢，這都是需要說明清楚的。
3、操作邏輯
一個原型界面上可以進行操作元素的有哪些，哪個可以點擊，哪個可以選擇，操作后出現怎樣的反饋，比如彈出浮層？進入新頁面？或是跳出新頁面？還是給一個怎樣的提示？ 這些也是需要在原型設計里面說清楚的。
這三個點是一份完整的原型設計基本需要包含的東西，再配合上之前畫好的產品結構腦圖和流程圖，就基本可以與開發進行輕松愉快的交流了。只有這樣，開發者才能明確這個原型設計的開發需求，而不是讓開發工程師自己去猜，去揣測數據邏輯、算法應該是什么樣的。
如下圖，可以在原型設計上做相關的注釋說明：
談談產品需求文檔（PRD文檔）
很多公司都要求產品經理寫產品需求文檔，我們來看下一份完整的產品需求文檔包含哪些部分：
通常來說，產品經理往往不會寫的那么詳細，能夠覆蓋到前面四個部分便已經算是一份基本合格的產品需求文檔了。
我們一起來看下文檔里面都具體包含什么內容：
1．概述
概述部分是概括地說明產品背景、產品目標等。
1.1產品概述及目標—-包括背景介紹和產品目的
1.2名詞解釋—-聲明文檔中出現的名詞含義
1.3數據詞典—-介紹本產品中數據的數據項、數據結構、數據流、數據存儲、處理邏輯、外部實體等。
1.4文檔閱讀對象—-聲明本文檔輸出的閱讀對象和注意事項
2．產品描述
產品描述介紹了產品的整體邏輯流程，概括性的描述產品需求、產品版本規劃、產品整體的框架結構以及功能列表。產品整體流程與產品框架都需要使用相應的圖表展現方式
2.1產品整體流程-—展示產品框架圖和用戶流程圖。
2.2產品需求描述—-描述產品核心功能，解決哪些情景下的哪些需求。
2.3產品版本規劃—-敘述產品版本迭代計劃，版本號、主要模塊、功能點、計劃開發時間、計劃結束時間、備注。
2.4產品框架—-展示頁面層級及備注信息
2.5功能列表—-展示產品功能名稱、對應模塊、功能說明、備注等信息。
3．功能描述
功能需求這部分需詳細描述產品所涉及的各個功能點。將整體框架拆成數個獨立的功能點，分別描述每個功能點的邏輯流程圖、界面、字段說明以及業務說明。統一采用Use Case的方式進行描述。
3.1流程圖
3.2界面原型
3.3字段說明（包括數據字典）
3.4業務說明（Use Case）
4．非功能需求
非功能需求，也就是關于產品的其它方面的要求。
4.1安全需求
4.2統計需求
4.3性能需求
4.4可用性需求
嗯，我們已經看到了常規的產品需求文檔長什么樣了。有一次和一個朋友聊天，說起他們公司的產品需求文檔，是一份長達200多頁的word形式的產品需求文檔，其實這樣的文檔看起來相當費勁，也不容易更新同步；
很多開發人員和產品經理之間產生的矛盾，其實都是因為這份又臭又長的產品需求文檔。因為無論是誰，都不喜歡看這么長的文字，開發人員其實根本不需要這份文字式的需求告白書，他們喜歡“看圖”，這種文字式的需求文檔應該是產品經理腦中的思路，而不應該直接把思路描述成文字轉交出來。其實我個人也不喜歡這樣的風格，溝通成本太高，所以對于創業公司而言，還是盡可能簡單直接有效最好。 做好如上幾點，對于大部分產品溝通場景來說，應該就可以滿足。
所以，通過輸出產品結構腦圖、產品流程圖、界面原型就可以替代一份產品需求文檔。
