産品設計是一個由抽象的概念到具體形象化的處理過程，通過文字或圖像等方式将我們規劃的産品需求展現出來。它将産品的某種目的或需求轉換為一個具體的實體或工具的過程，把一種計劃、規劃設想、問題解決的方法，通過具體的操作，以理想的形式表達出來。
由于産品設計階段要全面确定整個産品政策、外觀、結構、功能，進而确定整個産品系統的布局，因而，産品設計的意義重大，具有“牽一發而動全局”的重要意義。如果一個産品的設計缺乏具體形象的表述，那麼研發時就将耗費大量資源和勞動力來調整需求。相反，好的産品設計，不僅表現在功能上的優越性，而且便于執行時了解，進而使産品的研發效率得以增強。
1、産品需求文檔介紹
産品設計的最終表述的形式被稱為産品需求文檔，業界常常稱呼為PRD文檔，這是英文Product Requirement Document的縮寫。産品需求文檔是将産品規劃和設計的需求具體形象化表述出來的一種展現形式，主要用于産品界面設計和研發使用。
PRD文檔是基于BRD、MRD的延續文檔，主要是一份給執行層面的從業人員閱讀的文檔，這部分人群絕大多數是設計與技術人員。在這類人群中，設計師更多依賴于産品原型進行互動或視覺的設計，是以看這份文檔的人主要是技術人員。相對于技術人員，他們不太關注産品的商業需求和市場願景，因為在進行産品讨論立項時，産品的定義就已經向參與設計和研發的人員宣講過，是以技術人員更多的是關注界面、功能、互動、元素等等内容，是以産品需求文檔是一份詳細的産品功能需求說明文檔，是産品文檔中最底層和最細緻的文檔。
因為閱讀人類的因素，是以産品需求文檔是一份沒有閑話，直入主題的功能說明文檔。并且産品需求文檔是沒有标準規範的，也沒有統一的模闆，每個公司都不一樣和每個人也不一樣，這個取決于個人習慣和團隊要求。雖然産品需求文檔沒有明确的規範，但是目的都是一樣的，必須能夠明确産品的功能需求，便執行人員了解任務要求。
2、産品需求文檔寫作
産品需求文檔是産品經過規劃和設計之後的最終執行文檔，是以這份文檔的品質好壞直接影響到執行部門是否能夠明确産品的功能和性能。
2.1、羅列資訊（資訊結構圖）
在寫産品需求文檔之前，我們需要先羅列出産品功能的資訊内容，這一步是将想法逐漸清晰的第一步，也是幫助我們接下來設計功能的輔助資訊，同時也可以輔助服務端技術人員建立資料庫。因為這是第一步，是以我們不需要羅列的很詳細，在之後的步驟裡，我們會逐漸改進和完善資訊内容。
羅列資訊内容的方式有很多種，文本形式、思維導圖形式等等都可以，最主要的是能夠清晰易懂，我最常用的方法就是使用思維導圖軟體(MindManager)羅列成結構圖，是以我稱這一步為“資訊結構圖”。
上圖是一張以Blog系統為示例的資訊結構圖。資訊結構圖是一種接近資料庫結構的圖表，在羅列資訊結構時，更多的是考慮資訊資料，但是他并不是真正意義的資料庫結構。資訊結構圖是提供給産品經理自己梳理資訊内容的結構圖，也是友善産品經理和服務端技術人員溝通資料結構的參考圖，技術人員會根據這張圖表的内容再結合産品原型或需求文檔，然後規劃和設計出真正意義上的資料庫結構。
資訊結構圖中關于友情連結功能的資訊資料隻有“名稱”和“連結”兩個内容，但是在實際功能需求中，友情連結還有兩個功能，分别是“顯示或隐藏”和“是否新視窗打開”，這兩個功能會在産品原型和需求文檔中較長的描述，但是在資訊結構中是沒有展現的，因為從産品層面上來說，這兩個隻是功能，并不是資訊内容。但是在真正資料庫中，友情連結的這兩個功能分别也是有字段參數的，程式在讀取該參數後便知道友情連結的屬性，然後處理友情連結是顯示還是隐藏，是新視窗打開還是本視窗打開。通過友情連結這個例子，我們就知道了在實際中資料結構和資訊結構是不一樣的，資訊結構隻是産品層面的資料内容。
無論是什麼樣的産品類型，無論從哪裡入手，我們第一步都是先要羅列資訊結構，因為資訊結構圖不僅是輔助技術人員建立資料庫的圖表，也是輔助産品人員進行産品功能規劃的參考，隻有對資訊或資料的結構了解了，我們才能更好的設計産品。
資訊結構圖是我們将概念想法形成結構化的第一步，也是我們接下來幾步工作的輔助文檔，同時在接下來的幾步工作中，我們還會不斷的完善資訊的結構。
2.2、梳理需求（産品結構圖）
當我們對産品的資訊結構了解後，我們就需要規整腦海中的産品需求，讓想法更加結構化，是以這一步就要梳理産品的需求。在設計産品原型之前，我們首先要羅列出産品的功能結構，包括頻道、頁面、子產品及元素。這一步依然使用思維導圖軟體，像繪制樓盤鳥瞰圖一樣将産品的結構繪制成結構圖，是以我稱這一步為“産品結構圖”。
産品結構圖是一種将産品原型以結構化的方式展現的圖表，結構内容也如同産品原型一樣，從頻道到頁面，再細化頁面功能子產品和元素。是以産品結構圖是産品經理在設計原型之前的一種思路梳理的方式，并不是給其他從業人員檢視的文檔，通過類似鳥瞰式的結構圖可以讓産品經理對産品結構一目了然，也友善思考。
如上圖示例，“活動大全”的産品結構依次是：産品 -> 頻道 -> 頁面 -> 頁面元素 -> 操作 -> 元素。我們換一個角度觀看示例，産品結構圖實際上就是一種結構化的産品原型。這樣做的目的就是梳理産品結構邏輯，讓我們清楚的知道産品有幾個頻道，頻道下面有沒有子頻道或者有多少個頁面，這些頁面裡又有哪些功能子產品，這些功能子產品裡又有哪些元素。
上圖以我們第一步的“資訊結構圖”為基礎繪制的“産品結構圖”，有了這份結構導圖，我們可以對産品進行鳥瞰式考慮和完善，當有問題時，修改起來也比原型和文檔友善很多。比如在後續規劃中，我們發現文章的圖檔等附件上傳後，管理不太友善，這時就可以在結構圖中增加一個“附件管理”頻道。如果我們使用産品結構圖的方式，那麼附件管理的功能增加和修改就會比原型工具更加便捷和效率。
産品結構圖的方法同樣适用于移動網際網路産品的設計，并且比起Web産品更加容易梳理産品結構。
産品結構圖是一種讓産品經理通過思維導圖的方式梳理思路的方法，通過這種方法可以明确産品有多少個頻道、有多少個頁面、頁面有多少個功能子產品、功能子產品有多少個元素，逐漸的将腦海裡的想法明确梳理成結構。雖然這種方法能夠明确産品的結構，但是這樣的思維導圖也就隻有産品經理自己能夠看懂，因為對于設計和技術人員這是一個抽象的表述方式，如果沒有詳細的講解，是很難了解的。
産品結構圖是将産品原型具體化的一種方式，隻是羅列了産品的頻道頁面和功能，但是沒有詳細的進行推演，關于細化方面是否符合産品邏輯，是否符合使用者體驗，這些都是沒有深思過的，是以我們接下來就要進行原型設計，開始具體的考慮可行性。
2.3、原型設計（界面線框圖）
當我們逐漸清晰了産品的需求後，并梳理了産品的各個頻道及頁面，那麼這一步就要開始驗證這些想法的具體界面表現和方案的可行性了。
原型設計是幫助我們更細緻的思考，并做各項需求的評估，同時也是将自己腦海裡的想法進行輸出的一種方式。通過原型設計後，我們就可以進行産品宣講了，相比較于抽象的文字描述，原型則更加直覺的展現産品的需求，設計和技術人員或者老闆也能夠更加直覺的了解到産品意圖。
原型設計是将結構化的需求進行架構化，是以原型也被稱為線框圖，具體的表現手法有很多種，相關的輔助軟體也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner等等。
當到了原型設計這一步時，已經不僅僅是構思了，我們需要更加深入的了解每個頁面上元素和這些元素的屬性。例如按鈕元素，我們就需要考慮這個按鈕的功能，并且這個功能操作後帶給後端和前端的回報。例如注冊會員按鈕，使用者操作後，第一步邏輯是驗證使用者輸入的資訊是否合法，不合法則給出前端回報；合法則和後端通信驗證是否已經存在同樣資訊，已經存在則給出前端回報，不存在則進入下一步，注冊成功；注冊成功後的回報是跳轉頁面，還是彈出層提示使用者完善資料，這些都是需要更詳情的考慮。當然這些更細緻的思考是留在需求文檔撰寫時的，而此時我們需要做的就是把這些元素通過原型表現出來。
原型設計的表現手法主要有三種：手繪原型、灰模原型、互動原型。從工作效率的角度考慮，我非常建議先通過手繪的形式快速在草紙上繪制出産品的原型，推演和讨論方案的可行性。當方案的可行性被驗證之後，我們再根據個人習慣或團隊要求，通過軟體工具進行更深入的設計。
① 手繪原型
因為原型也被稱為線框圖，是以手繪是最簡單直接的方法，也是最快速的表現産品輪廓的手法。
手繪原型在初期驗證想法時非常高效，也友善讨論和重構，同時也适合靈活開發時快速出原型。
② 灰模原型
灰模原型是由圖形設計軟體制作而成，最常用的軟體是Photoshop和Fireworks，相對手繪原型，灰模更加清晰和整潔，也适用于正式場合的PPT形式宣講。
灰模原型也可以稱之為平面原型，是以如果不會使用圖形軟體也可以使用Axure RP設計，相比互動原型，灰模原型隻是缺少互動效果，僅僅是将産品需求以線框結構的方式展示出來，讓産品需求更加規整的直覺展現。
③ 互動原型
互動原型是使用原型設計軟體完成的原型，常用軟體是Axure RP，通常情況互動原型的設計要早于産品需求文檔，是産品經理想法推演的重要一步。通過Axure RP之類的互動原型軟體制作出來的産品原型，在功能需求和互動需求的表現上，幾乎和正式産品是一緻的，是以有時互動原型也被稱為産品Demo版。
通常情況下互動原型是産品經理與互動設計師共同讨論确定，然後由互動設計師制作，但是絕大多數的公司是沒有互動設計師這個職位的，是以這類工作最終是由産品經理來負責的。
—
以上三種方法并不是漸進的流程，而是三種原型設計的方法，具體取決于你的産品需求和團隊要求。
對于産品經理來說，原型設計是為了幫助我們細緻的考慮方案，并論證方案的可行性，同時也是為了産品宣講時讓聽衆能夠清晰直覺的了解産品，避免抽象的語言描述導緻聽衆了解困難和了解偏差。産品原型也是為了確定産品在執行過程中，是按産品經理最初設想的需求和期望完成的，是以産品經理的原型是沒有很高的要求的，隻要對方能夠聽懂看懂就可以了，是以使用手繪原型是最高效率的方法。
2.4、用例模型（産品用例圖）
用例(Use Case)是一種描述産品需求的方法，使用用例的方法來描述産品需求的過程就是用例模型，用例模型是由用例圖和每一個用例的較長的描述文檔所組成的。在技術和産品的工作領域裡都有用例模型的技能知識。技術人員的用例主要是為了友善在多名技術人員協同工作，或者技術人員任務交接時，讓參與者更好的了解代碼的邏輯結構。産品人員的用例主要是為了友善技術研發和功能測試時，讓參與者更好的了解功能的邏輯。
用例起源和發展于軟體時代的産品研發，後來被綜合到UML規範之中，成為一種标準化的需求表述體系。雖然用例在軟體研發和技術工作中應用的非常廣泛，但是在網際網路産品規劃和設計中，并不經常使用，網際網路産品的需求表達為了靈活效率，通常采用原型加産品需求文檔。
UML是英文Unified Modeling Language的縮寫，中文稱為統一模組化語言或标準模組化語言，是用例模型的模組化語言，常用工具是Microsoft Office Visio。産品用例是一種通過使用者的使用場景來擷取需求的方式，每個用例提供了一個或多個場景，該場景說明了産品是如何和最終使用者或其它産品互動，也就是誰可以用産品做什麼，進而獲得一個明确的業務目标。
① 用例圖
用例圖并不是畫成了圖形的用例。用例圖包含一組用例，每一個用例用橢圓表示，放置在矩形框中；矩形框表示整個系統。矩形框外畫如圖所示的小人，表示參與者。參與者不一定是人，可以是其它産品、軟體或硬體等等。某一參與者與某一用例用線連起來，表示該參與者和該用例有互動。
許多人通過UML認識了用例，UML定義為展現用例的圖形符号。UML并不是為描述用例定義書寫格式的标準，是以許多人誤認為這些圖形符号就是用例本身；然而，圖形符号隻能給出最簡單的一個或一組用例的概要。UML是用例圖形符号最流行的标準，但是除了UML标準，用例也有其它的可選擇的标準。
② 用例描述文檔
用例圖隻是在總體上大緻描述了産品所能提供的各種服務，讓我們對于産品的功能有一個總體的認識。除此之外，我們還需要描述每一個用例的詳細資訊，這些資訊應該包含以下内容：
用例名稱：本用例的名稱或者編号
行為角色：參與或操作(執行)該用例的角色
簡要說明：簡要的描述一下本用例的需求(作用和目的)
前置條件：參與或操作(執行)本用例的前提條件，或者所處的狀态
後置條件：執行完畢後的結果或者狀态
用例描述文檔基本上是用文本方式來表述的，為了更加清晰地描述用例，也可以選擇使用狀态圖、流程圖或序列圖來輔助說明。隻要有助于表達的簡潔明了，就可以在用例中任意粘貼使用者界面和流程的圖形化顯示方式，或是其它圖形。如流程圖有助于描述複雜的決策流程，狀态轉移圖有助于描述與狀态相關的系統行為，序列圖适合于描述基于時間順序的消息傳遞。
在網際網路産品和設計中，用例的使用越來越少，通常有了産品原型再加上功能流程圖和功能說明文檔就能夠将産品需求詳細的表述清楚，是以也沒有必須撰寫用例了。但是在大公司裡，往往會追求産品流程的規範性，要求撰寫用例，不過在靈活開發的時候也會采用其它更有效率的方式，不一定非要撰寫用例。
前面幾步我們将産品需求逐漸細化并且通過原型的方式将産品需求形象化的展現了出來，但是在産品功能的邏輯細節方面，原型就非常不直覺了，是以用例是一個非常重要的描述需求過程的文檔。
但是由于用例文檔以文字為主，并且格式複雜，不适用于高效率的産品需求表述，是以展現邏輯流程的“功能流程圖”是一個簡潔直覺的可替代用例文檔的方式。
（請點選檢視大圖）
如上圖所示，功能流程圖是一種使用圖形的方式表示算法邏輯的圖表，因為千言萬語不如一張圖，通過流程圖将“優惠券”功能子產品的邏輯和需求非常形象直覺、一目了然的展現了出來。
流程圖的展現方式也不會産生“歧義性”，便于了解，邏輯出錯時也非常容易發現，并且可以直接轉化為程式需求描述文檔。
2.6、需求文檔（PRD文檔）
前面的幾個步驟是為了幫助我們梳理需求、驗證可行性和明确細節，到了這一步的時候我們已經非常清晰的了解産品需求，此時撰寫産品需求文檔可以大大減少和避免了撰寫文檔時容易忽略的細節黑洞。
産品需求文檔是将産品規劃和設計的需求具體形象化表述出來的一種展現形式，主要用于産品界面設計和研發使用。因為每個人的習慣和團隊要求都是不一樣的，是以産品需求文檔沒有統一的行業規範标準，無論以什麼樣的格式撰寫産品需求文檔，最終的目的都是讓執行人員能夠了解産品需求，根據需求完成産品。
産品需求文檔的表現形式有很多種，常見的有Word、圖檔和互動原型這三種形式，文檔内容通常包含資訊結構圖、界面線框圖、功能流程圖、功能說明文檔。雖然産品需求文檔沒有标準的規範，但是有兩項是必不可少的，那就是檔案辨別和修改記錄。文檔在撰寫過程中，我們可以自行不斷的修改完善，但是如果正式釋出或交給團隊其他成員後，一旦有了修改，為了文檔的同步，我們就需要标注出文檔的修改内容，備注修改記錄，這樣可以友善大家檢視和了解改動的内容。關于檔案辨別和修改記錄，格式都大同小異。
① Word
這是傳統意義上的産品需求文檔，主要有四個部分組成(具體根據産品要求進行劃分)，分别是：結構圖、全局說明、頻道功能、效果圖。
因為産品需求文檔的閱讀者主要是偏向于技術人員，是以文檔的目的性非常明确，就是要描述産品的功能需求，所有産品需求文檔沒有關于市場方面的描述。為了保證需求的執行效率，建議大家盡量減少不必要的文字，在能夠讓閱讀者看懂并且了解産品意圖的情況下，文字越少越好。這主要是因為絕大多數人是沒有足夠耐心認真看完産品需求文檔的，是以我們要盡量減化文檔内容。
①-1、結構圖：
①-1.1、資訊結構圖：主要是輔助服務端技術人員建立或調整資料結構的參考檔案
①-1.2、産品結構圖：主要是輔助設計和技術開發人員了解産品的全局結構。
①-2、全局說明：
主要講解産品的全局性功能的說明，例如網站産品的頁面編碼、使用者角色，移動産品的緩存機制、下載下傳機制，這類全局性功能的說明。這裡我舉一個移動産品的“狀态維持與恢複”的例子。示例如下：
狀态的維持與恢複
當使用者退出産品時（誤操作、Home鍵、鎖屏、自動關機），産品需要維持使用者操作前的狀态，當使用者傳回産品時仍可以恢複到之前狀态，并繼續使用。
維持狀态包括流程操作、資訊浏覽、文本輸入、檔案下載下傳。
鎖屏狀态時，如果使用者在産品中有下載下傳任務時，仍然保持下載下傳。
①-3、頻道功能：
以頻道為機關，頁面為子項，分别描述産品的頻道、頁面及頁面子產品元素的功能需求。示例如下：
1、頻道名：頻道介紹及需求說明
2、頁面1：頁面介紹及需求說明
2.1、頁面子產品1：子產品功能需求說明
2.1.1、頁面子產品1-元素1：功能說明
2.1.2、頁面子產品1-元素2：功能說明
2.2、頁面子產品2：子產品功能需求說明
在撰寫功能需求時，我們需要考慮使用者的流程，例如一個“完成”按鈕，我們需要描述他完成後，系統要不要給出回報提示(回報提示是什麼樣的形式回報，内容顯示成什麼，有沒有内容需要調取資料庫)，或者要不要跳轉頁面(跳轉到哪個頁面，這個頁面是其他頻道頁面，還是這個功能的子頁面，如果是子頁面就需要再描述這個子頁面的子產品及元素内容)。
①-4、效果圖：
效果圖是由設計師完成的産品圖，和實際開發完成的産品保真度一緻。
這個示例是一個移動産品(iPad)需求文檔，其中部分隐私内容已過濾隐藏，并且隻保留了首頁和地圖找房頻道的需求說明。由于工作環境沒有互動設計師，是以Word文檔中包含了部分互動說明。
② 圖檔
圖檔形式的産品需求文檔是基于效果圖的說明檔案，将傳統Word形式的功能需求說明标注在效果圖上，這種方式經常使用在移動網際網路領域，實際上是圖文形式的互動需求檔案，隻是在此基礎上更深入的描述出功能需求。
對于圖檔形式的産品需求文檔，我們隻需要另外再描述一下全局說明，其他頻道頁面的需求直接以圖檔形式展示，這種方式相對于Word文檔的純文字更加生動易讀并且直覺，是以有一些産品經理非常喜歡用這種方式代替Word形式的産品需求文檔。
③ 互動原型
這裡指的互動原型就是前面篇章講到的原型設計，使用Axure PR之類的互動原型設計軟體制作出來的産品原型非常真實和直覺，并且原型軟體還支援元素标注和導出Word文檔，是以很多産品經理都喜歡使用Axure PR來代替Word完成産品需求文檔。
當我們通過Axure PR制作出産品原型後，實際上他已經是很完善的産品Demo了，是以我們隻需要加上元素的标注，在标注中說明功能需求，這樣導出的HTML檔案相比Word文檔更直覺易懂，是非常高效的産品需求說明方式。
無論你采用哪種方式撰寫需求文檔，最終的目的都是為了友善團隊成員了解産品的意圖，是以哪種方法能夠避免細節黑洞，高效完成産品的設計和研發，那麼這種方法就是最有效的方法