產品經理對原型和PRD的認知到達這個水準，才能稱之爲合格的PM

經歷了漫長的產品設計流程，咱們終於來到了最後一個環節，也就是根據以前梳理的產品流程來進行產品的界面設計了。前端

產品經理其實都知道，在這樣一個看重顏值的時代，一個賞心悅目的網站（或者移動APP）是多麼重要。每個產品經理，也都但願本身創造的產品是不同凡響的，在茫茫的互聯網產品海洋裏，可以閃射出耀眼的光芒，就比如每一個人都但願本身是人羣中獨一無二的那一個。嗯，這麼說來，其實每個產品經理的心裏深處，都有着一顆文藝青年的心靈，也正是擁有了這樣一顆感覺豐富、體驗細膩的產品之心，才使得咱們可以對產品設計的細節有着更爲透徹和深刻的理解。web

在大公司內部，一般來講不須要產品經理去進行具體的界面交互設計，多數是由產品團隊與UED團隊合做進行產品原型的設計，出具的交付物是產品原型和頁面交互圖，而產品經理則須要產出市場需求文檔（MRD文檔）和產品需求文檔（PRD文檔）。可是在絕大多數創業公司團隊裏面，則沒有配置那麼豪華的產品設計、交互設計團隊，常見的搭配每每是一個產品經理加上一個UI設計師，因此通常都是產品經理本身身兼交互設計的工做職責，輸出交互設計稿，也就是產品原型。算法

什麼是產品原型

說的簡單一點，產品原型是設計方案的表達，是產品經理、交互設計師的重要產出物之一，也是項目團隊的其它成員（尤爲是設計師、開發人員）的重要參考和評估的依據。api

結合咱們前面瞭解的知識，產品界面原型其實就是頁面級別的信息架構、文案設計、及頁面和頁面之間的交互流程，它是產品功能與內容的示意圖。瀏覽器

直接上幾個原型圖，可能會更加清晰明瞭，以下圖：
安全

產品設計原型按照精細程度來分，可分爲低保真產品原型和高保真產品原型、設計成品。服務器

低保真產品原型

所謂低保真原型，實際上是對產品較簡單的模擬，它只是簡單的表述了下產品的外部特徵和基本功能構架，不少時候都是用簡單的設計工具迅速製做出來，用來表示最初的設計概念和思路。微信

好比用紙和筆進行的手繪，用畫圖軟件作出的簡單線框圖，都算是低保真產品原型。網絡

這樣的原型圖有幾個好處：
1. 能夠快速產出：有時候一個需求的開發週期很短，低保真原型能夠快速知足研發同事的時間要求；
2. 修改爲本低：一個產品策劃極可能會被修改不少次，低保真的原型修改起來很方便。固然，低保真原型也會有幾個問題，好比交互細節不清楚，總體界面粗糙容易形成誤解等。數據結構

一般來講，通常只有時間比較緊迫，需求也比較簡單的時候，咱們纔會去產出低保真產品原型。

高保真產品原型

高保真產品原型，則是高功能性、高互動性的原型設計，是忠實展現產品功能、界面元素、功能流程的一種表現手段。原型圖中不管是功能模塊的大小，仍是文案設計甚至是所用的圖標、圖例、交互動做，都使用真實素材，或者說和最終UI設計師的產出很是接近，就算是高保真產品原型了。

高保真的好處：
1. 便於梳理產品細節：製做高保真原型的過程當中可讓產品經理提早發現產品潛藏的各類問題，提早處理風險；
2. 更容易讓其餘成員瞭解產品設計：有時候簡單的線框圖沒法讓別人想象出你要作的事情，也不清楚你要放的是哪幾個字段，具體的文案是什麼，而高保真原型就能夠。

相對而言，劣勢就是製做週期比較漫長，涉及到產品流程的修改，那基本上原型就得回爐重造一遍。

對於剛入門的產品經理，個人建議是若是有時間的話，仍是儘量多的畫高保真原型。由於在一開始產品設計經驗很少的狀況下，經過設計一些高保真原型，對梳理本身的產品思惟、瞭解產品設計是頗有幫助的。對於已經入門好久的同窗來講，則看需求的複雜程度和時間安排，好比產品的關鍵頁面是必然要用高保真原型去設計和梳理的，至於要不要親自上陣，則能夠結合設計資源及團隊實力來進行安排。

