真實案例分享|登錄注冊產(chǎn)品需求文檔
由于比較忙,所以挑選一個常規(guī),且都遇到的產(chǎn)品功能進行撰寫,就不撰寫極細,通用溝通為準。若撰寫極細,每個功能的流程圖都得畫與都得寫。
具體的PRD格式與樣式,則根據(jù)團隊自身情況與業(yè)務(wù)進行設(shè)計。在敏捷性開發(fā),可以不寫PRD,但是產(chǎn)品功能涉及的流程圖盡量有,不然后續(xù)業(yè)務(wù)交接業(yè)務(wù)非常麻煩,耗資的成本非常高,并且繪制張流程圖也花費不了多長時間。高保真是很難將平臺數(shù)據(jù)與邏輯結(jié)構(gòu)表達出來。
關(guān)于登錄注冊,核心的有:
- 提高登錄注冊轉(zhuǎn)化率,降低跳出率,辛辛苦苦做活動拉人拉過來,沒登錄注冊就跑
- 防刷單防馬甲防詐騙,平臺業(yè)務(wù)量大起來,特別涉及金額交易的平臺,那更要注意了
- 登錄注冊流友好通暢,細致至每個提示,當用戶是傻瓜對待,而標準是,把每個使用場景與觸發(fā)事件想清楚,用戶進行每個場景操作,想都不用想就知道啥意思
- 申訴流程足夠通暢,不然密碼錯誤了,因流程流程復(fù)雜有問題,用戶就不陪你玩了(微信公眾號的密碼申訴流程就是很典型BUG,登錄時提示該賬號密碼不正確,找回密碼又提示該賬號不存在,注冊時又提示該賬號已占用,啥玩意呀?)
PS:我寫的這份PRD時較倉促,如有BUG,請自行修補,本篇章僅針對PRD。
對了,參與門檻越低,參與度越高,付出成本越高,離開率就越低
登陸注冊-產(chǎn)品需求文檔
一、產(chǎn)品概念
1.1業(yè)務(wù)背景概述
當前xxx提出需求,將登陸注冊功能優(yōu)化,提升用戶注冊體驗
1.2產(chǎn)品功能概述
注冊、登錄格式驗證規(guī)則與提示優(yōu)化,后期根據(jù)產(chǎn)品功能轉(zhuǎn)化率進行方案篩選
1.3產(chǎn)品前景
提升xxxx用戶登錄、注冊轉(zhuǎn)化率,降低跳出率(目的性要強)
1.4產(chǎn)品整體流程/邏輯關(guān)系
產(chǎn)品功能框架圖:
消費者個人登錄流:
消費者個人注冊流:
密碼申訴:
可自行補充,我就不畫了
馬甲判斷邏輯關(guān)系
可自行補充,我就不畫了
1.5面對用戶
xxxxx
來源:xxxxxx買家
權(quán)限定義:擁有xxxxxx用戶注冊、登錄權(quán)限。
1.6 應(yīng)用對象
網(wǎng)頁商城
1.7 名詞解釋
1.8 參考文檔(學習資料)
產(chǎn)品新人,如何將產(chǎn)品需求文檔撰寫更深入?
剛?cè)胄械漠a(chǎn)品新人,你其實可以寫一份合格產(chǎn)品需求文檔
2?功能需求
2.1 前臺應(yīng)用
2.1.1? 登錄
主要參與者
游客:已注冊未登錄用戶
用例圖
前置條件:用戶未登錄線上平臺
后置條件:完成“登錄”操作,則在會員管理生成一條登錄記錄,且跳轉(zhuǎn)至xxx頁。
詳細描述
表單字段:(表單具體的交互樣式與頁面布局,請看高保真原型)
驗證規(guī)則:進入下一次操作時,則對上一個操作進行格式驗證
操作說明:?表單交互樣式說明:(建議平臺有條件都設(shè)個用戶體驗中心,由UI設(shè)計師\交互設(shè)計師\文案組成,對平臺的細節(jié)進行優(yōu)化,PM能獨立出來,專心負責產(chǎn)品功能迭代管理與KPI轉(zhuǎn)化率)
默認樣式:灰色
錯誤樣式:
觸發(fā)條件:點擊登錄按鈕
交互樣式:表單紅色
規(guī)則描述:
- 身份驗證失敗,則根據(jù)錯誤類型進行錯錯誤提示:
- 若無輸入密碼、用戶昵稱或驗證碼其中一個,則將對應(yīng)的表單為紅色
- 若無輸入用戶、密碼,則所有表單為紅色
- 若賬號與密碼不匹配,則密碼表單為紅色
下彈驗證碼
觸發(fā)條件:身份驗證失敗次數(shù)>=3次
交互樣式:下彈淡入浮現(xiàn)
通知欄樣式:
觸發(fā)條件:格式驗證失敗
交互樣式:默認隱藏,格式驗證錯誤則浮現(xiàn)
- 點擊“忘記密碼”,則跳轉(zhuǎn)至密碼申述頁http://www.xxxxxx.html;
- 用戶“立即注冊”,則跳轉(zhuǎn)至注冊頁;(詳情請看2.1.2)
用戶點擊登錄按鈕或回車登錄時,系統(tǒng)判斷是否符合登錄條件:
- 是,則登錄成功,在xx管理模塊,生成一次登錄狀態(tài)
- 否,則根據(jù)不符合條件,進入錯誤提示與消息通知
消息通知欄說明:
根據(jù)消息類型進行消息通知:
默認提示:“公共場所不建議自動保存密碼 ,以免賬號財務(wù)丟失”
錯誤通知:
浮現(xiàn)條件:格式不符合
通知內(nèi)容:
- 若是xx模塊無該用戶注冊記錄,則通知:“無該用戶,請確定后登錄“
- 若是用戶名、密碼與驗證碼不匹配,則通知:“賬號密碼不匹配,請重新輸入”
- 若是本頁面無操作時間>=xmin,則通知:“登錄超過有效期,請重新登錄”
- 若是輸入用戶昵稱,無輸入密碼進行身份驗證,則通知消息:“請輸入密碼”
- 若是輸入密碼,無輸入密碼進行身份驗證,則通知消息:“請輸入用戶昵稱”
- 若是驗證碼輸入錯誤,則通知消息“當前驗證碼錯誤,請重新獲取輸入”
若是多條消息并行通知,則根據(jù)優(yōu)先級“驗證碼>用戶昵稱與密碼不匹配>無填用戶昵稱與密碼>僅填用戶昵稱>僅填密碼”進行消息通知,僅通知一條
2.1.2? 注冊
主要參與者
游客:未注冊用戶
用例圖
前置條件:用戶點擊“注冊”按鈕,進入本頁面
后置條件:完成“注冊”操作,則在xxx管理生成一條注冊記錄,且跳轉(zhuǎn)至xxxx頁。
詳細描述
字段表單:
格式驗證觸發(fā)條件:進入下一個判斷或操作,則對上一個操作進行驗證
特別說明:本菜單所有表單不允許錄入空格
操作說明:表單交互說明:
輸入提示交互:
觸發(fā)條件:點擊表單,
交互方式:向右浮現(xiàn)
錯誤提示交互:
觸發(fā)條件:格式驗證錯誤
交互方式:向右浮現(xiàn)
通過提示交互:
觸發(fā)條件:格式驗證通過
交互方式:向右浮現(xiàn)
提示規(guī)則說明
輸入提示:
觸發(fā)條件:點擊表單
根據(jù)表單類型進行提示:
1、若是用戶名,則提示:“4~20位字符,可由中文、英文、數(shù)字或符號“_”組成”
2、若是手機號碼,則提示:“請輸入正確的手機號,以便接收訂單,找回密碼”
3、若是驗證碼,則根據(jù)操作狀態(tài)進行提示
- 如是點擊表單,則提示:”請輸入圖中數(shù)字”
- 如是點擊“獲取驗證碼”按鈕,則提示:“如無法接收驗證碼,請重啟手機,并確認短信未被攔截!4G用戶,請關(guān)閉4G進行接收”
5、若是設(shè)置密碼,則提示:“6~20個大小寫英文字母、符號或數(shù)字組合”
6、若是確定密碼,則提示:“請再次確認密碼”
錯誤提示:
觸發(fā)條件:格式驗證錯誤
根據(jù)表單類型進行提示:
1、若是用戶名,則提示:“用戶名格式錯誤,請輸入正確的用戶名”
2、若是手機號碼,則提示:“格式錯誤,請輸入正確的手機號”
3、 若是驗證碼,則提示:“驗證碼錯誤,請重新輸入”
4、 若是密碼,則根據(jù)輸入狀態(tài)進行提示:
- 如是僅輸入符號,則提示:“密碼不能全為符號”
- 如是表單為空,則提示:“密碼不能為空”
- 如是輸入字符超過限制字符,則提示“密碼應(yīng)為6-20個字符”
- 如是僅輸入數(shù)字,則提示:“密碼不能全為數(shù)字”
5、若是確認密碼,則提示“兩次密碼輸入不一致,請確認再輸入”
通過提示:
觸發(fā)條件:格式驗證正確
提示消息:將輸入提示或錯誤提示切換成通過提示標記
用戶點擊“請登錄”按鈕,則返回登錄頁(詳情請看2.1.1)
用戶點擊“同意協(xié)議并確認”按鈕,則系統(tǒng)判斷資料是否符合提交提交:
- 是,則注冊成功,彈出提示層,提示:“ 注冊成功”,0.x后自動關(guān)閉,跳轉(zhuǎn)至xxx首頁;并在xx管理模塊,生成一條注冊流水記錄;
- 否,則根據(jù)錯誤狀態(tài),彈出提示層,進行提示:
- 如是提交資料不完善,則提示:“ 資料填寫不完善,請?zhí)顚懞笤偬峤蛔裕?/li>
- 如是驗證碼過期,即系統(tǒng)當前時間-最后一次驗證碼獲取時間>=30S,則提示:“驗證碼已過期,請重新獲取輸入”
- 如是驗證碼錯誤,則提示: “短信驗證碼錯誤,請重新獲取輸入”
- 如是連續(xù)多次錯誤,則根據(jù)優(yōu)先級:提交資料不完善>驗證碼錯誤>驗證碼過期,進行錯誤提示
用戶點擊獲取驗證碼,則xxx系統(tǒng)發(fā)送本次短信驗證。驗證碼自系統(tǒng)發(fā)送時間開始算起,有效期為xxmin;
2.1.3密碼申訴
可自行補充,我就不畫了
2.1.4馬甲用戶判斷規(guī)則
可自行補充,我就不畫了
2.2 其他功能
2.2.1同意協(xié)議彈出層
可自行補充,我就不畫了
3?其他接口要求
無
4?系統(tǒng)風險預(yù)估
無
5?其他需求
5.1.1 BI需求
登錄注冊轉(zhuǎn)化率統(tǒng)計
詳情說明:統(tǒng)計完成登錄與注冊操作的轉(zhuǎn)化率,對登錄、注冊按鈕錨點
計算公式:
登錄轉(zhuǎn)化率=完成登錄UV\登錄頁UV
注冊轉(zhuǎn)化率=完成注冊UV\注冊頁UV
登錄注冊頁跳出率分析
詳情說明:統(tǒng)計離開登錄\注冊訪問數(shù)退出轉(zhuǎn)化率,對
計算公式:
登錄跳出率=離開登錄的訪問次數(shù)\進入登錄頁的總訪問次數(shù)
登錄跳出率=離開注冊的訪問次數(shù)\進入注冊頁的總訪問次數(shù)
新注冊用戶統(tǒng)計
詳情說明:統(tǒng)計完成注冊的用戶數(shù)
…統(tǒng)計
可自行補充,我就不畫了
本文由 @倒爺001 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
畢竟是17年的文章了,所以水平確實還有待提升
雖然有點亂,但是還是有很多東西值得學習
有值得學習的地方,也覺得有可以改進的內(nèi)容,感覺你把交互文檔和PRD文檔都合在一起了。太綜合又不夠全面。
想請教樓主 那個向右浮現(xiàn)指的是怎樣的效果?
漏洞居多,不合格,例如用戶輸入驗證碼,把手機號刪除了,后續(xù)怎么操作?
??
看了 收藏了
你這個寫的叫用例圖,其實是叫原型圖;用例圖是UML語言中用來描述參與者與系統(tǒng)之間關(guān)系。而且用例規(guī)約也不是這個格式,要單獨成表才能讓開發(fā)看的明白。還有,消費者注冊成功了進入XX管理,為什么還要走到驗證身份?你這就死循環(huán)了???希望作者回答一下
?? ?? ??
寫的蠻好的,我就想問一個使用場景。開發(fā)和測試會在這一個字一個字看你的東西么?你這一個功能看下來,一周的活都不用做了,開發(fā)更愿意看原型圖+標注的方式
?? ??
題主,我想問一下,我看到“注冊失敗”“失敗提示”這兩塊屬于子流程。那么這兩塊細化的話也是流程圖么?如果是流程圖應(yīng)該是什么樣的呢
凡是功能都有流程,流程圖核心是表達功能之間的關(guān)系
若以靜止的角度看一個功能,也會有流程,但更多集中在“判斷條件”
很細判斷條件盡量不要過多的放進流程圖里,因為它不是功能,放多了流程圖會很復(fù)雜。
注冊失敗:
開始
進入注冊失敗判斷
是否符合判斷條件(該處可將判斷條件抽取出來在流程圖展示展示)
是,則注冊失敗
否,則結(jié)束
樓主 我想問下 我怎么覺得用例圖不是你那樣畫的啊 你畫得原型圖吧
?? ?? ?? ?? ??
能大概說說馬甲判斷規(guī)則大概有哪些?
涉及核心的技術(shù)問題,不回復(fù)。
注冊流程目前好像為了避免短信接口暴露,都做了2道驗證,淘寶是滑塊分頁面,京東是一個頁面做的圖片驗證碼(移動端是2個頁面,也是圖片驗證碼),我覺得樓主可以關(guān)注下,短信也是成本麻~~
1、本文章僅針對PRD,不針對過多細節(jié);(并且看文中內(nèi)容參與成本越低,參與度越低)
2、不需要短信驗證,無法確認該本手機賬號是否屬于本人,后期風控維護成本高;
3、一條短信獲取一個用戶的真實聯(lián)系信息,是非常劃算,特別是電商領(lǐng)域;
4、滑動驗證或者是圖片驗證碼,本質(zhì)是為了防刷,區(qū)別在于交互體驗與安全性
5、馬甲管理會根據(jù)用戶行為,進行詐騙風控
每增加一個操作,都做提高參與成本
回復(fù)內(nèi)容有誤,是:參與門檻越低,參與度越高
有點長過頭了?部分功能其實大家都懂,技術(shù)和開發(fā)可能都滾瓜爛熟,可以一筆帶過
1、公司大了后,每個功能對接不同的而研發(fā)人員,你不寫人家不知道;
2、業(yè)務(wù)交接人,沒那么多時間,看你的原型去分析你的格式驗證規(guī)則與邏輯推理
3、不論是京東、一號店、天貓、淘寶、支付寶…..的注冊格式驗證規(guī)則都不同,京東密碼表單格式驗證,僅輸入數(shù)字便可,而淘寶且不可以,每個細節(jié)都針對不同的業(yè)務(wù)與場景;
4、細節(jié)決定成敗,影響著用戶體驗與轉(zhuǎn)化率
登錄 登陸 犯了好幾個低級錯
登錄 登陸 犯了好幾個低級錯誤
PRD一定要命名為“產(chǎn)品需求文檔”,不要寫成“需求文檔”
倒爺微信:ftl_keen
小白請教一下注冊流程和登錄流程里為什么分藍白兩種框,白框兩側(cè)還有兩條豎杠?是主流程和輔流程的關(guān)系么?
核心的功能流程與觸發(fā)的功能流程