文章分規劃篇和設計篇兩篇，分別適合不同階段的產品經理，大家各取所需，希望有所受益。

之前有寫過一個教程《五分鐘教你快速上手Axure交互設計》，令我感到欣慰的是那段時間里陸續不斷地有讀者加我微信向我表示感謝，有創業的，有工作的，也有經營電商的。其實真正要感謝的是你們，正是你們讓我嘗到了分享帶來的喜悅。因為寫這篇文章時自己還在校外實習，所以作為小白的我和你們一樣也在一點一點地學習別人授予我們的寶貴經驗。

這篇文章主要以“規劃”和“設計”為大的方向，整合了多個作者的觀點，并融入了不少自己的見解，結構上主要參考了唐杰的《杰出產品經理書v1.0》，希望對你們有用。

• 適讀人群：0-3歲產品經理（規劃篇）、0-1歲產品新人（設計篇）
• 寫作動機：聚合知識碎片，為讀者提供簡明的學習引導
• 文章特點：內容基礎實用，每一點都可當成課題進行深入研究（規劃篇）

機靈出了一個idea或是接到上面的需求，你該如何踏下產品之旅的第一步？先來一次市調？先給產品一個定位？冷靜下來吧少年，讓我們端杯咖啡看看地圖先。

規劃篇

戰略規劃

常見的戰略階段分為起步階段 、發展階段和迭代階段。

• 起步階段：注重核心功能的實現，目的是將產品快速推出市場并驗證可行性。
• 發展階段：注重產品功能的擴展和完善，同時也會進行灰度實驗，探索新價值。
• 迭代階段：注重用戶體驗的提升，商業產品會進行商業化的嘗試。

根據產品生命周期制定相應的運營策劃。

• 啟動階段：建立種子用戶社群，快速獲取反饋驗證。
• 成長階段：快速提升流量，建立品牌知名度。
• 成熟階段：活躍并留存老用戶、保持新用戶穩定增長，提高轉化變現能力。
• 衰落階段：積極創新，尋求轉型機會，實現用戶回流。

戰略受宏觀環境與公司內部的雙重影響。

• 宏觀環境：考慮政治政策、經濟水平、社會需求與技術壁壘（PEST）。
• 公司內部：考慮產品地位，是核心產品還是布局型產品，進行合理規劃避免資源供給不足導致困境。

產品定位

“在什么樣的場景下，用什么產品形態，滿足什么用戶的什么需求”

一般選擇產品定位有三個方向：

1. 選擇一些未被使用的痛點作為產品定位。
2. 選擇更高層次（細分）的核心需求作為產品定位。
3. 選擇垂直角度切入，滿足一部分人的需求。

同時最好注意以下幾點：

• 避免定位撞車：相同定位的競品由于更早的進入用戶的心智，不利于競爭。
• 將競品弱點擴大變為自己優點：就像百事可樂定位年輕人群沖擊上市已久的可口可樂。
• 尋找競品替代品：例如七喜的誕生，成為當時“非可樂”的代名詞占領市場。

通過產品定位，可以明確功能需求的界線，在產品規劃中并不是所有“相關的需求”都要實現，我們要充分考慮需求是否符合產品定位。

商業模式

商業模式的表現形式多種多樣，這里向大家推薦“商業模式畫布”，如下圖：

我們為什么需要有這樣只占一頁的商業模式圖？

• 完整性：它可以確定你商業模式的方方面面已經就緒。這里說的不是事無巨細的完整性。它應該是高層次的，而不是糾纏于細節。當然，如果存在很大的漏洞，同樣也會一目了然。
• 一致性：可以判斷商業模式的各個方面是否一致。比如，涉及合作伙伴的假設與涉及渠道的假設一致嗎？
• 一目了然:可以看到所有的同事是否清楚你正在做什么？為什么要這么做？必須確保這一點。如果要求他們獨立畫出商業模式畫布，他們畫出的圖會是一樣的嗎？商業模式畫布為討論確定了一個明確的焦點，我們可以討論商業模式各方面是否形成了一個整體，還可以看出人們對你正在做的事是否有什么誤解或不同見解。
• 溝通：你向創業導師、顧問、潛在雇員和投資者暢談自己的商業設想時，可以畫出商業模式畫布，也可也進行調整。它可以確定員工會議、董事會討論或投資者演示的焦點。相比一頁文字，人們更容易地記住一張圖（并根據基本的原則重新繪制一張圖）。

