登錄註冊的業務邏輯流程梳理

登錄註冊在不同的產品中有不同的體現，因爲對於它的很多功能細節使用的好壞也沒法一概而論，還是基於具體場景考慮。

這是早前實習期間做的一個登錄註冊流程的優化，主要是關於登錄註冊的業務流程圖（Transaction Flow Diagram）梳理，包括短信驗證碼登錄、賬號密碼登錄、第三方登錄、忘記密碼、圖形驗證碼等以及注意的一些情況。

業務流程圖中最主要的幾個問題就是：

誰（who），在什麼時候（when），在什麼條件下（condition），輸入什麼（input），輸出什麼（output），輸出流向（flow）……

業務流程圖表現形式我用的泳道圖，可以突出用戶操作、後端系統、前端頁面之間的邏輯關係，以及如何運作。

一、手機驗證碼登錄

注意事項：

11位手機號的顯示方式可以用「344」形式（如：000 0000 0000）；
手機、驗證碼的驗證先後順序（驗證碼是否超時、驗證碼是否正確、手機號是否註冊過等）；
錯誤反饋的方式（toast、HUD、alert文字、彈框）；
輸入錯誤後，是用戶點鍵盤上的刪除鍵一個一個刪除？還是在輸入框上提供一個一鍵刪除 icon？還是自動刪除？
對於手機號和驗證碼這種純數字的輸入，鍵盤彈出的類型預先設定，以及設定何時彈出；
是否需要自動驗證？（比如當輸入的手機號爲11位時，自動獲取短信驗證碼；當輸入的驗證碼爲4or6位時，自動驗證短信驗證碼，不需要用戶點擊 button）；
當驗證手機號爲未註冊過時，是否需要設置密碼？設置密碼是否可以跳過?若未設置，重新用驗證碼登錄時，是否還需要設置？

二、圖形驗證碼流程

注意事項：

應不同產品不同業務需求，爲防刷短信驗證碼，可在每次點擊獲取短信驗證碼前增設圖形驗證過程；
圖形驗證碼驗證存在形式，是在頁面內？還是彈框的形式？因爲要考慮到在多個場景下可複用的情況；
若爲彈框出現的形式，當圖形驗證碼輸入錯誤，用 toast 或者 HUD 的形式反饋錯誤會不會不合適？
用文字提示圖形驗證碼輸入錯誤後，是否可以自動清空圖形驗證碼？

三、賬號密碼登錄

注意事項：

默認登錄方式是手機號驗證碼登錄還是賬號密碼登錄？（看產品和場景：比如初次下載時，可以用驗證碼登錄，用戶主動登出後，下次登錄可用賬號密碼登錄）；
產品多長時間不使用，需要重新登錄呢？（重新登錄時，是否可以自動記住手機號），還是每次進入的時候都需要重新登錄？（比如我用的農行和中行移動app，在每次進入的時候都需要重新登錄，應該是爲了安全性考慮）；
手機號，密碼的驗證先後順序（手機號格式是否正確、手機號是否註冊過、手機號和密碼是否匹配等）；
關於輸入密碼的二次確認，在我實習的時候，我導師給我講過什麼時候用「再次輸入密碼」，什麼時候用「密碼可見開關」，以及密碼可見開關在什麼場景下默認可見，什麼場景下默認不可見。（因爲不想把這些限定成一個規則，大家可自行根據自己產品思考）；
若系統判斷手機號未註冊，是直接反饋用戶手機號未註冊？還是反饋手機號or密碼錯誤？還是引導用戶進入註冊流程或者驗證碼登錄流程？（當然還是依場景而異：部分產品如果直接反饋手機號未註冊，其實很容易泄露隱私，哪些手機號註冊過該產品就容易被他人知道）

四、第三方登錄

注意事項：

第三方登錄最常見的需要考慮的點就是是否還需要綁定手機號，是否可以跳過；
比如美團打車這種需要手機號驗證碼身份的，在用第三方登錄時候，就需要綁定手機號；一些產品想給用戶打造較輕體驗，也可以不需要綁定手機號。

五、忘記密碼流程

注意事項：

在輸入新密碼的時候需要考慮密碼的形式是否符合要求，以及怎麼明示用戶以及反饋給用戶；
新舊密碼是否能夠一樣？（比如 Adobe Creative Cloud 每次找回密碼時，新密碼和舊密碼不能一模一樣）；
在密碼找回後，進入哪一個流程？是直接進入首頁？還是進入賬號密碼登錄頁？是否需要自動輸入剛找回的賬號密碼？
有些產品可能會使用郵箱找回密碼，不過看場景，是不是所有人都會有郵箱，並且移動端是否能隨時收到郵件？

總結

回到最開始，登錄註冊裏的很多功能細節使用的好壞沒法一概而論，還是基於具體場景考慮。

在我之前兩份實習中，我的兩位導師都告訴過我，登錄註冊的邏輯是幾大複雜場景複雜邏輯之一（此外還有購物車的邏輯，退換貨的邏輯等等）。

以上是我對登錄註冊的業務邏輯和一些需要注意的 case 的總結，也算是理了下最近比較亂的思緒，希望有不同想法的大家多跟我交流。

印象很深的一句話是：做任何分析的時候，不要拘泥於表面，去思考背後的邏輯與深層原因，不需要得到一個準確的答案，思考的過程本就是一種收穫。