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

PAGEPAGE1Hi~最近在對(duì)自己參與過(guò)的項(xiàng)目進(jìn)行總結(jié)，希望可以和大家分享學(xué)習(xí)交流。輸出內(nèi)容是檢視自己的方式，所以我就來(lái)吸取經(jīng)驗(yàn)了。通過(guò)研讀各位優(yōu)秀作者的精品，我學(xué)習(xí)到了不少知識(shí)。此次，以實(shí)際工作中遇到的情況作為案例，我將從0至1的產(chǎn)品中抽取重點(diǎn)模塊進(jìn)行分享。為了閱讀體驗(yàn)，我將盡量簡(jiǎn)化常規(guī)化的環(huán)節(jié)，本次采用AXURE梳理PRD——利用AXURE動(dòng)態(tài)面板和內(nèi)聯(lián)框架，制作文檔導(dǎo)航，提高瀏覽人員的閱讀效率。一、概述1.產(chǎn)品介紹2.文檔修訂記錄將重點(diǎn)模塊添加對(duì)應(yīng)的跳轉(zhuǎn)鏈接，方便瀏覽人員迅速定位內(nèi)容。版本號(hào)規(guī)則：小數(shù)點(diǎn)后為當(dāng)前版本的小更新，小數(shù)點(diǎn)前為大版本更新。修訂屬性：新增、修改、刪除二、產(chǎn)品結(jié)構(gòu)1.信息結(jié)構(gòu)圖2.功能結(jié)構(gòu)圖由于完整結(jié)構(gòu)圖展開占很大的篇幅并且看不清楚，為了閱讀體驗(yàn)，對(duì)結(jié)構(gòu)圖部分收縮。完整版結(jié)構(gòu)圖可在AXURE中查看。三、業(yè)務(wù)流程圖建議將流程圖統(tǒng)一整理至表格中，做成鏈接跳轉(zhuǎn)形式，實(shí)現(xiàn)快速查閱。為了順暢的需求閱讀體驗(yàn)，將各自的流程圖放在之后的需求描述部分中展示。四、全局說(shuō)明1.名詞術(shù)語(yǔ)說(shuō)明2.權(quán)限彈窗3.時(shí)間距離規(guī)范3.1時(shí)間規(guī)范3.2距離規(guī)范4.異常情況4.1網(wǎng)絡(luò)異常手機(jī)網(wǎng)絡(luò)連接異常，小程序彈窗提示如下：4.2用戶狀態(tài)說(shuō)明五、功能性需求說(shuō)明良好的需求閱讀體驗(yàn)需要保證閱讀過(guò)程是順暢的。在這部分，首先列出【需求清單】，總覽這次需求涉及的模塊及簡(jiǎn)要信息。緊接著，按照【需求模塊】-【流程圖】-【原型頁(yè)面流轉(zhuǎn)】-【原型需求拆解】的敘述邏輯去完成各個(gè)模塊的需求說(shuō)明。1.需求池&需求清單1.1需求管理池需求來(lái)源：產(chǎn)品、運(yùn)營(yíng)、BOSS等等需求類型：新增需求、需求調(diào)整、功能優(yōu)化、BUG修復(fù)、UI優(yōu)化系統(tǒng)：涉及到的系統(tǒng)及模塊需求說(shuō)明：簡(jiǎn)述需求優(yōu)先級(jí)判斷：重要緊急、重要但不緊急、緊急但不重要、既不緊急也不重要（ps：我們要經(jīng)常關(guān)注重要但不緊急的任務(wù)進(jìn)度，避免重要緊急任務(wù)扎堆出現(xiàn)。）1.2需求清單對(duì)需求管理池評(píng)估篩選后，將需求模塊、對(duì)應(yīng)功能、需求優(yōu)先級(jí)、完成情況統(tǒng)一整理到表格中。同樣的，這里將模塊名稱做成鏈接格式，快速查閱對(duì)應(yīng)的需求模塊。優(yōu)先級(jí)規(guī)范：p1、p2……數(shù)字越小代表優(yōu)先級(jí)越高。2.新用戶&首頁(yè)模塊2.1新用戶登錄流程圖2.2

新用戶登錄原型（點(diǎn)擊查看大圖）2.3首頁(yè)3.預(yù)約團(tuán)課模塊3.1團(tuán)課預(yù)約流程圖3.2

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

課程列表頁(yè)3.3

課程詳情頁(yè)3.4