競品分析

首先了解競品分析的目的：

• 了解市場，看清市場的發展趨勢，找準市場切入點。
• 了解對手，他山之石可以攻玉，同時發現潛在的競爭對手。
• 了解需求，把握需求對應的功能點和界面結構，并側面了解用戶習慣。

其次注意分析關鍵點：

• 靈活多變：
  • 根據目的不同，靈活選擇分析重點
  • 根據時效性，靈活選擇分析深度
  • 根據資源不同，優化或調整分析手段

寧可無結論，也不能蒙一個錯誤結論。

需求決策

總的來說，需求決策可以分為4個階段，分別是：“搜集需求”、“分析需求”、“篩選需求”、“處理需求”。

• 搜集需求：在產品初期，主要的需求由產品經理通過定性定量的形式來挖掘，需求的類型更多地偏向功能類需求（做加法），目標是做出一個可用的產品；在成熟階段需要兼聽來自不同部門的同事、客戶、用戶的反饋，需求的類型偏向于運營類、設計類需求，目標是做出一個易用甚至好用的產品。
• 分析需求：產品經理應該有一張Excel表格，用來記錄日常工作中采集到的需求描述，包括需求提出者及提出時間。通過分析需求可以完成優先級的劃分，進行下一步的處理。
• 篩選需求：在這個階段，產品的相關人員會在一起開需求評審會，評審會的目的是篩選出一批需求，進行打包，整理出一個版本并交由上級復合，確認后進入需求處理（開發）階段。
• 處理需求：開發、排期、留存、暫緩、合并、擱置

需求分析過程主要做三件事：分類、分位、分級。

• 分類：不同的產品經理有不一樣的分類規則，這里可以細分為“粗分類”與“細分類”兩種
• 粗分類：將需求分為新增、優化、Bugfix和簡單的想法（基于用戶的心理模型）。
• 細分類：將需求分為功能類、運營類、數據類、設計類需求。
• 分位：以需求的急需性作為橫軸，重要性作為縱軸，通過四象限法則將需求分為四種，方便我們了解到需求的輕重緩急，也方便我們進一步的評估優先級。
• 分級：在分析需求優先級時，要結合用戶體驗（kano模型）、商業價值、技術架構等多方面因素綜合考慮，確定需求性價比，完成優先級劃分。

設計理念

產品的設計以用戶體驗為原則，對產品功能和體驗進行研究并開展設計。這里分為四個等級，形成一個金字塔式的設計理念。

• 有用——識別需求的有效性，抓住核心需求：應用商店設計的再華麗，沒有應用就沒用，所以要抓住產品的核心需求，避免無效需求。
• 可用——重塑并保障需求，滿足不同使用場景：確保產品不會有功能性BUG的出現，確保產品的安全、速度、兼容、流暢等方面的性能。
• 易用——梳理結構流程，便于用戶使用：易用的設計理念就是用戶體驗，需要我們在產品設計時，充分考慮用戶行為習慣和使用場景，減化用戶的學習成本、使用成本。
• 好用——優化設計界面，符合用戶群體喜好：注重視覺的表現，從視覺圖像上激發和提升用戶的潛意識操作行為，減少用戶的思考時間。

設計篇

設計流程遵循以下目錄順序

信息結構圖

羅列信息內容的方式有很多種，文本形式、思維導圖形式等等都可以，最主要的是能夠清晰易懂。 信息結構圖是一種接近數據庫結構的圖表，但是他并不是真正意義的數據庫結構。

上圖是一張以眾創平臺為例的信息結構圖，提供給產品經理自己梳理信息內容的同時，也方便產品經理和服務端技術人員溝通數據結構，技術人員會根據這張圖表的內容再結合產品原型或需求文檔，然后規劃和設計出真正意義上的數據庫結構。

產品結構圖

產品結構圖是一種將產品原型以結構化的方式展現的圖表，結構內容也如同產品原型一樣，從頻道到頁面，再細化頁面功能模塊和元素。所以產品結構圖是產品經理在設計原型之前的一種思路梳理的方式，并不是給其他工作人員查看的文檔，通過類似鳥瞰式的結構圖可以讓產品經理對產品結構一目了然，也方便思考。

