PRD文檔構建及使用流程

90 評論 69864 瀏覽 744 收藏 18 分鐘

正如大家在工作中遇到的那樣,產品需求文檔越來越被重視,因此整理了這份文檔方便大家日后在工作中,更加快速的構建自己的產品需求文檔。

此文檔由Axure構建。

附上文檔預覽連接:http://www.uedart.com/demo.html

首先我整理了我對此文檔需求的結構如下:

本次采用的是一個項目中多平臺多版本的控制模式,方便管理同一項目中的不同類型任務需求,主要包含了兩部分:產品簡介+產品文檔,接下來,我將根據每一部分做具體的用法介紹。

產品簡介使用介紹

1. 產品簡介

對項目本身進行簡短的介紹,方便理解本次項目的幾個主要組成部分:

  • 簡要說明產品的使用價值
  • 我是誰(一兩句話寫清楚產品的身份)?
  • 我有什么用(我是做什么的,我能提供什么服務等)?
  • 為什么選擇我們(與競爭對手相比,我們產品的優勢,核心競爭力是什么)?
  • 目標用戶、使用場景
  • 產品的主要用戶群是誰?
  • 用戶主要在什么場景下使用我們的產品。
  • 行業概要
  • 簡要闡述行業現狀
  • 未來的發展趨勢
  • 競爭對手情況分析

2. 版本說明

這里主要是對自己的項目進行版本更替說明,以及多平臺項目進行版本說明,做好版本鏈接到對應的產品文檔當中去。

3. 自查表

這里主要列出了當我們在進行文檔撰寫過程中,所需要注意的事項,方便完成文檔后,對文檔進行自查,完善文檔的不足之處;是否完成列表欄采用的是文字圖標進行對錯的標識。

這套文字圖標是我經常使用的,附上鏈接?http://www.axureux.com/home/fontawesome.html

產品文檔使用介紹

根據版本說明創建對應的產品文檔,并在版本說明中做好對應版本的鏈接跳轉(采用的是在新標簽中打開),產品文檔命名方式是“平臺-版本名”,方便區分。接下來主要針對產品文檔的各個頻道進行說明,方便大家更好的進行修改和使用。

1. 菜單欄

組成部分:項目名稱+頻道欄目一級切換+子屬性二級切換+不同產品文檔的切換。

本菜單除開二級切換,其余部分采用的是母版制作,所以大家可以根據自己的需求進行調整。

對應彈出選項采用的是動態面板制作,可以根據不同欄目進行管理,按需求進行增減與調整。

對應不同產品文檔的切換做好鏈接跳轉,因為我里面只有一個文檔所以沒做鏈接,同樣這個使用動態面板制作,可以按需增減與調整,做好鏈接跳轉到對應產品文檔的更新日志頁面即可。

2. 產品概覽使用介紹

這個欄目主要包括了更新日志+需求列表+開發排期。

更新日志:主要記錄此文檔的修改記錄,方便查閱負責人與修改人,以及修改內容時間等信息。

需求列表:列出本次版本項目,所需開發的新功能和調整的功能,說明原因,方便后面對調整新增的功能進行測試,排查遺漏。

開發排期:對項目進行時間點安排,及時跟進項目進度(要每天更新當前進度),推進項目進行,如果大家有使用其他在線工具進行項目進度管理也可以在排期詳情中附上鏈接,方便查閱更加詳盡的開發進度。

3. 產品架構

這個欄目主要包括了實體關系圖+結構圖+業務流程圖+任務流程圖+頁面流程圖,這個欄目主要是產品在梳理項目需求所使用的。

實體關系圖(又稱ER圖):我在文檔中也示例了2個實體關系圖的畫法,此圖主要是理清實體(數據對象)及其屬性的相關聯系。

實體關系圖例如:

結構圖:包含了產品結構圖和產品信息結構圖,區分了這兩個結構圖的差異,這個是產品在工作中經常用到的,對產品的欄目,頻道,頁面,模塊、元素進行梳理。

產品結構圖,例如:

產品信息圖,例如:

業務流程圖:

通過業務流程圖,鉆研關鍵事件的流程,分析為什么要這么做,探索出更深層次的問題,從而對現有不合理的業務流程進行重組優化,進而制定優化方案,改進現有流程。主要使用泳道圖來進行繪制,闡述在項目中各個角色是如何產生相關聯系。

業務流程圖,例如:

任務流程圖:基于業務流程,進行任務流程梳理,闡述角色和程序發生交互的流程,你如何進行操作,系統如何進行反饋。

任務子流程圖:

頁面流程:

根據不同的子任務流程,對其交互過程中所需的頁面及其操作點,進行梳理,方便理解各個頁面間的跳轉關系,是如何產生聯系的。這個我認為是很關鍵的,不是簡單的將頁面關聯在一起就完成了,而是通過任務流程,理解頁面間是如何產生彼此聯系。這樣可以更好的思考,流程是否完善,能否提高用戶體驗,并對頁面進行優化。