設計成品

設計成品在這裏，你也能夠理解爲是視覺設計師產出的UI設計稿，也就是設計師對你的產品原型進行美化以後得出的做品。設計師會運用必定的設計規範，來將你的原型變成可讓前端開發進行代碼實現的做品。

在設計成品出來的那一刻，產品經理須要作的就是和設計師進行PK就行了，不管是產品主題色的選擇，仍是頁面佈局，甚至是交互按鈕和控件，都是大家須要討論的話題。

放上一張圖來比較下三種原型的區別：

原型設計工具

工欲善其事，必先利其器。好的原型設計工具，老是能大大提升咱們的產出效率。產品經理在平常的工做中，其實也應該多多體驗一些互聯網工具產品，一方面可讓本身的產品感提高，另外一方面，也能夠經過體驗產品來了解工具屬性，從而更好地將工具利用起來。這裏給你們介紹幾款產品設計經常使用的原型設計工具：

一、Axure RP ，推薦指數✦✦✦✦✦

Axure RP是一個專業的快速原型設計工具。Axure（發音：Ack-sure），表明美國Axure公司；RP則是Rapid Prototyping（快速原型）的縮寫。Axure是產品經理的必備工具，其餘的很少說了，去看看招聘網站上關於PM的招聘信息，基本全部職位描述裏，都包含了這麼一句「熟練使用Axure」，因此這款工具的重要性你懂的。

二、墨刀，推薦指數✦✦✦✦

墨刀也是一款原型設計軟件，雖然可能功能沒有那麼完整，相對來講對於通常使用也是足夠的，目前分爲網頁版和客戶端，網頁版能夠直接使用，客戶端其實也是網頁版的功能，通常來講會下載客戶端，使用過程當中須要聯網。

墨刀相對來講有這麼幾個優點：一、簡單、易上手；二、支持團隊多人協做；三、控件什麼的都是現成的；四、能夠直接在手機上進行預覽；

固然缺點也很明顯：一、依賴網絡，網絡不穩定或者服務器不穩定的時候則無法使用，這點有點讓人崩潰，好比說原型設計到一半忽然斷網了，則沒有保存；二、不少交互功能不夠強大，還不能像axure那樣實現複雜的交互和跳轉；

三、Visio，推薦指數 ✦✦✦
不少老牌的產品策劃人員、產品經理都使用過它來設計產品原型，算是線框圖專業戶，比較靈活，Office使用習慣接受程度較高。另外一個好處是支持各類平臺尺寸設計。有些產品設計團隊從原先的Axure 調整至 Visio ，是由於Visio 能夠更便捷地輸出標準大小的PDF文檔，方便在同事之間交流。

在學習伊始，不少剛剛入門的產品新人比較熱衷於上網找課程學習Axure等原型工具的使用，樂此不疲；他們都但願經過精通工具的使用能力，來提升本身的職場競爭力。然而這並非重點，工具只是用來承載和描繪咱們思想和內容的一個畫筆，因此沒有必要把太多的時間消耗在掌握工具的使用技巧上，產品設計的主題、內容、規劃纔是真正須要用心去考量和思索的。這就比如武俠小說裏的故事同樣，沒有深厚的內功心法，即便擁有好的武器，也發揮不了太大的做用。

設計原型時須要注意的事項

經過上面的介紹，其實咱們已經瞭解了，一個好的產品原型可讓其餘人迅速理解咱們想要作什麼事情，減小團隊的溝通成本，並確保接下來要推動的事情沒有什麼誤會。

產品經理在將原型圖畫好以後，每每會特別欣喜，巴不得立馬就讓全體團隊成員看到本身的設計成果。可是，這時候的原型圖一般是不完整的，不少場景、因素缺乏考慮，小到一個按鈕的位置，字段展現、大到功能的流程設計、邏輯設計，都缺少系統地思考和完善。若是你就輕易把這麼一份不完整的原型交付給技術，不但技術會噴你，搞很差用戶也來噴你，甚至Boss也來噴你。因此，打磨好產品原型，儘可能考慮各類場景、因素，設計原型時儘可能細化分析，讓全部人從原型就能看到你的態度，是一件很是重要的事情。