預(yù)約課程頁(yè)4.預(yù)約私教模塊4.1私教預(yù)約流程圖4.2私教預(yù)約頁(yè)面流轉(zhuǎn)4.3私教列表頁(yè)4.4私教詳情頁(yè)4.5私教預(yù)約頁(yè)5購(gòu)卡模塊5.1購(gòu)卡流程圖5.2購(gòu)卡頁(yè)面流程5.3購(gòu)買儲(chǔ)值卡頁(yè)面6.我的模塊（個(gè)人中心）6.1個(gè)人頁(yè)面6.2修改資料6.3我的卡包6.4我的課程包6.5我的優(yōu)惠券6.6富文本頁(yè)面六、非功能性需求非功能性需求，是比較容易忽視的部分，往往和性能、安全掛鉤，影響著產(chǎn)品的穩(wěn)定性與安全性。以下僅僅是例子，具體方案需要根據(jù)業(yè)務(wù)情況和產(chǎn)品特性與相關(guān)人員深入溝通。1.性能需求響應(yīng)時(shí)間：系統(tǒng)對(duì)請(qǐng)求做出響應(yīng)的時(shí)間。例如系統(tǒng)處理一個(gè)HTTP請(qǐng)求需要200ms，這個(gè)200ms就是系統(tǒng)的響應(yīng)時(shí)間。并發(fā)用戶數(shù)：同時(shí)承載正常使用系統(tǒng)功能的用戶數(shù)量。與性能相關(guān)的數(shù)據(jù)指標(biāo)還有QPS（每秒響應(yīng)請(qǐng)求數(shù)）、TPS（每秒處理的事務(wù)數(shù)）等。性能需求這部分僅僅是舉個(gè)例子，具體情況和數(shù)據(jù)方案，需要和相關(guān)人員深入溝通。2.可用性需求避免用戶高頻點(diǎn)擊無(wú)反饋的情況。為用戶提供反饋渠道。保持文案與組件的一致性。3.數(shù)據(jù)統(tǒng)計(jì)需求產(chǎn)品初期需要一定基礎(chǔ)的數(shù)據(jù)提供支持，因此，除了小程序官方數(shù)據(jù)統(tǒng)計(jì)平臺(tái)，再接入第三方統(tǒng)計(jì)平臺(tái)，統(tǒng)計(jì)以下事件的數(shù)據(jù)及路徑轉(zhuǎn)化率。七、思考總結(jié)1.內(nèi)容細(xì)節(jié)流程圖和頁(yè)面流轉(zhuǎn)圖要整齊統(tǒng)一，實(shí)在太多信息，建議用子流程模塊和多頁(yè)面分述解決。見過(guò)很多像“蜘蛛網(wǎng)”一樣的圖，閱讀體驗(yàn)比較糟糕。盡量讓用戶不用點(diǎn)開大圖就能看清內(nèi)容，本篇部分頁(yè)面流轉(zhuǎn)圖和頁(yè)面需求也難免遇到這類問(wèn)題。異常邏輯和toast彈窗等細(xì)節(jié)需要加強(qiáng)把控，本篇這部分還是有所欠缺。2.高保真or低保真？低保真線框圖：重點(diǎn)在于功能、結(jié)構(gòu)、流程的梳理，利用簡(jiǎn)單的框架和元素，省時(shí)省力；但細(xì)節(jié)相對(duì)高保真沒(méi)這么完善，可能會(huì)有一定的溝通成本。高保真：針對(duì)于高層領(lǐng)導(dǎo)及投資人等，進(jìn)行產(chǎn)品概念演示，視覺效果好，細(xì)節(jié)相對(duì)完善；相當(dāng)于是一個(gè)產(chǎn)品的demo，但修改成本較高。原型交互做的很酷炫，證明你對(duì)工具非常熟練。但如果為了做交互花費(fèi)了大量的時(shí)間，就得考慮時(shí)間成本值不值得。如果能夠用簡(jiǎn)單的注釋和跳轉(zhuǎn)，清晰表達(dá)交互邏輯，會(huì)不會(huì)省時(shí)省力一些？具體情況具體分析，比如，你做了很多交互，開發(fā)做漏了會(huì)說(shuō)：“沒(méi)寫清楚啊，我怎么知道哪里可以點(diǎn)擊呢？”因此，我的習(xí)慣是做簡(jiǎn)單的“交互邏輯+交互注釋”，盡量避免復(fù)雜且耗時(shí)耗力的交互。當(dāng)然，重要核心的交互邏輯，繪制出來(lái)比文字說(shuō)明更容易理解。這時(shí)候，如果有現(xiàn)成的組件就套用，如果沒(méi)有，就采用“圖+文字+口述”的方式表達(dá)清楚。3.WORD？AXURE？需求文檔用什么工具寫比較好？這是我見過(guò)比較多的產(chǎn)品話題討論之一——有用WORD的，有用AXURE的，還有用墨刀、石墨文檔等等……我曾經(jīng)請(qǐng)教過(guò)兩位分別使用WORD和AXURE撰寫需求文檔的朋友，他們是這樣的看法：WORD選手：用word寫，形式更規(guī)范。結(jié)構(gòu)大綱清晰，細(xì)節(jié)到位。洋洋灑灑幾十頁(yè)，滿足感杠杠滴。AXURE選手：用AXURE寫，圖+標(biāo)注+交互，更直觀地表達(dá)產(chǎn)品需求，閱讀更順暢。預(yù)覽方便，支持上傳云端同步。WORD寫了也沒(méi)人有耐心看，這個(gè)世界很浮躁啊。我的看法：需求文檔是幫助傳達(dá)及溝通需求的工具，講究的是“可讀性”。所以，在選擇采用什么方式之前，需要和團(tuán)隊(duì)溝通達(dá)成共識(shí)，即什么樣的方式能給到他們更好的閱讀體驗(yàn)。我在實(shí)際工作中，