註冊登錄是大多數App的基礎功能，本文將從註冊登錄體系開始，解析設計這一體系的步驟與要點。
萬事開頭難。
對於一個互聯網產品來說，賬號體系的設計是一切的根基。
賬號是產品與用戶之間的綁定關係，是用戶在產品中的唯一性憑證。我們在企業工作中很少有機會參與一個產品從零到一的設計，很少能參與產品體系的搭建，這一模塊反而成為最熟悉的陌生人。
今天帶著大家一起探討『如何設計一套賬號註冊登錄體系』，開啟一個產品的『從零到一』。
當我們接到一個需求的時候，第一個肯定要問一個為什麼？這東西為誰存在？解決了什麼問題？採取了什麼方式？
這三問堪稱產品經理接需求時的『產品三連』，只有搞清楚這三個問題，需求才會清晰和有意義。
一、需求分析
痛點：用戶在產品中如果沒有賬號，無法確認用戶與產品的唯一聯繫，賬號是用戶的標識，用以確認身份，在產品中進行數據分發、權限分發等。
賬號就像是產品體系下的身份證。
比如對於微信來說，每個賬號的消息、朋友圈、通訊錄、各種服務都不相同，賬號將這些區分隔離並加以保護。只有確認了賬號，確認了身份，才會讓用戶進入產品中使用。
那麼是不是所有產品都需要賬號體系？
答案肯定是否定的。
『如無必要，勿增實體』，如果用戶與產品之間不需要建立綁定聯繫，不需要根據賬號信息進行數據分發，那麼可以沒有賬號。比如一些工具型的產品：一些小型游戲、秒錶、計算器等。
二、業務分析
What：一個完整的賬號體系業務主要包括五個模塊：
無論是註冊、登錄還是找回密碼，目的都是引導用戶使用產品，而風險控制則是為了保護用戶賬號的安全。
賬號體系涉及的五個模塊，軟件製作：MindNode
1. 賬號註冊主流程
在判斷賬號是否註冊時，為了防止惡意攻擊，通過手動或自動化程序測試賬號是否註冊，這裡應該做風險控制，如連續3次賬號未註冊，後續每次輸入賬號都需要驗證（如輸入驗證碼，滑動驗證等）才會繼續流程。
賬號註冊流程圖
2. 賬號登錄主流程
賬號可能是手機號、郵箱號或其他，大部分App均支持手機號驗證碼登錄，這裡也分析此流程。
第三方賬號登錄一般情況下有兩種情況：
①主流社交賬號如微信、QQ、微博、Facebook等的登錄，對於已綁定的賬號，直接喚起相應App進行授權登錄，對於未綁定的賬戶，則還需要進行綁定；
②同一公司體系下產品的賬號，如騰訊系的騰訊視頻、王者榮耀等，無需註冊，使用一套賬號（微信、QQ）授權登錄。
賬號登錄流程圖
3. 找回密碼流程
找回密碼流程圖
三、結構設計
結構設計，就是從信息架構和功能架構兩個角度對產品的描述。
對於一個賬號體系，從用戶角度看，主要功能包括註冊、登錄、找回密碼等。
賬號註冊登錄的信息架構圖
四、原型設計
1. 登錄主流程設計
首先要明確登錄界面要解決什麼問題？這個界面的用戶大概可以分為以下3類：
- 已註冊的用戶且記得密碼
- 已註冊的用戶且不記得密碼
- 未註冊的新用戶
所以登錄主界麵包含幾個功能，應該包括：
- 賬號密碼登錄
- 找回密碼
- 註冊
登錄這裡我們還增加了手機號驗證登錄和第三方賬號登錄。
無論是註冊還是找回密碼還是登錄，最終目的都是為了用戶能更流暢地登錄。
賬號登錄頁面流程圖
異常情況
這裡的異常情況主要包括：
- 賬號格式錯誤
- 賬號密碼錯誤
- 網絡異常等
我們需要對異常情況加以區分並給出清晰的提示。
提示的文案規範有一個格式：錯誤原因+引導用戶操作。
如『網絡異常』+『稍後重試』。
登錄是一個對安全性要求很高的功能，所以這裡必要地加入風險控制，如輸錯密碼時候的懲罰機制，這個大家在類似於手機解鎖時也會遇到，至於懲罰機制，具體怎麼限制就看各個產品對於安全程度的要求。
我們分析一下，什麼情況下用戶會頻繁輸錯密碼。
是不是有兩種主要的情況，一是用戶對密碼記不太清楚了，在這裡抱著試一試的心態在登錄。那麼這裡可以加一個引導，在連續輸入錯誤密碼3次的時候，可以提醒用戶是否找回密碼，提高用戶體驗，加速登錄流程。
還有一種情況是賬號不是該用戶的，用戶在暴力破解密碼。這時候就必要地加入懲罰機制以保障用戶的賬號安全。
這裡有一個思考點，那就是這個懲罰機制是以什麼維度去統計密碼錯誤次數的呢？
個人認為最好是以賬號+終端統計而不要單純以賬號統計。
試想一下這樣的場景，在設備1上暴力破解A賬號，這時候觸發懲罰機制，需要1小時後才能登錄，這種情況下如果以賬號為統計維度，會導致A賬號的擁有者在設備2上登錄受限，所以採取賬號+終端的方式會比較好。
2. 手機號驗證登錄
手機驗證登錄頁面流程圖
手機號驗證碼的流程就是輸入賬號綁定的手機號，獲取驗證碼，輸入驗證碼。
流程是比較簡單，也是目前各種App普遍採用的登錄方式，因為手機號的唯一性以及安全性，再加上沒有密碼記憶的成本，這種登錄流程簡單便捷，現在越來越受推崇。
那麼這種流程需要註意什麼細節呢？因為魔鬼往往都在細節里。
首先是手機號本身，大家日常遇到的手機號大部分都是中國大陸的手機號，以86為國家碼的11為連續數字，但是大家要清楚的是，這隻是全球手機號中的一種，刨去不支持非大陸手機號登錄的情況。應該要註意的有以下2點：
- 國家和地區碼可以默認跟隨手機系統，但需要支持修改，防止手機收不到驗證碼，同時需要給出收不到驗證碼的操作指引。
- 風險控制，由於短信服務是一個需要付費的服務，為了防止暴力地刷這個獲取驗證碼接口，大部分App都會加一個獲取驗證碼的時間間隔（一般是60秒）。同時，當多次點擊的時候需要驗證。如圖片驗證碼，滑動驗證等。同時驗證碼錯誤也會有相應的懲罰機制防止暴力破解。
3. 註冊流程設計
註冊主流程就是輸入賬號>獲取驗證碼>設置密碼>完成登錄，這裡賬號不一定是手機號，也有部分使用郵箱（特別是國外的互聯網產品）。
賬號註冊頁面流程圖
驗證部分的風險控制跟上面相似這裡就不贅述了。那麼大家想一下，設置密碼這裡有什麼需要註意的？
日常的設置密碼主要有兩種形式：
一種是明文/隱藏顯示，多見於移動端的註冊流程，還有一種是重覆輸入密碼確認，多見於網站或者PC端產品。
那麼為什麼有這兩種方式呢？
大家有沒有這種抓狂的瞬間？重覆輸入密碼然後系統提示前後兩次不一樣！還有設置了密碼然後登錄的時候提示密碼錯誤！
密碼是人設置的，人為的操作具有不可控性，有很大的概率輸入密碼的過程中會出錯。更何況有些密碼要求極其變態，就算設置符合規則了也不一定記得住。
由於電腦鍵盤比較大，輸入錯誤的概率相對較小，所以可以採取重覆輸入確認的形式，而手機鍵盤就小了很多，而且還需要進行字母大小寫、特殊符號、數字等的切換，輸入錯誤的概率大大增加，所以明文顯示的方案會讓流程更流程。
當然，默認密碼絕對是要隱藏的，為了保證安全。
找回密碼的流程跟註冊大致相同。但這裡有一個比較棘手的情況，那就是用戶的手機號換了該怎麼辦。這個我們下期再講。
五、數據設計
原型設計其實已經是對一個需求的分析、梳理到解決方案的設計的最後環節了。
對一個問題的解決方式永遠都不會只有一個，但最優的情況一般只有一個，為了找到這個最優情況，我們必須對我們給出的方式做出驗證。
用什麼驗證呢？
用數據說話。
對界面中用戶可能觸發的事件進行埋點統計，可以幫助我們驗證猜想，修正我們的設計，在後續的迭代中不斷優化功能，提升體驗。
比如本例子中，我們把賬號密碼登錄放在主頁面而手機號驗證登錄則是一個二級頁面，如果埋點數據顯示手機號驗證登錄的數據很高，我們是不是就可以轉換策略把它放在主界面呢？
其實沒有這麼簡單，數據還需要慢慢研究，發現背後的業務邏輯、用戶操作的場景以及當時的想法，這個我們後續會娓娓道來。
作者：PM大叔；公眾號：互聯網產品研究院（ID:Deep_Boom)
本文由 @互聯網產品研究院 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議