PRD分享:直播產品需求文檔-版本2
本文筆者對一款直播產品進行產品需求分析輸出此份PRD文檔。該文檔由幾個板塊構成:用戶角色描述、產品概述、產品頁面說明、其它產品需求以及相關文檔。
設計優化生活,2017年時的一個項目,項目已經落寞。在我還沒有準備入行時做的這份直播文檔,主要功能是在原型體現。說明文檔或有缺失,希望指正,也希望借大家批評的機會,鍛煉產品邏輯及基礎文檔PRD能力。(基本框架是參考人人都是產品經理-PRD需求文檔模板后做的,感謝?。?/p>
需求文檔
PRD文檔
目錄
一、簡介
1.1 目的
1.2 范圍
二、用戶角色描述
三、產品概述
3.1 背景介紹
3.2 目標
3.3 總體流程
3.3.1 業務流程
3.3.2?主播開直播流程
3.4 功能架構圖
3.5 信息架構圖
3.6?功能摘要
四、 產品頁面說明
4.0? 首頁板塊
4.0.1. 產品概述
4.0.2. 功能摘要
4.0.2.1 首頁功能摘要
4.0.2.2 首頁原型圖
4.0.3.搜索說明
4.1? 動態板塊
4.1.1. 動態板塊概述
4.1.2. 動態功能摘要
4.1.3. 動態狀態說明
4.1.3.1 用戶場景
4.1.3.2 前置條件
4.1.3.3 需求描述
4.2? 直播間
4.2.1. 直播間概述
4.2.2. 直播間功能摘要
4.2.2.1 直播間功能摘要
4.2.2.2 直播間原型圖
4.2.3. 主播直播實名認證
4.3? 排行板塊
4.3.1. 排行板塊概述
4.3.2. 排行板塊功能摘要
4.3.3. 排行板塊狀態說明
4.3.3.1 用戶場景
4.3.3.2 前置條件
4.3.3.3 需求描述
4.4? 個人中心
4.4.1. 用戶場景
4.4.2. 前置條件
4.4.3. 狀態說明
4.4.4. 流程說明
五、其它產品需求
5.1 性能需求
5.2 安全需求
5.3 兼容性需求
六、 相關文檔
一、簡介
1.1 目的
本文檔為“千鶴直播1.0”的產品需求文檔,主要作為確認需求以及系統分析設計的依據。
1.2 范圍
此文檔主要描述“千鶴直播1.0”前端頁面涉及到的功能點、以及部分交互細節。本文檔主要讀者為技術部門的開發人員、測試人員,以及視覺部門的視覺設計UI/UE等相關人員。
二、用戶角色描述
三、產品概述
3.1 背景介紹
移動直播的興起,使直播的范圍從室內走向了室外,應用的場景大大拓展開來了。
直播不僅僅是一種表演形式,泛生活與泛娛樂化的”直播+”將O2O、購物、旅游、教育、財經、時尚、音樂、科技等場景與互聯網商業模式相結合進行全景直播,也使得直播進入更多細分垂直行業。移動直播使得直播已不僅僅是一種表演的形式,而是用戶獲取信息、滿足需求、互動娛樂、社交的重要途徑。
【千鶴直播】定位是文化、藝術、風土人情、旅游產業展示的最佳窗口,是各名團、名人、大咖、明星們與他/她們的粉絲、觀眾親密無間的交流互動平臺,是為打造更多名人、明星的孵化器,更是人人都可以展示自我、實現夢想的搖籃!
3.2 目標
成為高端的人文社交直播平臺。
3.3 總體流程
1)業務流程
2)開播流程
3.4 功能架構圖
3.5 信息架構圖
3.6?功能摘要
四、產品頁面說明
4.0 首頁板塊
4.0.1. 產品概述
滿足用戶的核心需求,最大的滿足用戶體驗。從功能點,交互上盡量與市場現存的同類產品存在一定的差異化。為用戶提供一個優質的直播體驗,提高用戶滿意度、粘度。
4.0.2. 功能摘要
4.0.2.1 首頁功能摘要
4.0.2.2 首頁原型圖
4.0.3.搜索說明:
4.0.3.2用戶場景:
用戶有針對性的尋找,進入首頁,點擊搜索按鈕,
4.0.3.3流程說明:
4.0.3.4需求描述:
- 點擊進入搜索頁面“取消”按鈕退出搜索頁面;
- 進入該頁面時默認彈出鍵盤、輸入框獲得輸入焦點,未輸入任何內容時鍵盤上的“確定”按鈕失效;輸入內容后“確定”按鈕有效,點擊后彈出搜索結果頁面;
- 關鍵字匹配規則:關鍵字為ab,優先顯示ab,在顯示abc,在顯示dabc;
- 搜索無結果則在tab頁面提示“未找到內容,換個關鍵字再搜搜看~”。;
- 用戶搜索結果展示信息:用戶頭像、昵稱、粉絲、關注關系——如果已經關注過該用戶則不顯示關注按鈕,沒有關注過則顯示“關注”按鈕,點擊關注把用戶添加到我的關注列表,關注按鈕消失;點擊頭像昵稱跳轉到個人主頁;
- 搜索結果分頁顯示,每頁顯示3條,點擊“加載更多”查看更多;
當用戶點擊“搜索”按鈕時,搜索頁面由右向左滑出:
原型說明:
4.1? 動態板塊
4.1.1. 動態板塊概述
上傳直播回放、片段、展現日常生活,粉絲觀看視頻回放,用戶隨時把身邊所看所感所想的發到動態相互交流,是為了拉近用戶們之間的距離,增加用戶粘性。
4.1.2. 動態功能摘要
4.1.3. 動態狀態說明
4.1.3.1 用戶場景
打開APP,點擊查看動態板塊
4.1.3.2 前置條件
已注冊用戶,已發布動態或已關注主播發布過動態。
4.1.3.3 需求描述
- 按時間最新的顯示在上面(若取消關注則不顯示);
- 列表每次顯示15條,上翻后加載更多,支持下拉刷新當前頁面。
4.2? 直播板塊
4.2.1. 直播板塊概述
直播間作為直播平臺的核心板塊亦是用戶的核心需求,最大的滿足用戶體驗;為用戶提供一個優質的直播體驗,提高用戶滿意度、粘度。
4.2.2. 直播板塊功能摘要
4.2.2.1 直播板塊功能摘要
4.2.2.2 直播板塊原型圖
4.2.3. 主播直播實名認證
4.2.3.1用戶場景:用戶打開APP,登錄直播
4.2.3.2輸入/前置條件:已成為平臺注冊用戶
4.2.3.3流程說明:(用例圖、時序圖)
4.2.3.3需求描述:
4.3? 排行板塊
4.3.1. 排行板塊概述
展現用戶在平臺人氣的排名展示(主播人氣榜和富豪榜),通過打賞禮物、會員服務,提升排行榜名次。
4.3.2. 排行板塊功能摘要
4.3.2.1 排行板塊功能摘要
4.3.3. 排行板塊狀態說明
用戶場景:用戶想要查看個人排行或通過排行觀看排名較高直播
前置條件:用戶點擊進入排行榜
需求描述:
- 人氣榜按最新最新粉絲數的顯示,由高到低依次排列(前百名);富豪榜按照刷禮物金額的多少由高到低依次排列(前百名)。
- 列表每次顯示15條,上翻后加載更多,支持下拉刷新當前頁面、切換tab時刷新當前頁面。
- 用戶頭像、昵稱,粉絲數(人氣榜)/禮物金額(富豪榜)。
- 點擊后跳轉到用戶個人主頁。
- 用戶未登錄情況下點擊關注按鈕,跳出登錄界面,成功登錄后才能使用。
原型說明:
4.4? 個人中心(我的)
4.4.1. 用戶場景:進入我的進行設置個人賬號基本信息,查看資料。
4.4.2. 輸入/前置條件:打開APP,進入我的
4.4.3. 狀態說明:
個人基本信息設置完成后將會保存設置,除非下次更改設置;如果用戶沒有上傳頭像,使用默認頭像。
4.4.3. 流程說明:(用例圖、時序圖)
五、其它產品需求
5.0 性能需求
5.0.1. 3G或3G以上網絡,從啟動頁顯示完畢到首頁顯示完畢,時間不超過1s,普通頁面的加載時間不超過300ms,生成行程結果頁面的加載時間不超過2s。
5.0.2. 如果頁面加載時間超過3s后仍無響應,需給出提示信息:網絡繁忙,請稍后重試;如果網絡中斷,需給出提示信息:網絡異常,正在重新連接。
安全需求:
- 用戶密碼采用MD5加密方式,數據庫中存放加密后的密碼。
- 代碼要求經過反編譯處理。
- 通信采用https協議。
5.0.3. 列表頁默認展示15條,滑到底部加載更多,加載列表信息的時間不超過100ms。
兼容性需求:
- ?iOS:應適配iPhon5以上機型,支持iOS8.0及更高系統版本。
- ?Android:應適配華為、小米、三星等主流廠商設備,支持Android 7.0及更高版本系統。
5.0.4. 圖片采用異步加載方式,圖片未加載完也可以進行操作。
5.0.5. 信息支持緩存機制,只要加載完成,網絡中斷后仍可顯示信息。
六、相關文檔
主播等級文檔 與 財富等級文檔
本文由@believe 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash, 基于CC0協議。
寫的好詳細,學到了
哈哈哈 樓主,張俊平是你的名字嗎,我。。張駿平
哈哈,緣分啊,握手
互關了
有個問題哦,你在開直播審核上出現了一個時間差的問題。既然流程圖上表示填寫過程中就會提示是否正確那思維就是提交之后之后就會立馬說明認證成功呀,那么提交界面就多余了。
最近正在做直播,能請教嗎?
原型圖Axure畫的嗎
請問下流程圖是拿什么工具畫的
學習了,贊
寫得不錯??
寫的很好。
補充新文檔(完整版),版本號區分于上一版,在新文檔前提綱中概述新增/修改功能,在新文檔中標注為新增/修改功能:20xx年xx月xx日 Vxxx版本新增功能。
有更好的方法歡迎交流學習,期待大神指教
mark
寫的真好,請問下寫了多久寫出來的
我最近也是在寫需求文檔。我發現一個問題就是在文檔中寫的內容與原型中一部分內容是重復的。所以如果我在文檔中寫需求描述時只寫頁面有什么功能,有什么用。在原型中則寫明開發時相關的注意事項你覺得如何????
個人感覺要是在一個成熟的團隊,成員相互都比較熟悉,是完全沒有問題的,在文檔中提示清楚就可以,
但是要是團隊不那么成熟的話,有時候咱們在寫文檔的時候多麻煩一點也是必要的,更多的避免后面可能發生的一些麻煩事項,萬一后面有一些事情發生的話,咱說起來也是有理有據的,個人見解,希望能有所幫助 ??
嗯,不無道理。畢竟我看很多人寫的需求文檔也是這樣的。我在想想。。。。對了我和開發的人去溝通溝通,看看他們的想法
你的原型圖確定是使用Axure畫出來的嗎?
我UI出身,文檔最重要的是意思表達明確,用什么工具應該沒有那么重要吧,個人習慣而已,主要咱們看表達意思準確與否 ??
樓主辛苦了啊,必須支持個
?? 感謝
不錯,挺詳細的,不過感覺卻少校驗(錯誤提示),全局說明
恩恩,prd我們這技術好像都不怎么喜歡看 ? ,就主要在axure里面了,以后做時會注意寫的更全面一些,感謝 ??
辛苦辛苦~~挺詳細的,不過做完一個項目后,正如你所說,我發現PRD寫得多詳細,技術的都不愛看,最喜歡是看原型圖+批注
你還算好的了,我們技術連文檔和原型都不怎么看,只是在需求評審會的時候聽一下,有問題提出來,大家討論達成一致后,就沒了。開發的時候完全憑著主觀理解或者以前的經驗認知來。
真是個好開發。
在用戶觀看的時候,進行關注.送禮.評論,分享的時候,是否在這些邏輯之前,應該進行一次是否登錄判定把.
流程是允許游客模式觀看的,所以只是在有關注.送禮.評論等具體操作時判定 ??