整體來講，原型設計須要表達清楚這麼幾個地方：

一、界面元素

什麼是界面元素，好比文字，下拉框，按鈕，圖標、圖片等等這些都屬於界面元素。咱們在運用原型設計工具（如axure、墨刀、visio等）設計產品原型的時候，須要明確界面上的元素是什麼，如何展示，鼠標移動或者手勢滑動、點擊上去是怎樣的效果。

二、數據邏輯

這一點每每也是很是多創業團隊和新手產品經理容易忽視的。好比一個直播列表界面，上面有三個tab，分別是關注直播、熱門直播、最新直播，那麼最新直播是基於怎樣的數據邏輯獲取的，你就須要在你的原型設計上進行說明了。固然，最新直播的數據獲取邏輯是比較簡單的，也許你不和研發人員說明清楚，他們也能知道是按時間倒序排列；但若是碰到稍微複雜一點的數據邏輯呢，就好比剛剛說的關注直播的數據獲取，是獲取關注的機構的直播呢，仍是獲取我的的直播呢，這都是須要經過註釋來講明清楚的。

三、操做邏輯

一個原型界面上能夠進行操做元素的有哪些，哪一個能夠點擊，哪一個能夠選擇，操做後出現怎樣的反饋，好比彈出浮層？進入新頁面？或是跳出新頁面？仍是給一個怎樣的提示？這些也是須要在原型設計裏面說清楚的。

這三個點是一份完整的原型設計基本須要包含的東西，再配合上以前畫好的產品結構腦圖和流程圖，就基本能夠與開發進行輕鬆愉快的交流了。只有這樣，開發者才能明確這個原型設計的開發需求，而不是讓開發工程師本身去猜，去揣測數據邏輯、算法應該是什麼樣的、具體的產品交互方案如何。

以下圖，能夠在原型設計上作相關的註釋說明：

談談產品需求文檔（PRD文檔）

與產品原型同樣，產品需求文檔也是支撐產品經理與團隊溝通的重要工具。不少公司都要求產品經理寫產品需求文檔，撰寫產品需求文檔是產品經理平常工做中，很是重要的一部分。需求文檔的質量好壞，直接影響到研發部門是否可以明確地瞭解產品定義和產品功能、邏輯。咱們來看下一份完整的產品需求文檔包含哪些部分：

一般來講，產品經理每每不會寫的那麼詳細，可以覆蓋到前面四個部分便已經算是一份基本合格的產品需求文檔了。

咱們一塊兒來看下文檔裏面都具體包含什麼內容：

1．概述

概述部分是歸納地說明產品背景、產品目標等。

1.1產品概述及目標—-包括背景介紹和產品目的

1.2名詞解釋—-聲明文檔中出現的名詞含義

1.3數據詞典—-介紹本產品中數據的數據項、數據結構、數據流、數據存儲、處理邏輯、外部實體等。

1.4文檔閱讀對象—-聲明本文檔輸出的閱讀對象和注意事項

2．產品描述

產品描述介紹了產品的總體邏輯流程，歸納性的描述產品需求、產品版本規劃、產品總體的框架結構以及功能列表。產品總體流程與產品框架都須要使用相應的圖表展示方式

2.1產品總體流程-—展現產品框架圖和用戶流程圖。

2.2產品需求描述—-描述產品核心功能，解決哪些情景下的哪些需求。

2.3產品版本規劃—-敘述產品版本迭代計劃，版本號、主要模塊、功能點、計劃開發時間、計劃結束時間、備註。

2.4產品框架—-展現頁面層級及備註信息

2.5功能列表—-展現產品功能名稱、對應模塊、功能說明、備註等信息。

3．功能描述

功能需求這部分需詳細描述產品所涉及的各個功能點。將總體框架拆成數個獨立的功能點，分別描述每一個功能點的邏輯流程圖、界面、字段說明以及業務說明。統一採用UseCase的方式進行描述。

