作為產品經理在設計產品過程中你需要使用哪些文檔?

相信很多同學都很好奇,在一個產品的設計中產品經理到底需要輸出多少文檔,并且這些文檔又有什么作用呢?

相信產品原型、PRD這兩個文檔名稱肯定是大家聽的最多的,但是在一個產品的設計中光有這兩個就夠了么,先讓答案是否定的,下面我就把我在產品的設計中會用到的文檔類型及其作用做一個詳細說明。

首先,在一個產品需求收集階段,我們需要進行大量的用戶訪談或者是調查,在這個階段我們需要準備一封叫做“需求管理列表”的文檔(也有人叫做“需求池”),這份文檔也是我們后續工作的指導性文檔,很多其他的文檔都是從這份文檔衍生出來。下面是我們自己的需求管理列表的截圖:

需求管理列表示例

這份表格中的內容大多比較好理解,特別需要注意的是優先級和需求來源,這兩項屬性是后續決定該需求是否實現的重要依據,來源一般可以分為公司內部和外部用戶,具體在往細分可以根據自己所在團隊的實際情況決定。

在需求收集階段完成之后,產品經理需要快速的把需求功能化,這一階段需要把需求抽象、挖掘需求的本質,很多時候不同的需求可以整合到一個功能中進行實現。例如:需求1、我要能夠及時的和朋友聊天;需求2、w我想要把自己拍的好看的圖片傳給我的朋友;需求3、要是能夠和朋友進行語音或者是視頻聊天就好了。類似這樣的描述在需求收集階段是經常出現的,產品經理需要挖掘其背后的本質,進行需求抽象,形成實際的功能,于是我們需求產生一份功能列表和功能結構圖(信息結構圖)

功能列表示例

功能結構圖示例

在需求功能化的階段,對每一個子功能都需要整理出對應那個的功能流程圖,流程圖是產品經理梳理自己的產品邏輯、驗證產品效用的重要步驟,在制作流程圖的過程中會窮盡功能的各種狀態和操作,并在腦海中不斷的推演功能的使用場景。在這一階段一定要定義好具體功能的狀態,通過狀態去控制不同的操作,而操作又可以改變狀態,在這一階段如果能夠對狀態和操作進行十分明確的定義,那么在開發進行具體實現時邏輯也會清晰,因為在具體的功能實現中流程往往包含正向和逆向,而通過狀態和操的相互影響是解決這兩種流程的較優解決方案(至少我現在沒有找到更好的解決方案)。

功能流程圖示例

往往在你完成了這兩份文檔的時候,一般你也開始進行原型設計了,會產生線框圖、低保真原型、高保真原型等等一系列的原型文檔。在很多的產品經理社區一直在討論原型和prd能不能整合為一個文檔,個人認為在原型中加入必要的功能說明和交互說明是很有必要的,但是PRD也是不可缺少的文檔,所有文檔的存在都有其價值所在,不明白其價值而討論起存在的合理性都是耍流氓。原型多是在項目進行中使用,其特點:直觀、有交互邏輯、能給項目成員真實的體驗,在完成的過程中產品經理更多的是處于交互體驗的角度去考慮問題;而PRD更多的是保證產品迭代的延續性,其特點:內容全面、定性定量,在團隊成員更換、產品周期較長時發揮其作用,在完成過程中產品經理更多的是規范規則和定義。兩個文檔的意義,決定了他存在的價值。

原型頁面結構示例

在以上三分文檔(功能列表、功能結構圖、產品原型)準備妥當之后,我們就可以愉快的去組織第一次評審會議了,如果要求高的同學,也可以準備對應的演示PPT,主要是對整個產品的介紹,有部分公司可能需要準備MRD文檔,進行立項說明,爭取更多的公司內部的資源,而像我現在所在的公司屬于創業型公司,產品經理提出的絕大部分功能都是為了解決實際問題的,一般不會存在爭奪資源的情況。而在不斷的評審確認的過程中,一般會輸出更多的魚其他人員對接的文檔,與UI溝通的界面跳轉流程圖、與測試溝通的用例等等。

界面跳轉流程圖示例

而在評審和確認階段,需要把最開始的需求管理列表和產品功能列表完善,把項目開發計劃于技術人員進行確認,并逐漸完善&優化原型文檔、PRD,把產品標準和規則、功能定義及說明、產品風險等事項進行充分考慮。而評審通過后,視覺進行UI設計(原型、界面跳轉流程圖)、開發進行技術實現(原型、PRD)、測試進行功能檢測(功能列表 、PRD、原型)主要的參考依據都是以上文檔,至于PRD的模板優秀的太多了,我也就不再進行累贅了。而最后作為一個產品自然少不了自己也體驗并測試產品,還會輸出測試反饋文檔,提出功能優化意見。

測試反饋一覽表示例

往往在完成了一個產品后我們都需要對其進行部署、上線,而每一次的上線我總是提心吊膽著,感覺每一次的上線都是在走鋼絲,錯了一步都會造成巨大的影響,功能是否全部測試到位、程序的代碼是否完整的提交了、新老版本直接更新會不會出現意想不到的情況等等,這些問題一致困擾著我,而在經歷了若干次的提心吊膽之后,我把上線中可能會遇到的問題整理成了一份上線前的自查清單,每次在上線前都會發送給項目中的各個成員要其對清單中的具體內容進行確認,以保證產品上線的質量,至此一個完整的項目便算完結,而后續的數據統計分析等環節,有時候更多可能是運營需要保證的工作。

產品上線自查清單示例

以上就是我在整個項目的實施過程中需要用到的文檔,產品經理需要對接的角色太多,而不同角色的特定或是專業知識也是不一樣的,不可能通過一份文檔對接所有的干系人,所以會衍生出各種各樣的的文檔,而這些文檔也是必須在實際的項目中遇到問題之后才能體現其價值,而我也是出于希望你能夠去實際體驗、領悟的目的,故不提供以上文檔模板的下載鏈接。

其實文檔不在于類型有多少,內容有多豐富,只在于需要使用你文檔的人或是關鍵點能夠發揮文檔的價值即可,一切的文檔都是為了保證項目的正常進行,保質保量的完美實現。

文中若有不妥的內容,歡迎大家指正!

本文由 @keeliu(微信號cainiaoPM)發布

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,362評論 6 537
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,013評論 3 423
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,346評論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,421評論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,146評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,534評論 1 325
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,585評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,767評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,318評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,074評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,258評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,828評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,486評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,916評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,156評論 1 290
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,993評論 3 395
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,234評論 2 375

推薦閱讀更多精彩內容