嗨！菜鳥~我們來談談你的新工作（文檔篇） | 人人都是產品經理

寫給我的第一任助理

是一個菜鳥產品經理寫給她的菜鳥產品助理的入職培訓教材，教材分為「習慣」「流程」「文檔」「產品思維」等幾個部分。

如果我給你一篇文檔，讓你按照我的格式來寫。而實際上你並不明白為什麼要寫這些內容？為什麼按照這個順序來寫？這個內容是不是真的需要？在這樣的情況下，你可能會做一些毫無意義的文字堆砌浪費珍貴的時間，或者總是無法確定自己的文字是不是被需要的。

我希望你避免一種「八股」的做事方式，有些嚴格的規定會讓你失去對做這件事情的原因本質的了解，而失去了一些你可以掌控的隨機應變。

當然在一切初學者面前，一個專業規範的文檔格式對他們的工作是實用的幫助，所以我還是會從「規範」談起，稍後與你分享一些「靈活」的原則。

規範

首先我們應該了解，規範的文檔撰寫源於規範的流程（我已經在流程篇中向你介紹過），因我們在流程中做的大部分事情，都會有相對應的工作「產出」，這些產出可以統一被稱為「文檔」。

策劃前期

BRD商業需求文檔

BRD是一個在企業商業戰略層面撰寫的文檔，在文檔中分析大環境和市場前景，得出產品的商業目標，並核算投入產出等。對於小團隊而言……好吧，我認為這篇文檔的實用價值不太大。

1． 市場環境分析

2． 問題分析

3． 我們的優勢

4． 結論和商業目標

5． 收益與成本

6． 風險與對策

嘿~你在我的文件夾中找不到這篇文檔，它的所有內容都在boss的腦子裡。

策劃中期（產品目標、用戶需求、內容與功能需求）

MRD市場需求文檔

這篇文檔說明「怎麼做產品」，以達到（BRD中的）商業目標。它會是未來所有文檔的參考源頭。

1. 文檔說明

a) 文檔基本信息（公司名稱、產品名稱、文檔創建日期、創建人和聯繫方式、部門職務）

b) 文檔修改記錄

2. 市場說明

a) 市場問題（產品、技術、運營、用戶、商業模式等）

b) 針對大市場中的目標市場（市場規模、特徵、發展趨勢等）

c) 結論（市場定位）

d) 團隊目標（我們要從這個產品中得到什麼）

3. 用戶分析

a) 目標用戶群體（年齡、收入、學歷、地區等）

b) 目標用戶特徵分析（特點與共性）

c) 用戶角色卡：

假設真實存在的用戶Gara，為他設計年齡性別、生日、收入職業、居住地、愛好、性格等

根據他的背景推理他的技能情況（熟練使用電腦辦公等）

推理與產品相關的特徵（使用微信，單身，喜歡皮膚白長頭髮的女孩子）

針對用戶群可以虛擬多個用戶角色

d) 用戶使用場景

用戶Gara如何使用我們的產品，講一個完整的故事（時間、地點、人物、任務等）。

周五下班途中，在公交車上，無聊又寂寞的Gara打開了微信看看周圍有美女在線，加了對方好友，快樂地聊起來……

a) 用戶需求和用戶的真實需求

用戶需求：在旅途中方便地充電。

用戶的真實需求：手機電池更耐用。

b) 可能影響用戶的因素（設備、網路、速度、信息等）

不僅要羅列因素，還要詳細分析這些因素如何影響用戶使用產品的過程。

4. 產品說明

a) 用戶定位

簡單描述產品的目標用戶群體。

b) 產品定位

我們將用什麼樣的產品滿足用戶需求。

c) 用戶需求、產品核心目標

我們的目標用戶要從這個產品中得到什麼。

我們的產品幫助目標用戶解決什麼問題。

d) 產品結構

我們需要哪些類型的內容。

我們需要什麼樣的功能去支撐這些內容。

5. 產品路線

成功標準：了解我們的開發過程，知道我們什麼時候到達終點。

產品路路線經常被誤解為方向，實際上，成功的標準不見得是以方向衡量的，我們通常告訴自己「滿足哪些條件，我就成功了」而不是「向著哪個方向走，我就成功了」。

因此在規劃中，我們設定里程碑（需要完成的任務），制定可追蹤的指標（需要滿足的條件），來評估我們的工作。