3.1流程圖——包含流程圖、順序圖和狀態圖等，這三種圖均可以理解爲UML圖

3.2界面原型——將產品概念具象化，也就是將交互原型設計稿貼上去

3.3字段說明（包括數據字典）——描述產品功能頁面包含哪些字段，字段的格式和限制要求等

3.4業務說明（Use Case）——描述產品的業務場景及相關用戶角色說明

4．非功能需求

非功能需求，也就是關於產品的其它方面的要求。

4.1安全需求——可以抵擋住黑客的攻擊，保證用戶的數據不會丟失等

4.2統計需求——梳理產品的埋點、統計需求，明確須要統計的相關指標

4.3性能需求——產品最大併發數等

4.4可用性需求——產品的加載速度、響應速度、瀏覽器的兼容性等

嗯，咱們已經看到了常規的產品需求文檔長什麼樣了。有一次和一個朋友聊天，提及他們公司的產品需求文檔，是一份長達200多頁的word形式的產品需求文檔，其實這樣的文檔看起來至關費勁，也不容易更新同步；

不少開發人員和產品經理之間產生的矛盾，其實都是由於這份又臭又長的產品需求文檔。由於不管是誰，都不喜歡看這麼長的文字，開發人員其實根本不須要這份文字式的需求告白書，他們喜歡「看圖」，這種文字式的需求文檔應該是產品經理腦中的思路，而不該該直接把思路描述成文字轉交出來。其實我我的也不喜歡這樣的風格，溝通成本過高，因此對於創業公司而言，仍是儘量簡單直接有效最好。作好如上幾點，對於大部分產品溝通場景來講，應該就能夠獲得知足。

因此，經過輸出產品結構腦圖、產品流程圖、界面原型加上相關的文字輔助說明業務、用戶使用場景，就基本能夠替代一份產品需求文檔了。因而，你會發現愈來愈多的互聯網公司產品經理已經開始使用Axure來撰寫PRD了，這也能夠理解爲是對需求文檔自己的一種認知迭代。

產品設計的構思

咱們已經瞭解了原型的相關知識，也掌握瞭如何熟練地使用一款原型設計工具，那最後就能夠進入到真正的原型設計實戰階段了。

前面已經強調過，工具只是一種手段，關鍵在於設計的構思與設計背後遵循的產品設計原則，就像每一個人手中都有一隻筆，但具體寫出什麼主題、什麼樣內容的文章，則是寫做者須要在動筆以前就好好思考清楚的了。產品經理說到底，也是一個藝術創做者，只不過這種創做是先理性，後感性。事實上，不少經典功能背後的設計都是有着更加深層次的構思和底層原理在驅動的。

舉個你們耳熟能詳的例子，微信裏面的「搖一搖」功能。

初期版本的微信只有一個動做（尚未識別歌曲、電視的功能），甚至連按鈕都沒有，可是你看到圖片依然會情不自禁地去搖動手機，一個來福槍的槍聲忽然響起（這個聲音很是性感），而後你會看到有一朵小花打開，最後就給你推送跟你同一時刻搖手機的人。這個體驗的整個過程實際上是很是嚴實的，它是一種人類的性暗示和性的驅動力在完成整個過程，弗洛伊德說，沒有什麼吸引你的驅動力比性的驅動力會更加原始。

總結起來，「搖一搖」這個功能作的好，一方面是它確實作的比較簡單，甚至連一個頁面提示都沒有，另外一方面它讓你用的很爽，這個爽是來自很深層次的緣由，它其實帶給了人類一種微妙的心理體驗，很是原始的一種動力體驗。固然，這也是一個科學，並非一個道德低下的問題。

咱們再來看一個案例。

假設大家公司是作SaaS產品，面向B端企業客戶，如今要開始設計產品官網，你會從哪幾個角度去進行構思呢？

咱們先來把簡單能想到的幾個點給列舉一下：

一、產品定位、產品功能介紹，讓用戶瞭解咱們是幹嗎的，能提供什麼價值；

