PRD:「FITLIFE」小程序产品需求文档(用户端)
這是我們私密學員寫的的一個文檔,拿出來和大家分享一下。
Hi~最近在對自己參與過的項目進行總結,希望可以和大家分享學習交流。輸出內容是檢視自己的方式,所以我就來吸取經驗了。
通過研讀各位優秀作者的精品,我學習到了不少知識。此次,以實際工作中遇到的情況作為案例,我將從0至1的產品中抽取重點模塊進行分享。
為了閱讀體驗,我將盡量簡化常規化的環節,本次采用AXURE梳理PRD——利用AXURE動態面板和內聯框架,制作文檔導航,提高瀏覽人員的閱讀效率。
一、概述
1. 產品介紹
2. 文檔修訂記錄
將重點模塊添加對應的跳轉鏈接,方便瀏覽人員迅速定位內容。
版本號規則:小數點后為當前版本的小更新,小數點前為大版本更新。
修訂屬性:新增、修改、刪除
二、產品結構
1. 信息結構圖
2. 功能結構圖
由于完整結構圖展開占很大的篇幅并且看不清楚,為了閱讀體驗,對結構圖部分收縮。完整版結構圖可在AXURE中查看。
三、業務流程圖
建議將流程圖統一整理至表格中,做成鏈接跳轉形式,實現快速查閱。為了順暢的需求閱讀體驗,將各自的流程圖放在之后的需求描述部分中展示。
四、全局說明
1. 名詞術語說明
2. 權限彈窗
3. 時間距離規范
3.1 時間規范
3.2 距離規范
4. 異常情況
4.1 網絡異常
手機網絡連接異常,小程序彈窗提示如下:
4.2 用戶狀態說明
五、功能性需求說明
良好的需求閱讀體驗需要保證閱讀過程是順暢的。
在這部分,首先列出【需求清單】,總覽這次需求涉及的模塊及簡要信息。緊接著,按照【需求模塊】-【流程圖】-【原型頁面流轉】-【原型需求拆解】的敘述邏輯去完成各個模塊的需求說明。
1. 需求池&需求清單
1.1 需求管理池
需求來源:產品、運營、BOSS等等
需求類型:新增需求、需求調整、功能優化、BUG修復、UI優化
系統:涉及到的系統及模塊
需求說明:簡述需求
優先級判斷:重要緊急、重要但不緊急、緊急但不重要、既不緊急也不重要(ps:我們要經常關注重要但不緊急的任務進度,避免重要緊急任務扎堆出現。)
1.2 需求清單
對需求管理池評估篩選后,將需求模塊、對應功能、需求優先級、完成情況統一整理到表格中。同樣的,這里將模塊名稱做成鏈接格式,快速查閱對應的需求模塊。
優先級規范:p1、p2……數字越小代表優先級越高。
2. 新用戶&首頁模塊
2.1 新用戶登錄流程圖
2.2?新用戶登錄原型(點擊查看大圖)
2.3 首頁
3. 預約團課模塊
3.1 團課預約流程圖
3.2?團課預約頁面流轉
3.2?課程列表頁
3.3?課程詳情頁
3.4?預約課程頁
4. 預約私教模塊
4.1 私教預約流程圖
4.2 私教預約頁面流轉
4.3 私教列表頁
4.4 私教詳情頁
4.5 私教預約頁
5 購卡模塊
5.1 購卡流程圖
5.2 購卡頁面流程
5.3 購買儲值卡頁面
6. 我的模塊(個人中心)
6.1 個人頁面
6.2 修改資料
6.3 我的卡包
6.4 我的課程包
6.5 我的優惠券
6.6 富文本頁面
六、非功能性需求
非功能性需求,是比較容易忽視的部分,往往和性能、安全掛鉤,影響著產品的穩定性與安全性。
以下僅僅是例子,具體方案需要根據業務情況和產品特性與相關人員深入溝通。
1. 性能需求
響應時間:系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms,這個200ms就是系統的響應時間。
并發用戶數:同時承載正常使用系統功能的用戶數量。
與性能相關的數據指標還有QPS(每秒響應請求數)、TPS(每秒處理的事務數)等。
性能需求這部分僅僅是舉個例子,具體情況和數據方案,需要和相關人員深入溝通。
2. 可用性需求
避免用戶高頻點擊無反饋的情況。
為用戶提供反饋渠道。
保持文案與組件的一致性。
3. 數據統計需求
產品初期需要一定基礎的數據提供支持,因此,除了小程序官方數據統計平臺,再接入第三方統計平臺,統計以下事件的數據及路徑轉化率。
七、思考總結
1. 內容細節
流程圖和頁面流轉圖要整齊統一,實在太多信息,建議用子流程模塊和多頁面分述解決。見過很多像“蜘蛛網”一樣的圖,閱讀體驗比較糟糕。
盡量讓用戶不用點開大圖就能看清內容,本篇部分頁面流轉圖和頁面需求也難免遇到這類問題。
異常邏輯和toast彈窗等細節需要加強把控,本篇這部分還是有所欠缺。
2. 高保真or低保真?
低保真線框圖:重點在于功能、結構、流程的梳理,利用簡單的框架和元素,省時省力;但細節相對高保真沒這么完善,可能會有一定的溝通成本。
高保真:針對于高層領導及投資人等,進行產品概念演示,視覺效果好,細節相對完善;相當于是一個產品的demo,但修改成本較高。
原型交互做的很酷炫,證明你對工具非常熟練。但如果為了做交互花費了大量的時間,就得考慮時間成本值不值得。如果能夠用簡單的注釋和跳轉,清晰表達交互邏輯,會不會省時省力一些?
具體情況具體分析,比如,你做了很多交互,開發做漏了會說:“沒寫清楚啊,我怎么知道哪里可以點擊呢?”
因此,我的習慣是做簡單的“交互邏輯+交互注釋”,盡量避免復雜且耗時耗力的交互。
當然,重要核心的交互邏輯,繪制出來比文字說明更容易理解。這時候,如果有現成的組件就套用,如果沒有,就采用“圖+文字+口述”的方式表達清楚。
3. WORD?AXURE?
需求文檔用什么工具寫比較好?
這是我見過比較多的產品話題討論之一——有用WORD的,有用AXURE的,還有用墨刀、石墨文檔等等……
我曾經請教過兩位分別使用WORD和AXURE撰寫需求文檔的朋友,他們是這樣的看法:
WORD選手:
用word寫,形式更規范。
結構大綱清晰,細節到位。
洋洋灑灑幾十頁,滿足感杠杠滴。
AXURE選手:
用AXURE寫,圖+標注+交互,更直觀地表達產品需求,閱讀更順暢。
預覽方便,支持上傳云端同步。
WORD寫了也沒人有耐心看,這個世界很浮躁啊。
我的看法:
需求文檔是幫助傳達及溝通需求的工具,講究的是“可讀性”。所以,在選擇采用什么方式之前,需要和團隊溝通達成共識,即什么樣的方式能給到他們更好的閱讀體驗。
我在實際工作中,采用的是AXURE,整理需求與線框圖后與團隊溝通,實現需求快速流轉更新。但我會選擇再用WORD梳理一遍,利用文字梳理大綱結構,整理產品邏輯和需求,能夠發現某些疏漏的環節,完善產品細節。因此,用WORD寫,是一個良好的查漏補缺的手段,是檢視自身邏輯的過程。
最后,由于篇幅關系,本次分享只展示了部分內容,完整預覽請在以下鏈接查閱。
預覽鏈接:https://r4zef5.axshare.com
PS:?轉發此篇文章到朋友圈或者是產品經理群,并截圖發給微信chanpin628,可以找我領取一份BRD。
此外我們的官方網站也上線了,每日分享高質量的文章、原型素材和行業報告,小伙伴可自行前往索取,支持搜索,需要的小伙伴可點擊底部的閱讀原文直接查看,或者復制網址:www.dadaghp.com?打開。
更多干貨可關注微信公眾號:產品劉
想學習更多關于產品、職場、心理、認知等干貨,可長按右邊二維碼,關注我們。
··················END··················
RECOMMEND
推薦閱讀
出現這些跡象,說明你面試可能沒戲了
面試離職原因,換個表述更有吸引力
線下實戰2.0
面試中如何解釋自己跳槽頻繁
面試題:“如果你被錄取了,將如何開展工作?”
點擊“閱讀原文”
查看更多干貨
總結
以上是生活随笔為你收集整理的PRD:「FITLIFE」小程序产品需求文档(用户端)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Qt中 QString 和int,dou
- 下一篇: 要专注于目标