當我們在設計產品時我們寫些啥

假設我們已經完成了產品的Business Plan/MRD的Review，要開始做詳細的產品設計PRD了，那麼我們怎麼最高效的開始這件事？ 每家公司都有自己的PRD模板，有些用Word、有些用wiki，有些要求詳細的Mockup，有些只需要功能說明，但是綜合來看，個人感覺用五張圖（U-M-F-P-M）便可以將你的產品表達清楚。

User Experience Funnel - 用戶體驗漏斗

Module Structure - 模塊結構

Function Tree - 功能樹

Page Relationship - 頁面關係

Mockup - 產品模型

試試能不能不用任何文欄位落，僅僅靠這五組圖說明你的產品設計？

User Experience Funnel

用戶體驗漏斗提現你產品的核心使用步驟，可以簡單地告訴Reader你的產品主要交付怎樣的價值。比如，

理財App的核心漏斗是：註冊 - 了解理財項目 - 投資；

借款App的核心漏斗是：註冊 - 了解費率 - 提出借款訴求 - 審核 - 放款 - 還款；

酒店App的核心漏斗是：註冊 - 搜索目標酒店 - 了解酒店、房間詳情 - 預訂 - 入住；

共享單車的核心漏斗是：註冊 - 掃碼 - 開鎖 - 騎行 - 關鎖。

用戶體驗漏斗是一張非常簡單的流程圖，你也可以嘗試將你的體驗分支表述上去，但不管怎樣，核心的體驗是簡單的，要和分支體驗獨立開表述，比如：

理財App的用戶在完成投資後，我們還希望其完成這個漏斗：投資 - 分享投資紅包 - 其好友加入投資；也可能是：投資 - 追加投資；

共享單車：關鎖 - 分享騎行紅包 - 更多好友加入騎行；

酒店：預訂房間 - 預訂接送 - 預訂周邊遊玩項目。

Module Structure

模塊結構能夠表述產品的模塊分布，有哪些模塊，哪些是支撐性的、哪些是面向用戶的、哪些是第三方提供的等等，一般模塊結構圖能夠幫助你將產品拆解為鬆散耦合的架構，並幫助排列優先順序。在體量較大的成熟互聯網公司，往往有一部分模塊是可以拿來即用的。比如，一個用戶數據產品的模塊結構可能是這樣的：

基於這個模塊架構，可以簡單的繼續闡述產品開發的Roadmap，比如：第一期實現客群管理、第二期客群分析、第三期Service，在這些過程中逐步完善數據源管理……

對於團隊分工，模塊結構也可以提供與參考，比如：Service Team、管理平台Team、數據處理Team；

模塊結構圖考驗產品經理抽象和解耦能力。

Function Tree

一般我們使用Mindmap的形式來整理產品的完整功能結構，這個圖原則上是Module Structure的延續，將每一個模塊拆解為具體的功能點，繼續舉例這個數據產品。 第一期我們希望實現基本的客群管理和客群分析，那麼具體的功能會涉及到：

每個功能一個分支，然後子功能、孫子功能；

每個功能點的名字可以非常簡單，重點是梳理；

當前打算開發的可以用黑色，未來才做的可以用灰色。

基本上，這是一個非常細的梳理圖，整理完成後產品經理的腦海里應該會有基本的產品形象，並開始思考具體的Mockup。

Page Relationship

設計一個具體的Page一般至少要三個迭代： 頁面的功能描述 -> 交互稿 -> 視覺稿。Page Relationship主要目的是表達這些Page間的關係，並且幫助產品經理梳理清楚Page的數量，以免遺漏。因此一般到頁面的功能描述級別即可。繼續舉例這個數據產品：

Page Relationship可以和Function Tree進行互補，幫助產品經理雙向核對功能設計的完整性和合理性；

交互設計的同事也可以根據產品經理提供的Page Relationship來規劃交互設計的進度和優先順序，同理，開發人員、測試人員也是；

可以基本判斷，當Function Tree和Page Relationship這兩張圖都無誤後，產品設計中基本不會有功能點被遺漏。

Mockup

個人認為，當你完成了以上工作後才應該開始做Mockup，且大型互聯網公司的Mockup都會有專門的交互團隊來設計，產品經理不需要親自接入太深。Mockup最終會給整個Team一個更加具象的畫面。這裡就不展開了，很多入門的產品經理往往都是反著來的，現有Mockup，然後直接拿著Mockup就開始推進，請不要這樣。

本文作者：趙征宇（點融黑幫），人稱「毛毛（MAOMAO）」現任點融產品總監，十年產品小生，曾就職於1號店、百姓網，興趣閑置交易社區Have創始人，攝影品牌「鎂光人生"聯合創始人。 在互聯網廣告、大數據平台、商業化、用戶體驗、GrowthHacker等領域有著較為豐富的經驗。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！