二、客戶案例，有哪些用戶使用了咱們的產品，取得了一個怎樣的效果；

三、幫助與支持，能提供的產品幫助與服務；

四、價格，讓用戶瞭解產品的一個基本收費策略，是否分爲若干種套餐；

五、資訊、博客等，讓用戶瞭解產品的相關動態，及時獲取產品信息；

六、註冊、登陸按鈕頁面，讓用戶註冊咱們的產品進行體驗；

……

固然還有其它的點，在這裏就不一一列舉出來了。光看上面這些列舉出來的點，可能咱們還沒法獲知它們內在的邏輯是怎樣的，但咱們是否能夠換一個角度去思考問題，好比把本身想象成一個用戶，你在什麼狀況下會去購買一家公司的產品，成爲這家公司的一個使用用戶。

大致邏輯，無外乎要通過這四個步驟：瞭解、信任、價值、轉化。

用戶首先須要瞭解這個產品是什麼，才能肯定本身是否有使用這款產品的需求，來決定本身是否有必要作進一步的認識和了解；接下來，是用戶要可以信任這款產品，就比如你去參加會展，全部的展商都跟你說咱們的產品多麼多麼好，但用戶爲何要相信你呢，你有什麼好的信譽背書嗎；當用戶對你產生了必定的信任，以爲你這個產品是靠譜的以後，你是否是應該讓用戶更深刻地瞭解產品的價值，只有當用戶真正認識到這款產品可以給他帶來的價值以後，才能實現有效地轉化。

因此，咱們會發現，上面列舉的那些點，都是圍繞着這幾個方面來作的：

瞭解：產品的定位、產品簡單的功能介紹

信任：客戶案例、資訊動態

價值：產品功能的詳細介紹、產品價格、幫助與支持

轉化：註冊、登陸按鈕，引導用戶進行體驗購買

最後根據上面的設計思路，得出來的產品官網設計就是這樣的，以下圖：

其實，不只僅是產品官網頁面，在任何一個涉及到須要轉化的頁面，均可以使用這種產品設計思路，好比下圖典型的電商裏的寶貝詳情頁：

你會發現，其實天貓裏面的寶貝詳情頁的設計，也是圍繞着「瞭解－－信任－－價值－－轉化」的設計思路在進行設計，咱們也能夠簡單地來梳理一下：

瞭解：寶貝的5張主圖、寶貝的主標題、副標題、運費、尺碼、顏色、庫存；

信任：寶貝月銷量、商品累計評價、服務承諾、收藏商品的人氣

價值：價格、優惠活動、寶貝詳情、送天貓積分

轉化：當即購買按鈕、加入購物車按鈕

固然，這裏涉及到一個轉化率的概念，咱們上面論述的範圍都是從產品設計的角度去講如何提升商品的購買轉化率，如何提升網站的註冊轉化率、產品使用率等等。可是在實際的工做過程當中，不少時候運營人員也會參與到轉化率的數據提高上面來，他們可能會運用各類各樣的運營數據模型，來進行分析和推演。好比經過漏斗模型，找出影響產品每一個流程的細節因子，而後將全部影響因子都用數據工具監控起來，再來逐個優化，最後達到提高轉化率的目的。這個時候就須要產品經理和運營進行團隊配合，來共同提升產品的總體轉化率了，產品和運營都能發表本身對於轉化率的見解，但最後誰的方案奏效，依然是要看數據來講話。

總結一下，說了這麼幾個案例，只是爲了表達一個觀點，那就是對於產品經理來講，每個功能、頁面設計的背後，都要有更深層次的思考。給產品作功能加法實際上是很容易完成的一件事情，但如何只作少許的工做能起到最優的效果，如何實現「單點突破」，這個纔是更能考驗產品經理功底和深度思考能力的東西。咱們平時在觀察優秀的互聯網產品的時候，也要試着去多問幾個爲何，養成獨立思考的好習慣，爲何這個界面是這樣設計的，若是換一種設計方式，換一種交互邏輯，佈局調整一下，元素的位置、大小互換一下，又會帶來什麼樣的變化。

分享兩個產品設計原則