一般會以項目甘特圖的形式體現，包含時間、任務、說明等內容（如下圖）

放鬆的小劇場：

BRD：嗨~為了放鬆心情~我們出去玩吧~

MRD：那我們就來商量下去哪裡玩，幾個人，完成什麼任務，空出多少時間，準備多少錢…

B、M：小P快去幹活！

接下來我們一起來了解下這個小P

策劃後期（界面交互與設計、信息架構、布局與導航設計）

PRD產品需求文檔

有時候也叫做產品說明書，最細緻也最繁瑣的文檔，開工之前一定要深呼吸，擺好姿勢。這個文檔會是所有項目成員做事的直接依據，描述要低調膚淺簡單粗暴，這樣大家才能愉快滴繼續玩耍。

1. 文檔說明（略）

2. 語言說明

a) 溝通語，明確與目標用戶溝通的語言風格，使用與用戶合拍的溝通方式。這是為了避免一些我們自以為很了解的專業術語妨礙了用戶的閱讀。

b) 命名，在用戶溝通方式的基礎上，為前台的主要功能進行命名。

如果可能，我們也可以為後台功能做命名。這樣前台語言是給用戶看的，後台語言是給我們自己看的，把兩者對應起來以防錯誤。這樣程序員的溝通壓力就不會太大（設計人員更加喜歡使用用戶語言，導致程序員的理解困難）。

c) 解釋幾個重要功能的命名，它們會在以後的文檔中被使用，現在就需要統一概念。

3. 產品說明

a) 產品結構

b) 任務流程圖

4. 全局說明

全局是指可以被套用在大部分的頁面或操作中的一些通用的規則，如果某個內容或功能與全局情況不同，就在細化中另外說明。

以下舉例兩種全局說明：

a) 設計規範

i. 布局

ii. 圖片

iii. 文字

iv. 色彩

v. 按鈕

vi. 控制項

vii. 元素……

b) 交互規則

i. 頁面和元素的切換

ii. 退出軟體

iii. 被打斷

iv. 不同網路情況

v. 常用手勢

vi. 載入方案

vii. 錯誤處理

viii. 反饋提示……

（退出軟體、打斷、切換、手勢等內容經常使用在APP產品中）

5. 細化說明

接下來我們就要描述清楚產品細節：

i 頁面布局和顯示規則

ii 頁面元素

iii 交互和操作

iv 錯誤和反饋

v 網路異常

vi 重複點擊

viii 操作中斷......

除了描述清楚正常情況下的所有內容，還要考慮到特殊場景。

這裡佔了PRD文檔百分之九十的內容，需要點耐心。

我經常使用和上文中「產品結構」相同的順序來進行說明，從頻道、頁面、模塊、元素進行描述。這種方式適合對技術不太了解的小夥伴，描述的重點是用戶看到的部分。

原型

嚴格來說原型是為了更形象地說明PRD中所描述的頁面布局信息，它在需求傳遞中扮演了重要的角色，並且我們可以讓用戶使用原型提早進行可用性測試。

它會隨著需求的逐漸明確，變得更加精緻：

1.低保真：表達布局和重點

2.中保真：表達動態和細節，

3.高保真：模擬產品。

避免常見的錯誤

客觀

主觀：「這裡要使用第一人稱」

客觀：「參考文案規範」

避免使用主觀的內容，用客觀事物做參照可以避免反覆修改。

具體

「具體」而不是「詳細」。

確保文檔中不要出現漏洞，清楚明確。

但是不要追求描述每一個細節。

應該包含設計或開發過程中存在的可能會產生混淆的功能定義。

記錄

不是「展望未來」，是「記錄」當下的決議。

所以我們要小心文檔中出現一些不確定的「想像」。

你完全可以把文檔內容拆分開來，或者合併，或者重組，或者刪減。你只要確保以下幾點：

1. 你想要的內容沒有遺漏

2. 你不需要的內容可以沒有

3. 你的文檔閱讀流暢，邏輯可以被理解

Ps：聽說點「很好看」那個方塊，天上會掉金磚……

本文為作者Gara投稿發布，轉載請註明來源於人人都是產品經理並附帶本文鏈接

第一篇：嗨！菜鳥~我們來談談你的新工作（習慣篇）

第二篇：嗨！菜鳥~我們來談談你的新工作（流程篇）

第四篇：嗨！菜鳥~我們來談談你的新工作（產品思維篇）