頁面總流程圖:

4. 產品原型

這個欄目主要包括了全局說明+控件規范+交互原型+交互說明,這個欄目主要是產品與UI、程序配合時使用,通過原型圖能更好的闡述產品的整體樣貌。

全局說明:主要對產品的通用性進行說明,譬如:z軸內容層級、屏幕適配性、功能權限、加載方式、彈層樣式、字段屬性、異常狀況、頁面交互方式,根據項目本身進行通用性的闡述。

這里我只列出了幾項,大家可以根據自己的需求添加欄目和相應頁面。

控件規范:對自己在原型中使用的一些元素、控件、組件做統一的規范,這邊要感謝@大梨,這邊我使用的是他整理的web元件以及移動元件,具備統一性, 整個原型項目看上去才會更加簡潔美觀。

掛載了兩套,大家可以根據自己需求調整內聯框架的跳轉,以及也可以自己制作相關的控件,保證原型項目的一致性。

交互原型:這里主要展示帶交互的原型,原型的目錄結構可以按照產品結構圖定義好的頁面進行。

交互說明:這里主要對原型頁面進行描述說明,根據用戶與界面之間發生的交互操作,提供相應的反饋,可能是提示內容,也可能是界面內或界面之間的跳轉。

在這之前可以設置一個目錄頁,用來快速調整每個頁面的說明。

這里提供了兩種交互說明的方式:一種站點地圖方式,按照產品的信息結構,對每個頁面進行描述,一個頁面一個描述。如下:

另一種方式是:流程分解方式,控制一個流程3-4個頁面,以流程的方式對其進行描述介紹。

如下:

此架構用圖來自?Qinsman,感謝!

大家可以根據項目對原型說明的具體需求進行選擇,我比較常用第一種,方便頁面的調整和修改。

5. 非功能需求

這里包含了三部分:埋點需求+性能需求+兼容性需求,對產品中的非功能需求進行描述,根據自身需求進行添加。

6. 用例文檔

這里包含了四部分:角色說明+用例關系+活動過程+用例描述。

用例圖是UML的一種類圖表現方式,是從用戶角度描述產品功能,并指出該用戶在產品各功能中的操作權限。流程圖是通過線框圖形的方式描述產品功能的處理過程,主要是描述功能的執行順序、分支和循環的邏輯。

7. 需求卡片

主要用來采集需求,往往在項目進行中可能會根據一些情況對需求進行調整,這里我們需要對需求進行整理,方便后續查看,主要包含了:

需求編號:該需求的編號或序號,可以是時間+序號的形式,如:20150430-001。

需求類型:分為功能性需求和非功能性需求。

  • 功能性需求:主要涉及產品邏輯架構、交互、功能以及BUG類的需求,這些需求的重要性較高,因為涉及到產品的正常使用。
  • 非功能性需求:主要涉及產品的UI設計等等,如某個按鈕應該為矩形還是圓角矩形,這些需求重要性較低,并不影響產品的正常使用。

需求來源:該需求主要提出的人員以及提出的場景。

  • 提出人員:該需求提出人員的詳細信息,如性別、年齡、教育程度、崗位經驗等信息,這有助于產品經理了解該需求所對應的用戶類型,能夠在需求梳理時,了解某個用戶群體的需求類型。
  • 提出場景:該需求提出的使用場景、如地點、環境和時間等,便于產品經理了解用戶是在何種條件下會使用該需求所涉及的功能,如果該需求提出場景是經常發生的,那么該需求的重要性就會相對有所提高。

需求描述:這是單項需求卡片最為重要的要素,該部分主要體現的是需求的詳細內容,如需求所涉及的現象,希望得到解決的方案等等。該要素會對需求產生各種描述,需要產品經理在整理需求時,進行思考、分析和歸納。

需求原因:該需求提出的原因,該部分可能會在“需求描述”中也予以體現,主要體現的是提出該需求的主要原因,該部分便于產品經理對需求描述進行歸納總結。

需求屬性:分為重要性、緊迫性以及持續時間。

  1. 重要性:該需求對于產品的重要程度,該需求的完善對于產品的成長運營具有積極意義;
  2. 緊迫性:該需求完善的時間要求,主要體現在功能類需求,其中BUG類需求最高,該需求的解決便于產品的正常使用;
  3. 持續性:該需求的持續時間長度,主要體現為該需求是否能夠隨著產品的不停迭代更新,依舊能夠對產品的使用發揮作用。

附上文檔預覽連接:http://www.uedart.com/demo.html

 