上圖是一張以眾創平臺為例的產品結構圖，是將產品原型具體化的一種方式，只是羅列了產品的頻道頁面和功能，但是沒有詳細的進行推演，關于細化方面是否符合產品邏輯，是否符合用戶體驗，這些都是沒有深思過的，因此我們接下來就要進行原型設計，開始具體的考慮可行性。

產品原型圖

原型設計是將結構化的需求進行框架化，因此原型也被稱為線框圖，具體的表現手法有很多種，相關的輔助軟件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner等等。原型也有低保真原型與高保真原型之分，相較低保真原型而言，高保真原型從視覺與交互上更為接近產品的真實效果，但是制作所需的時間成本高。

原型設計的表現手法主要有三種：手繪原型、灰模原型、交互原型。

• 手繪原型：手繪原型在初期驗證想法時非常高效，也方便討論和重構，同時也適合敏捷開發時快速出原型。
• 灰模原型：灰模原型相較手繪模型更加規整直觀，也適用正式場合的PPT宣講，一般使用PS或Axure設計。
• 交互原型：交互原型在功能需求和交互需求的表現上幾乎和正式產品是一致的，所以有時交互原型也被稱為產品Demo版，一般由Axure制作。

以上三種方法并不是漸進的流程，而是三種原型設計的方法，具體取決于你的產品需求和團隊要求。

產品用例圖

用例(Use Case)是一種描述產品需求的方法，使用用例的方法來描述產品需求的過程就是用例模型，用例模型是由用例圖和每一個用例的詳細描述文檔所組成的。

• 用例圖：用例圖包含一組用例，每一個用例用橢圓表示，放置在矩形框中；矩形框表示整個系統。矩形框外畫如圖所示的小人，表示參與者。參與者不一定是人，可以是其它產品、軟件或硬件等等。某一參與者與某一用例用線連起來，表示該參與者和該用例有交互。

• 用例描述文檔：用例圖只是在總體上大致描述了產品所能提供的各種服務，讓我們對于產品的功能有一個總體的認識。除此之外，我們還需要描述每一個用例的詳細信息，這些信息應該包含以下內容
• 用例名稱：本用例的名稱或者編號
• 行為角色：參與或操作(執行)該用例的角色
• 簡要說明：簡要的描述一下本用例的需求(作用和目的)
• 前置條件：參與或操作(執行)本用例的前提條件，或者所處的狀態
• 后置條件：執行完畢后的結果或者狀態

在互聯網產品和設計中，用例的使用越來越少，通常有了產品原型再加上功能流程圖和功能說明文檔就能夠將產品需求詳細的表述清楚，所以也沒有必須撰寫用例了。但是在大公司里，往往會追求產品流程的規范性，要求撰寫用例，不過在敏捷開發的時候也會采用其它更有效率的方式，不一定非要撰寫用例。

功能流程圖

由于用例文檔以文字為主，并且格式復雜，不適用于高效率的產品需求表述，所以展現邏輯流程的“功能流程圖”是一個簡潔直觀的可替代用例文檔的方式。

功能流程圖是一種使用圖形的方式表示算法邏輯的圖表，其展現方式也不會產生“歧義性”，便于理解，邏輯出錯時也非常容易發現，并且可以直接轉化為程序需求描述文檔。

PRD文檔

前面的幾個步驟是為了幫助我們梳理需求、驗證可行性和明確細節，到了這一步的時候我們已經非常清晰的了解產品需求，此時撰寫產品需求文檔可以大大減少和避免了撰寫文檔時容易忽略的細節黑洞。

產品需求文檔是將產品規劃和設計的需求具體形象化表述出來的一種展現形式，主要用于產品界面設計和研發使用。因為每個人的習慣和團隊要求都是不一樣的，所以產品需求文檔沒有統一的行業規范標準，無論以什么樣的格式撰寫產品需求文檔，最終的目的都是讓執行人員能夠理解產品需求，根據需求完成產品。

關于PRD的范例網上有很多，這里就不一一貼出來了。不過個人認為，設計師或開發人員拿著Word版的PRD很難直觀地審查頁面中的元素屬性、交互效果或是用例規則，合理地利用Axure中的屬性、說明與樣式可以更直觀的將需求說明與元件結合在一起，并準確無誤地傳遞參數信息，所以用Axure寫PRD也受到了部分產品經理的青睞。

作者：Milov（微信：milov_wy），有安卓開發、平面設計相關經驗，正在學習產品。

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