簡單，Don’t make me think

什麼是簡單？張小龍說簡單是一種審美觀，我深表贊同。

咱們作產品是要作簡單，不是說盡量作得簡陋一點，而是你腦殼裏是否是有一種審美觀念在這裏。當你看到一個界面上密密麻麻鋪滿了按鈕，你就知道這東西一點都不美，想要把它給簡化一下。並且簡單在許多行業和領域內都是通用的原則，好比以簡潔爲美進行產品設計的廠商MUJI和蘋果，都是這方面的典型表明。

那如何作到簡單呢？

一方面是要作到產品的信息架構簡單，只有一個簡單的產品架構，才能讓人更清楚地理解產品的定位和價值，產品功能之間的邏輯關係和層級關係是怎麼樣的，我要如何操做才能完成我想要完成的任務；

另外一方面是界面簡單，一個產品界面不要堆砌太多的元素。這裏給個建議，就是儘可能一個頁面就表達一個主題，每一個頁面最終是要引領用戶進行某一個操做，從導航到頁腳都要圍繞這一個目標來設計。這個和攝影很像，攝影講究構圖，一個構圖就表達一個主題，這樣一張照片的主題就會比較清晰。產品設計也是如此，一個頁面就表達一個主題，實在不行，則退而求其次，作到一個頁面有且只有一個主要的主題。這種目標上的一致性可以很好的幫助用戶瞭解他們須要在網站或者APP產品上作什麼，簡單的選擇每每可以讓用戶更輕鬆參與進來。

簡單直觀的設計並不必定非得是極簡的，它一樣能夠是豐富而又有趣的。可是簡單而易用的頁面的設計過程是須要用心作才能達成的，它須要具有高度的可用性和直觀的設計，確保用戶在使用的時候足夠直覺、不會遲疑。

以用戶爲中心

每一個產品經理和設計師時常掛在嘴邊的一句話即是，要以用戶爲中心，產品是和人打交道，產品的用戶體驗很重要。

既然咱們都知道要以用戶爲中心，要設計好的用戶體驗，那麼在原型設計好以後，有沒有什麼好的方法去測量一下呢？

其實，產品經理在作完原型設計以後，能夠多作一些可用性測試，這樣能夠更好地瞭解本身的設計是否符合用戶的認知和操做習慣。能夠將高保真的交互原型打印出來，製做成紙質原型，邀請用戶完成產品典型任務，待驗證功能點；也可使用一些原型工具，好比騰訊團隊出品一款叫作Demoo的工具，把原型放到手機上直接體驗預覽。

這裏再給你們簡單科普下什麼是可用性測試：

可用性測試就是邀請真實用戶或潛在用戶使用產品或設計原型，對其在使用過程當中的行爲進行觀察、記錄、測量和訪談，進而瞭解用戶對產品的要求和須要，並以此做爲改進產品設計的出發點，提升產品的可用性。

另外一個老生常談的地方是，究竟是選擇聰明，仍是選擇善良。

「善良比聰明更重要」的觀點源自於亞馬遜CEO傑夫·貝索斯在2010年學士畢業典禮上發表的演講。他追憶了本身的幼年歲月，講述本身如何在兒時懂得了「善良比聰明更難」的道理;分享了16年前本身決定放棄優厚工做、建立亞馬遜時的複雜心路。

產品設計也是如此，你在作產品的過程當中，究竟是要不計一切地展現聰明，仍是要選擇善良。不少軟件產品的安裝過程當中，都會使用下圖這種增長軟件裝機量的手段，這就是一種典型的選擇聰明的價值觀。

雖然咱們在產品中，會有意無心地利用人性的弱點，去擊中用戶需求的要害，可是，不能把這種聰明過分化，而是須要站在一種坦誠的角度和用戶對話，而不是給用戶下套。就像選擇朋友，你們可能都會認爲善良更重要。一樣地，用戶選擇咱們的產品，也會如此。

因此，我仍是認爲作產品要有道德底線，用小聰明去欺騙用戶，用惡意營銷去吸引用戶下載，最終或許會有很多的關注量和點擊量，但最終仍是會被用戶拋棄。