全栈工程师?
嗯.....目前并不是!

PRD:「FITLIFE」小程序產品需求文檔(用戶端)

筆者通過產品概況、產品結構、業務流程圖、全局說明、功能性需求、非功能性需求分析等模塊,系統輸出這一份關於“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

 

希望自己能堅持輸出內容,定期復盤,與優秀的你們碰撞更棒的想法,共同進步~

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《PRD:「FITLIFE」小程序產品需求文檔(用戶端)》
文章链接:https://www.pmbear.com/prd%ef%bc%9a%e3%80%8cfitlife%e3%80%8d%e5%b0%8f%e7%a8%8b%e5%ba%8f%e7%94%a2%e5%93%81%e9%9c%80%e6%b1%82%e6%96%87%e6%aa%94%ef%bc%88%e7%94%a8%e6%88%b6%e7%ab%af%ef%bc%89/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们