本文由 @時光若刻 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Pixabay,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 前輩想跟你一起交流學習,能否發個原型包到;414116852@qq.com,方便的話想加一下QQ

    來自北京 回復
  2. 大佬寫的很奈斯,最近轉型產品經理,一直在頭疼prd文檔怎么寫,還望能指教一二。求個原型模板學習學習!!1927686371@qq.com

    來自安徽 回復
  3. 很系統,對規范文檔有很大幫助,求一個模板。58456071@qq.com

    回復
  4. 求大佬原型學習學習。18134387@qq.com?;蛘甙l一下在大牛的鏈接也可以

    來自廣東 回復
    1. 文章底部有鏈接

      回復
  5. 可以加個qq么,657866881

    來自北京 回復
  6. 求原型包學習

    回復
    1. 求原型包學習,謝謝11967094@qq.com

      回復
  7. 產品文檔top1 ? ,請問做一個這么全面的文檔大概需要多少時間呢?如果把產品過程分為調研理解溝通思考需求,完成原型書寫兩部分,每個部分需要花費多久?順便求原型包,郵箱348035626@qq.com ??

    來自北京 回復
  8. 非常好,結構比較清晰,文檔很好看,學習一下

    來自江蘇 回復
  9. 大神,求詳細模板資源和求加qq互相交流,840809536@qq.com ?

    來自廣東 回復
  10. 很胖~一直很想知道詳細的PRD文檔怎么寫完整,學習了,250882039@qq.com,原型包求分享~

    來自廣東 回復
  11. 帥哥,仔細看了這篇文章,覺得文章寫的很好,原型做的也很棒,剛好最近在找用Axure寫PRD模版,可不可以給個原型的下載地址?

    回復
  12. 大梨?

    來自浙江 回復
  13. 兄弟,這是產品大牛上的原型,被你搬過來了吧,盜用別人的東西發布有意思么

    來自四川 回復
    1. 大哥,大牛上也是我發布的~

      回復
    2. 哈哈哈哈??????

      來自北京 回復
    3. 哈哈,很尷尬

      來自北京 回復
  14. 關于需求卡片跟用例文檔這一塊兒,有更加詳細的說明么?

    來自上海 回復
  15. 產品簡介 – 版本說明 里有關聯平臺,然后更新日志里沒有平臺呢?有點沒看明白
    還有一個需要說明的是 現在都講究敏捷開發,可能一個小的任務迭代都不需要文檔,簡單的確認下流程、交互、文案加以原型輔助,開發就直接開干

    來自四川 回復
    1. 更新日記是在版本里的結構里的一個模塊,也就是每個版本一個更新日志,文檔的作用對象一個是產品自己,一個是開發,至于每個團隊的配合流程,就根據實際場景靈活應對

      來自福建 回復
  16. 梳理的很詳細,規范和流程做的真的很好,有個問題:產品結構圖、產品信息圖之間的區別還是有些不理解,可以做個詳細的剖析嗎? ?

    來自北京 回復
    1. 簡單來說,結構:產品頻道-產品模塊-產品功能點,信息:具體到具體要展示的信息內容,有點像開發所需記錄的信息字段,

      來自福建 回復
    2. 感謝 ??

      來自北京 回復
    3. 老師,求原型包,704062664@qq.com

      回復
    4. 可以搜索 ‘‘功能結構圖、信息結構圖、結構圖’’

      來自浙江 回復
    5. 感謝 ??

      來自北京 回復
  17. 很贊????啊

    回復
  18. 求原型包學習一下

    回復
  19. 真贊,學習了,17852353@qq.com,原型包求分享~

    來自北京 回復
  20. 大佬寫的真棒,能求一份原型圖嗎?

    回復
  21. 求帥哥的原型包 ?? 2378172493@qq.com

    來自廣東 回復
  22. 我也想知道做的這么細致,規范的文檔耗時多久???

    來自浙江 回復
    1. 我也想問,感覺沒那么多時間來梳理文檔啊,都很多雜事處理每天都

      來自重慶 回復
  23. 大佬,求聯系方式,交流下

    來自北京 回復
  24. 很完備了,請問你做這個份需求文檔耗時和需求團隊人數?

    來自廣東 回復
  25. 太牛了 超級詳細 準備這些文檔 工時怎么計算的 會不輝占有時間

    回復
  26. 您好,看了您這篇文章。感覺您寫的很詳細,全面。但是有幾個問題想請教您一下,不知道是否方便加個微信或QQ;

    來自北京 回復
    1. 你qq多少

      來自福建 回復
    2. 1765709561,謝謝您。 ??

      來自北京 回復
  27. 贊一個 原型是邏輯的體現 太棒了

    來自安徽 回復
  28. 寫的太帥了,原型做這么漂亮,人一定長的很帥 ?

    來自奧地利 回復
    1. 哈哈哈,一般般,不帥,但也不至于嚇到人

      來自福建 回復
  29. 其他的感觸良多,項目管理那一塊我還是有點懵

    來自廣東 回復
    1. 可以加個qq一起討論

      來自福建 回復
    2. 求原型包 ??

      來自安徽 回復
  30. 很好

    來自廣東 回復