本文筆者將對某款APP的注冊登錄流程的設計，結合當前業務需要和自己的思考，進行改版優化。

走查當前在負責的某款APP的注冊登錄流程，發現一些優化點。在調研市面主流APP的注冊登錄流程后，結合當前業務需要和自己的思考，設計了以下注冊登錄方案，附圖為改版方案。本文詳細介紹了此版方案相較原版的優點，希望能對新同學有所幫助，也希望大佬們多提改進意見。

P1：注冊登錄頁

注冊登錄后臺分流：手機號注冊登錄流程，將注冊和登錄的分流交由后臺判斷，無需用戶選擇，同時減少注冊用戶的一步操作。原版登錄流程第一步是輸入手機號和密碼登錄，注冊用戶需要點擊注冊按鈕才能進入注冊流程，這對注冊用戶并不友好?？紤]到無論注冊還是登錄，第一步都是輸入手機號，后臺拿到手機號即可判斷出該用戶是要注冊還是要登錄（判斷及后續流程見流程圖），因此將注冊登錄流程首頁改版為P1，節省了注冊用戶的一步操作，也使得系統更智能。

分步式注冊：考慮到各路徑步驟較少（驗證碼注冊登錄3步，無密碼用戶登錄3步，有密碼用戶密碼登錄2步，有密碼用戶驗證碼登錄3步，忘記密碼用戶登錄4步，第三方賬號登錄1步或3步，步為流程中的頁面數），以及分步式注冊的優點（減少用戶因畏難情緒而流失的概率、界面更聚焦更清爽、避免鍵盤遮擋文本框、無需用戶手動調起鍵盤），以及后臺分流注冊登錄流程的需要，故采用分步式注冊。

第三方登錄：若用戶上次是采用第三方登錄，頁面顯示“上次登錄”提示。

關閉按鈕：導航欄采用關閉按鈕而不是返回，代表這個界面跟上一個界面沒有層級關系。

P2：有密碼的用戶用密碼登錄

登錄方式推薦：業務方要控制驗證碼登錄的短信成本，故對于有密碼的用戶，優先顯示的是密碼登錄，雖然相較于驗證碼的復制粘貼輸入，密碼的輸入更繁瑣。如果無此項要求，可以優先顯示驗證碼登錄。

提前發送驗證碼：頁面點擊“切換至驗證碼登錄”和“忘記密碼”后，頁面跳轉同時，后臺發送驗證碼，減少用戶在驗證碼輸入頁面的等待時間。

文案：分段顯示用戶上個頁面輸入的手機賬號，作為線索，方便用戶檢查自己輸入的賬號是否正確。

明文密文切換按鈕：最初的設計稿是默認明文顯示密碼的，但被產品經理否決了，認為用戶可能接受不了，要避免這個風險。最終折中的方案是：明文顯示最新輸入的字符，提供密文/明文切換按鈕。此處我仍認為可以默認明文顯示，至少是值得一試的，是個提升用戶體驗的機會。因為我們的APP是一個學習APP，不涉及金錢等敏感信息，明文輸入方便用戶核驗和糾錯，效率上肯定是提升的，相信大家都有因為輸錯一位而清空密碼框重新輸入的經歷。這里的風險在于用戶在心理上能不能接受明文輸入，因此在交互評審時，我的建議是先上線試試，后面通過埋點數據查看用戶進入頁面后就切換密碼至密文的比例，再綜合用戶的反饋決定最終方案。但鑒于成本考慮，最終上線了折中方案。

自動調起鍵盤：進入頁面文本框自動獲取焦點，調起默認鍵盤。

密碼文本框：文本框輸入內容后顯示清空按鈕。密碼校驗未通過，用戶再次輸入時，不自動清空文本框。

登錄成功提示：登錄成功會有toast提示，文案“歡迎回來，[用戶名]”，更親切。

P2.1：有密碼的用戶忘記密碼

文案提示：進入頁面后，后臺檢測到短信已發，顯示文案。文案分段顯示用戶上個頁面輸入的手機賬號。

自動調起鍵盤：進入頁面文本框自動獲取焦點，調起默認數字鍵盤。

自動檢驗，自動跳轉：驗證碼支持復制粘貼，文本框檢測輸入六位后自動校驗驗證碼正確性，通過則自動跳轉至下一流程頁。

P2.2：有密碼的用戶重置密碼

明文本提示：密文規則提示不做暗文本提示，以免用戶輸入密碼后忘記規則。

密碼文本框：超出最大長度，前端限制輸入，報錯。

P3：注冊用戶&無密碼用戶登錄頁

注冊用戶和無密碼用戶(歷史版本原因，APP有一批無密碼用戶)登錄，承接頁。

