亚洲最大看欧美片,亚洲图揄拍自拍另类图片,欧美精品v国产精品v呦,日本在线精品视频免费

  • 站長資訊網(wǎng)
    最全最豐富的資訊網(wǎng)站

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


    筆者通過產(chǎn)品概況、產(chǎn)品結(jié)構(gòu)、業(yè)務(wù)流程圖、全局說明、功能性需求、非功能性需求分析等模塊,系統(tǒng)輸出這一份關(guān)于“FITLIFE”小程序用戶端的產(chǎn)品需求文檔。

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

    Hi~最近在對自己參與過的項目進行總結(jié),希望可以和大家分享學(xué)習(xí)交流。輸出內(nèi)容是檢視自己的方式,所以我就來吸取經(jīng)驗了。

    通過研讀各位優(yōu)秀作者的精品,我學(xué)習(xí)到了不少知識。此次,以實際工作中遇到的情況作為案例,我將從0至1的產(chǎn)品中抽取重點模塊進行分享。

    為了閱讀體驗,我將盡量簡化常規(guī)化的環(huán)節(jié),本次采用AXURE梳理PRD——利用AXURE動態(tài)面板和內(nèi)聯(lián)框架,制作文檔導(dǎo)航,提高瀏覽人員的閱讀效率。

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

    一、概述

    1. 產(chǎn)品介紹

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

    2. 文檔修訂記錄

    將重點模塊添加對應(yīng)的跳轉(zhuǎn)鏈接,方便瀏覽人員迅速定位內(nèi)容。

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

    版本號規(guī)則:小數(shù)點后為當(dāng)前版本的小更新,小數(shù)點前為大版本更新。

    修訂屬性:新增、修改、刪除

    二、產(chǎn)品結(jié)構(gòu)

    1. 信息結(jié)構(gòu)圖

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

    2. 功能結(jié)構(gòu)圖

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

    由于完整結(jié)構(gòu)圖展開占很大的篇幅并且看不清楚,為了閱讀體驗,對結(jié)構(gòu)圖部分收縮。完整版結(jié)構(gòu)圖可在AXURE中查看。

    三、業(yè)務(wù)流程圖

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

    建議將流程圖統(tǒng)一整理至表格中,做成鏈接跳轉(zhuǎn)形式,實現(xiàn)快速查閱。為了順暢的需求閱讀體驗,將各自的流程圖放在之后的需求描述部分中展示。

    四、全局說明

    1. 名詞術(shù)語說明

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

    2. 權(quán)限彈窗

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

    3. 時間距離規(guī)范

    3.1 時間規(guī)范

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

    3.2 距離規(guī)范

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

    4. 異常情況

    4.1 網(wǎng)絡(luò)異常

    手機網(wǎng)絡(luò)連接異常,小程序彈窗提示如下:

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

    4.2 用戶狀態(tài)說明

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

    五、功能性需求說明

    良好的需求閱讀體驗需要保證閱讀過程是順暢的。

    在這部分,首先列出【需求清單】,總覽這次需求涉及的模塊及簡要信息。緊接著,按照【需求模塊】-【流程圖】-【原型頁面流轉(zhuǎn)】-【原型需求拆解】的敘述邏輯去完成各個模塊的需求說明。

    1. 需求池&需求清單

    1.1 需求管理池

    • 需求來源:產(chǎn)品、運營、BOSS等等
    • 需求類型:新增需求、需求調(diào)整、功能優(yōu)化、BUG修復(fù)、UI優(yōu)化
    • 系統(tǒng):涉及到的系統(tǒng)及模塊
    • 需求說明:簡述需求
    • 優(yōu)先級判斷:重要緊急、重要但不緊急、緊急但不重要、既不緊急也不重要(ps:我們要經(jīng)常關(guān)注重要但不緊急的任務(wù)進度,避免重要緊急任務(wù)扎堆出現(xiàn)。)

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

    1.2 需求清單

    對需求管理池評估篩選后,將需求模塊、對應(yīng)功能、需求優(yōu)先級、完成情況統(tǒng)一整理到表格中。同樣的,這里將模塊名稱做成鏈接格式,快速查閱對應(yīng)的需求模塊。

    優(yōu)先級規(guī)范:p1、p2……數(shù)字越小代表優(yōu)先級越高。

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

    2. 新用戶&首頁模塊

    2.1 新用戶登錄流程圖

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

    2.2?新用戶登錄原型(點擊查看大圖)

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

    2.3 首頁

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

    3. 預(yù)約團課模塊

    3.1 團課預(yù)約流程圖

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

    3.2?團課預(yù)約頁面流轉(zhuǎn)

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

    3.2?課程列表頁

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

    3.3?課程詳情頁

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

    3.4?預(yù)約課程頁

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

    4. 預(yù)約私教模塊

    4.1 私教預(yù)約流程圖

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

    4.2 私教預(yù)約頁面流轉(zhuǎn)

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

    4.3 私教列表頁

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

    4.4 私教詳情頁

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

    4.5 私教預(yù)約頁

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

    5 購卡模塊

    5.1 購卡流程圖

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

    5.2 購卡頁面流程

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

    5.3 購買儲值卡頁面

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

    6. 我的模塊(個人中心)

    6.1 個人頁面

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

    6.2 修改資料

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

    6.3 我的卡包

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

    6.4 我的課程包

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

    6.5 我的優(yōu)惠券

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

    6.6 富文本頁面

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

    六、非功能性需求

    非功能性需求,是比較容易忽視的部分,往往和性能、安全掛鉤,影響著產(chǎn)品的穩(wěn)定性與安全性。

    以下僅僅是例子,具體方案需要根據(jù)業(yè)務(wù)情況和產(chǎn)品特性與相關(guān)人員深入溝通。

    1. 性能需求

    • 響應(yīng)時間:系統(tǒng)對請求做出響應(yīng)的時間。例如系統(tǒng)處理一個HTTP請求需要200ms,這個200ms就是系統(tǒng)的響應(yīng)時間。
    • 并發(fā)用戶數(shù):同時承載正常使用系統(tǒng)功能的用戶數(shù)量。
    • 與性能相關(guān)的數(shù)據(jù)指標還有QPS(每秒響應(yīng)請求數(shù))、TPS(每秒處理的事務(wù)數(shù))等。

    性能需求這部分僅僅是舉個例子,具體情況和數(shù)據(jù)方案,需要和相關(guān)人員深入溝通。

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

    2. 可用性需求

    • 避免用戶高頻點擊無反饋的情況。
    • 為用戶提供反饋渠道。
    • 保持文案與組件的一致性。

    3. 數(shù)據(jù)統(tǒng)計需求

    產(chǎn)品初期需要一定基礎(chǔ)的數(shù)據(jù)提供支持,因此,除了小程序官方數(shù)據(jù)統(tǒng)計平臺,再接入第三方統(tǒng)計平臺,統(tǒng)計以下事件的數(shù)據(jù)及路徑轉(zhuǎn)化率。

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

    七、思考總結(jié)

    1. 內(nèi)容細節(jié)

    • 流程圖和頁面流轉(zhuǎn)圖要整齊統(tǒng)一,實在太多信息,建議用子流程模塊和多頁面分述解決。見過很多像“蜘蛛網(wǎng)”一樣的圖,閱讀體驗比較糟糕。
    • 盡量讓用戶不用點開大圖就能看清內(nèi)容,本篇部分頁面流轉(zhuǎn)圖和頁面需求也難免遇到這類問題。
    • 異常邏輯和toast彈窗等細節(jié)需要加強把控,本篇這部分還是有所欠缺。

    2. 高保真or低保真?

    • 低保真線框圖:重點在于功能、結(jié)構(gòu)、流程的梳理,利用簡單的框架和元素,省時省力;但細節(jié)相對高保真沒這么完善,可能會有一定的溝通成本。
    • 高保真:針對于高層領(lǐng)導(dǎo)及投資人等,進行產(chǎn)品概念演示,視覺效果好,細節(jié)相對完善;相當(dāng)于是一個產(chǎn)品的demo,但修改成本較高。

    原型交互做的很酷炫,證明你對工具非常熟練。但如果為了做交互花費了大量的時間,就得考慮時間成本值不值得。如果能夠用簡單的注釋和跳轉(zhuǎn),清晰表達交互邏輯,會不會省時省力一些?

    具體情況具體分析,比如,你做了很多交互,開發(fā)做漏了會說:“沒寫清楚啊,我怎么知道哪里可以點擊呢?”

    因此,我的習(xí)慣是做簡單的“交互邏輯+交互注釋”,盡量避免復(fù)雜且耗時耗力的交互。

    當(dāng)然,重要核心的交互邏輯,繪制出來比文字說明更容易理解。這時候,如果有現(xiàn)成的組件就套用,如果沒有,就采用“圖+文字+口述”的方式表達清楚。

    3. WORD?AXURE?

    需求文檔用什么工具寫比較好?

    這是我見過比較多的產(chǎn)品話題討論之一——有用WORD的,有用AXURE的,還有用墨刀、石墨文檔等等……

    我曾經(jīng)請教過兩位分別使用WORD和AXURE撰寫需求文檔的朋友,他們是這樣的看法:

    WORD選手:

    • 用word寫,形式更規(guī)范。
    • 結(jié)構(gòu)大綱清晰,細節(jié)到位。
    • 洋洋灑灑幾十頁,滿足感杠杠滴。

    AXURE選手:

    • 用AXURE寫,圖+標注+交互,更直觀地表達產(chǎn)品需求,閱讀更順暢。
    • 預(yù)覽方便,支持上傳云端同步。
    • WORD寫了也沒人有耐心看,這個世界很浮躁啊。

    我的看法:

    需求文檔是幫助傳達及溝通需求的工具,講究的是“可讀性”。所以,在選擇采用什么方式之前,需要和團隊溝通達成共識,即什么樣的方式能給到他們更好的閱讀體驗。

    我在實際工作中,采用的是AXURE,整理需求與線框圖后與團隊溝通,實現(xiàn)需求快速流轉(zhuǎn)更新。但我會選擇再用WORD梳理一遍,利用文字梳理大綱結(jié)構(gòu),整理產(chǎn)品邏輯和需求,能夠發(fā)現(xiàn)某些疏漏的環(huán)節(jié),完善產(chǎn)品細節(jié)。因此,用WORD寫,是一個良好的查漏補缺的手段,是檢視自身邏輯的過程。

    最后,由于篇幅關(guān)系,本次分享只展示了部分內(nèi)容,完整預(yù)覽請在以下鏈接查閱。

    預(yù)覽鏈接:https://r4zef5.axshare.com

     

    希望自己能堅持輸出內(nèi)容,定期復(fù)盤,與優(yōu)秀的你們碰撞更棒的想法,共同進步~

    贊(0)
    分享到: 更多 (0)
    網(wǎng)站地圖   滬ICP備18035694號-2    滬公網(wǎng)安備31011702889846號