PRD文檔:logo生成小程序
編輯導讀:PRD作為產品經理經常撰寫的文檔,是產品的基本功。本文通過產品概述、業(yè)務流程、全局說明、功能性需求、非功能性需求五個模塊輸出一份“l(fā)ogo生成”需求文檔,希望對你有幫助。
本人也小白轉產品,在一家創(chuàng)業(yè)公司就職。由于沒有人帶只能自己根據產品經理的相關書籍和網絡文章自行摸索了兩個月。第一個月其實是比較痛苦的,完全不知道該做什么,只能不??磿唇坛?。
由于創(chuàng)業(yè)公司的緣故基本都是一人身兼多職,當時特別迷茫經常問自己現(xiàn)在做的這些事真的是產品職位該做的么?(痛苦不堪)中間也想過很多,但是還是想在產品職位發(fā)展下去,只能在下班的時候花更多的時間去學習如何做產品經理。
PRD作為產品經常撰寫的文檔,是產品的基本功。由于剛開始沒有模板沒有概念,只能通過網絡上相關的PRD去了解。經??吹胶芏嗳苏f“沒有完美的PRD,只有最適合團隊的PRD”。這話雖然沒錯,但是還是需要自己寫一份系統(tǒng)性的PRD才能讓自己有更深入的了解。轉行兩個月后決定參考@秋風的PRD文檔,寫一份自己公司產品的PRD。
產品果然光靠理論沒用,還是需要實戰(zhàn)才行。寫完后發(fā)現(xiàn)對PRD的概念逐漸清晰起來,本文的PRD還有很多問題。所有希望能和大家多多討論交流,一起進步!
一、概述
1. 產品介紹
2. 文檔修訂記錄
版本號規(guī)則:小數點后為當前版本的小更新,小數點前為大版本更新。
修訂屬性:新增、修改、刪除。
二、產品結構
1. 信息結構圖
2. 功能結構圖
三、全局說明
1. 名詞解釋
2. 權限彈窗
3. 輸入法說明
小程序中用戶點擊聊天框,底部彈出輸入法。
4. 時間規(guī)范
5. 異常情況
1)網絡異常
手機網絡連接異常,小程序彈窗提示如下:
2)用戶狀態(tài)說明
四、功能性需求說明
1. 需求清單
優(yōu)先級規(guī)范:p1、p2……數字越小代表優(yōu)先級越高。
2. 新用戶&首頁模塊
1)新用戶登錄流程
2)新用戶登錄原型圖
3)首頁
4)案例展示模塊
3. 客服模塊
4. 我的模塊
1)個人中心
2)我的訂單
3)建議反饋
5. logo生成模塊
1)生成&編輯流程
2)logo生成原型圖
3)logo編輯
4)logo下載/買斷流程
5)logo下載原型圖
6)定制頁原型圖
五、非功能性需求說明
1. 性能需求
2. 可用性需求
避免用戶高頻點擊無反饋。
3. 數據統(tǒng)計需求
六、思考總結
1. 內容細節(jié)
原型圖流程圖需要整齊統(tǒng)一,太多的內容建議展開分塊描述。
原型圖盡量按模塊展示,避免像蜘蛛網一樣加大閱讀障礙。
異常邏輯、底層邏輯描述還有toast彈窗還有很思考方面還有很大不足,還需在實戰(zhàn)操作中多觀察多思考。
本文由 @阿狗子 原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協(xié)議
請問可以分享一下元件庫嗎?很喜歡你的原型圖風格,很簡潔
學到了,最近正煩惱如何寫prd 呢
想問一下 使用什么標注的原型圖呀? 感覺很方便呢
Axure
寫得很棒,為你點贊
你的原型需求文檔的更新不能作為版本的更新,真實的版本是根據拆解需求和技術部門定義版本需求內容的,而并非修改文檔就要設定一個版本
大家公司的研發(fā)部,會認真看完嗎? 寫越詳細看的越少。當個證明可以。大家都是用什么方便提升溝通效率的。
我們公司是用墨刀做原型圖和簡單的交互跳轉給技術部門,然后和他們口訴需求邏輯的。我寫prd主要是問了產品迭代的時候歸檔。
就是留存一下記錄對吧。
每個公司都不一樣的,我們是這樣的
很棒。
很棒。
涉及到單位可以統(tǒng)一下,有RMB和¥
好的,謝謝提醒
你的標題寫錯了,寫成PDR了
呀!我都沒有注意到,感謝提醒
寫的很棒呢,受教了,之前一直不會寫PRD文檔
還有很多不足之處,一起加油前進把!