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