此頁還解決了一個異常情況的問題。PM因為控制驗證碼登錄短信成本的壓力，所以堅持將設置密碼放在注冊登錄流程中；又因為想盡量減少注冊流程的流失率，后臺開發時將用戶驗證碼校驗通過作為了注冊成功的節點。這樣就帶來一個問題，當注冊用戶到達密碼設置頁，未設置密碼便連續點擊返回，直至P1時，當他以剛注冊的手機號走這個流程時，系統會將其認為已注冊用戶，但實際上他并沒有密碼。本頁面的存在避免了其到達密碼登錄頁的困惑，以及點擊驗證碼登錄那一步，體驗是比較好的。

注冊流程步驟：注冊登錄流程設計的一個重點就是注冊流程要盡量短，因為注冊流程對用戶沒有任何價值，用戶在這里的耐心是十分有限的，流失風險是很高的。注冊流程盡量短，非必要的內容都可以放在注冊后再補充，“先上了賊船再說”。方案中的注冊流程，用戶只需輸入手機號，再點擊粘貼驗證碼，即可完成注冊，是比較精簡的了。評審時PM要求加上設置密碼，共3步，也可以接受。

P3.1：無密碼的用戶設置密碼

前文提到業務方要控制驗證碼登錄的短信成本，因此在改版后的流程中加入了設置密碼一步。評審時有討論過將設置密碼放在用戶登錄成功后，在“我的”標簽上給予氣泡提示，在“我的”頁內給予紅點提示，以此引導用戶去設置密碼。但最終未能說服PM，因為后臺可以實現讓用戶在驗證碼校驗通過之后就算是“上了賊船”，同時因為控制驗證碼登錄短信成本的壓力，PM堅持要把設置密碼步驟放在進入APP之前，以保證密碼設置率。

明文密文切換代替確認密碼：提供明文密文切換按鈕，以供用戶確認密碼。刪除確認密碼這一步，減少用戶操作。風險在于用戶很可能不會主動點擊查看明文密碼來確認，因此設置的密碼可能跟預想的不一樣，導致后續登錄失敗。

綜合考慮，對于“設對”密碼的用戶，流程少了一步，體驗提升了；對于“設錯”密碼的用戶，只要不退出登錄不卸載APP，就不會遇到這個問題，因此體驗也是提升了；對于“設錯”密碼的確實遇到這個問題的用戶，還有忘記密碼流程兜底，體驗下降了一些。

所以，總體考慮，改版方案還是利大于弊的，因此最終說服PM，刪除了確認密碼這一步。

P4：第三方登錄綁定手機號

為什么非要用戶綁定手機號？

• 原因一：《中華人民共和國網絡安全法》規定用戶上網必須要提供真實身份信息，因為手機號都是實名注冊的，所以可以滿足法律規定。當然也可以讓用戶輸入身份證信息，但這顯然不如手機號。
• 原因二：手機號是重要的用戶信息，可以通過手機號發送驗證碼、運營消息等，也可以通過手機號得知用戶手機通訊錄、歸屬地等其他信息。
• 原因三：手機號是我們APP用戶賬號的主要形式，方便用戶管理。因此讓用戶綁定手機號一舉三得。

文案提示：第三方登錄后還要綁定手機號，這是一個很不友好的設計。因為用戶點擊第三方登錄的動機就是免去輸手機號密碼驗證碼等等步驟，然而在第三方授權后不僅沒省事回頭想想還更麻煩了。

為了安撫用戶情緒，文案搬出了《中華人民共和國網絡安全法》——畢竟這是國家法律明文規定的嘛，我們也沒得辦法/委屈臉，希望用戶能理解。

一步式注冊：鑒于前面提到的原因，用戶到達這個頁面都是比較煩躁的，因此這個頁面不宜再分步，再分步會讓用戶抓狂。

獲取驗證碼按鈕：按鈕文案：從用戶角度出發，應該是“獲取驗證碼”，而不是“發送驗證碼”。

按鈕位置：用戶操作的流程，應該是先輸入手機號，再點擊按鈕，再輸入驗證碼；用戶視覺流與操作流程一致，因此，按鈕位置放在了手機號文本框之后，而不是驗證碼文本框之后。

此版設計的缺點：

1. 鑒于APP還在發展早期，用戶量較小，注冊登錄流程未考慮手機號二次放號的問題。
2. 限于團隊規模和財力預算，在方案上線后沒有數據驗證設計時的一些想法。對于懸而未決的爭論，最終也不了了之。比較遺憾。

參考文章：

產品設計-登錄注冊(一)

產品設計-登錄注冊(二)

登錄注冊設計前的思考

登錄注冊深思

手機QQ里的注冊那些事兒

完美“登錄”，從去掉“注冊”開始

產品設計經驗分享：6個輸入框 ，47個設計點

關于APP注冊設計的兩三事

你有沒有想過為何要隱藏密碼或顯示密碼？

關于第三方登錄的趣分析

3種不友好的注冊登錄設計

有了手機號快捷登錄，還需要密碼登錄嗎？

賬號體系設計：如何解決手機號二次使用導致的賬號問題

本文由 @Tzufeng 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議