注冊登錄業務的宏觀理解
一、注冊登錄流程的需求痛點是？
注冊登錄流程的需求背景各有不同，需求痛點是統一的，即個人與該個體為度的數據無法達成關聯。
注冊登錄環節，是服務方為單個用戶建立身份標識的過程，是服務與享受該服務的用戶在數據層面建立雙向聯系的過程。
注冊登錄環節并不是標配。如果服務與享受該服務的用戶在數據層面無需建立雙向聯系（主要為純工具類應用），則無需額外設置該環節
二、注冊登錄流程具體包括什么內容？
注冊登錄流程是一個流程集，包括正向和逆向流程；
注冊登錄環節主要包括正向流程：注冊流程、登錄流程；逆向流程：找回密碼流程，風控流程。
三、注冊登錄環節的影響？
正向：可以建立服務于用戶之間的雙向聯系，快速進行推廣，進行個人化營銷，有利于用戶的信息安全等等。
反向：有流程就會有損耗，注冊登錄流程對用戶來說，是使用網站服務的額外流程。在現在流量越來越貴的情況下，流程的損耗是必須考慮的要點；流程考慮不到位可能導致的問題是需要付出巨大的額外成本進行流程補全。（假如應用要全量用戶添加昵稱及頭像，如果忘記在注冊登錄環節增加昵稱及頭像補充環節，后續要在其他環節補全需要付出極大的額外成本）
總結：
注冊登錄環節，是服務方為單個用戶建立身份標識的過程。
注冊登錄流程是一個流程集，包括正向和逆向流程。
注冊登錄流程作為用戶行為的關鍵節點，十分重要。
注冊登錄業務中驗證機制的演變
前的注冊登錄流程發展也是由身份標識的識別符號變化，也就是我們常說的驗證方式決定的。要作為驗證方式需要兩種特性：
- 在服務對象中覆蓋率高；
- 與真人的關聯度高。
一、密碼
包括的注冊登錄方式：賬號密碼登錄；
密碼其實就是一串理論上只有身份標識所有者記得的字符串，
使用密碼的好處：目前識別字符串的功能所有的設備均可以支持，同時用戶也已經被教育成熟，使用密碼進行校驗。
目前問題：字符串的標識性不夠強，很多人設置的簡單密碼都相同；其次，字符串的安全性不夠高，相對于現在的黑客技術來說，簡單密碼被破解成本極低；字符串只有通過不斷提高復雜程度，才能確保其與真人的關聯度及安全性。意味著用戶的記憶成本會不停提高。安全性和與真人的關聯度都不夠強，以及為解決這個問題導致的用戶記憶成本提高，這個平衡點的難以把握注定這是一種將隨著技術進步被拋棄的驗證方式。
個體識別度：低
便捷程度：低
技術要求：低
風險程度：高
二、基礎通訊方式
包括的注冊登錄方式：手機注冊登錄；郵箱注冊登錄
基礎通信方式具有網絡效應及替代成本高的特點，同時符合作為驗證方式的特性，這也是隨著通信技術的發展及普及帶來的驗證方式升級。
好處：注冊登錄的便捷性，無需記住密碼的特點，采用基礎通信方式進行身份驗證是最為普遍的
問題：由于運營商手中通信資源的稀缺性，會存在重復放號的可能，這對于依賴手機號碼驗證方式是個巨大挑戰，因此經常需要進行補充流程的校驗。這無形中也提高了用戶的使用成本。
個體識別度：中
便捷程度：中
技術要求：中
風險程度：中
三、證件信息
包括的注冊登錄方式：實名注冊登錄；護照注冊登錄；學生證驗證等
限制使用場景：
一是敏感性，作為個人身份標識，在網絡安全還比較初級的今天用戶一般不愿透露；
二是復雜性，由于國家需要區分的用戶數量之大，導致區分方式會非常復雜，用戶記憶的成本很高。另由于個人信息安全目前極易泄露，導致目前用戶需要以證件號碼及特殊姿勢手持證件照相的形式進行驗證，導致便捷程度極低
個體識別度：高
便捷程度：低
技術要求：中
風險程度：中
總結：
在服務對象中覆蓋率高、識別度高的方案，都可以作為驗證方式。
注冊登錄流程的演變是人性中懶惰的體現。
注冊登錄流程的演變與技術發展息息相關。
注冊登錄業務的產品流程設計
按驗證動作分：
賬號密碼：
賬號密碼登錄：賬號 密碼
全球手機登錄：手機號 密碼
三方授權登錄：三方賬號 密碼
三方靜默登錄：三方賬號 密碼
手機驗證：
免密登錄：手機號 短信驗證碼
按驗證時間分：
進入應用前
后置流程中
一、賬號密碼
1）自由賬號體系流程
優點：
- 注冊登錄環節的數據均在自己手中，可以獲得更多維度的用戶數據；
- 賬號體系外部依賴少，安全性較強。
缺點：
- 風控流程較多（驗證碼等），需要用戶操作的節點多；
- 需要自己設計風控流程及對抗性高的組件（圖形驗證碼等），成本較大。
2）三方賬號體系流程
優點：
- 流程短，登錄速度快，注冊轉化率高，背靠三方豐富的用戶信息，有利于網站快速推廣；
- 能快速建立簡單的賬號體系，使用個體維度的信息；
- 與三方互相背書，可以增加在用戶心中的可信度；
缺點：
- 對外部依賴性較強。
特別需要注意的點：
三方登錄的流程最好不要再加額外流程，無論是填寫手機還是增加個人信息補充都會極大降低注冊轉化率，在用戶感知中甚至會比只有賬號流程還復雜，導致三方登錄主要的優點蕩然無存~
具體而言：
- 賬號密碼登錄：普通的賬號密碼登錄，不做贅述。
- 全球手機登錄：手機號 密碼，主要用于有國外用戶注冊登錄需要的賬號體系。
- 三方授權登錄：三方賬號 密碼，需要用戶進行一次授權后使用三方賬號快速注冊登錄。
- 三方靜默登錄：在已登錄三方賬號的情況下靜默使用三方賬號注冊及登錄。
二、手機驗證
優點：
- 登錄便捷，轉化率高。
缺點：
- 運營商二次放號問題是個坑，需要有流程進行判斷；
- 短信費用的預算問題需要考慮；
- 需要準備至少兩個短信通道，以防出現短信通道堵塞或熔斷等導致用戶無法順利注冊的情況。
三、驗證時間
按登錄注冊頁面出現的時間點劃分，一般分為兩種：進入應用前及后置節點中。各有利弊。
1.進入應用前
優點：注冊入口少，維護成本低；用戶信息全面，需要信息可一次收集完畢
缺點：用戶體驗差，在用戶沒有體驗服務的情況下需要注冊，容易造成用戶流失
2. 后置流程
優點：用戶體驗佳，對用戶來說流失成本較高
缺點：入口多，維護成本較大；需要進行全盤規劃才能做好；用戶信息需要分多環節收集
最適合的方式？
注冊登錄流程的選擇，是流量需求與風控需求的博弈。注冊登錄環節作為流量漏斗的重要一環，對注冊成功率，各種轉化率的直接影響非常大，因此流量的主要主張為，盡可能縮短流程，降低流程損耗；減少用戶不必要的操作，確保流程流暢；登錄注冊流程盡可能后置，增加客戶留存；而同時注冊登錄流程作為站內用戶的入口環節，對風控來說勢必是不可放松的閘口。其主要主張為，風控組件盡可能多，登錄注冊流程盡可能前置，以及盡可能延長流程，使用戶在該環節留下更多數據供其進行判斷。
利害相關方的肯定都會舉出非常有力的證據來說明利弊，但作為用戶產品，在選擇注冊登錄流程時，更重要的是看具體的行業需要，公司發展階段，及具體渠道需要而定，不能因為業務方的影響而隨意調整流程
一、行業
不同的行業，面臨的流量與風控的要求不同。如上圖所示，不同的行業由于業務場景的不同需要選擇不同的注冊登錄流程。越接近流量導向，則注冊登錄流程越短（甚至無需注冊登錄亦能享受服務），注冊登錄流程后置可能性加大；越靠近風控導向，則注冊登錄流程越長，注冊登錄流程后置可能性變小。當公司產生發展方向調整的時候，注冊登錄流程也需要進行相應調整。
二、公司發展階段
不同的公司發展階段，也是一樣的道理。發展初期，由于面臨巨大的流量壓力，對更偏向于選擇短平快的，快速搭建賬號體系的方式；發展后期，不管是出于業務拓展，為轉型準備、精確營銷及增加手中數據價值等等的考慮，往往會考慮自建賬號體系，使用自己的注冊登錄流程。
三、具體渠道業務定位
以電商行業舉例，APP，PC及H5，外投渠道，這些渠道承載的使命是不同的，因此如果有必要，也應該根據他們的定位進行符合要求的注冊登錄流程設計，最大化的發揮渠道效果。APP及PC，由于相對來說面向用戶主要以成熟用戶，老用戶為主，功能更加全面，也有包括資產管理等安全要求較高的模塊，因此對這些渠道來說，是需要走相對長的注冊及登錄流程的；至于H5及外投渠道，由于更輕量化，更側重于引導快速交易，因此更傾向于流程后置，縮短流程，減少用戶損耗。
因此需要看下，自己的行業是偏流量導向還是風控導向，公司發展階段如何，具體渠道的業務形式，才可以從上面不同的賬號注冊登錄形式中，選出最適合自己的方式，再進行逆向流程的補充，UI交互的打磨，形成最適合自己的注冊登錄流程。
需要說明的一點是，注冊登錄流程不是一成不變的，在發展的不同階段，有可能會適當的進行調整。甚至于，在同一階段，針對不同渠道的需求，也需要靈活處理。
注冊登錄業務的基本要求
1、穩定性
穩定性作為用戶業務的核心，是需要重點保證的。電商中，雙十一、雙十二，日常大促等均會出現高峰值用戶注冊登錄請求，一旦注冊登錄業務跪了，后面做的再好也是白搭。
主要從以下幾方面提高穩定性水平：提高架構合理性；日常進行穩定性檢查；大促前壓測；穩定性預案到位等等。
2、通用性
通用性并不是每個APP都需要做的，只是我們公司旗下APP有點多（類似盛大，數量多得我考慮過通行證的架構），所以作為負責整條用戶業務線的產品，需要在通用性上下功夫，做好整體規劃。這樣可以減少代碼開發及維護成本的同時，提高流程的可復用性。
主要從以下幾方面提高通用性水平：解耦風控業務（歷史包袱丟開~）；組件化開發，流程可選配。
3、支撐性
支撐性是指如何更好的支撐其他業務方工作開展。前期發展速度較快，接入流程不太規范，容易增加后續額外開發成本。因此提高支撐性的首要任務是增加開發及業務接入規范，包括工程及數據層面的規范，從而更快、更好的實現對業務方的支撐。
登錄注冊產品需求自檢清單
.PC端：
1.1 PC具有公共屬性，輸入密碼是私密性的，需要在登錄注冊時給予適當保護；
1.2 PC端臺式機一般固定在特定的位置，無法隨意移動，筆記本可以移動但使用場景相對固定，網絡狀況與移動設備相比穩定；
1.3 PC顯示區域比較大，登錄注冊通常只有1個頁面，需要填寫的所有內容都會呈現。
1.4 PC端的輸入設備有鼠標和鍵盤，人機交互和可輸入速度要快很多；
2.移動端：
2.1 移動設備屬于個人私密性較高的設備，用戶在進行操作時，可對輸入密碼進行有效的保護；
2.2 移動設備隨身攜帶，隨時隨地在變換位置，網絡狀況不穩定等不確定因素很多；
2.3 移動設備顯示區域均較小，登錄的注冊頁面通常都會有3個頁面（M站通常在一個頁面），需要用戶填寫的內容要精簡；
2.4 移動設備輸入更多是手指觸屏操作，人機交互有其獨特性，例如虛擬鍵盤的設計。
了解這些之后，需要清楚的甄別兩者之間的關聯和區別。
一、設計前的思考
- 為誰設計登錄注冊
- 是否一定要登錄注冊
- 是否需要獨立的賬戶體系
- 哪些操作需要用戶登錄？
二、登錄注冊的設計步驟
第一步：梳理腦圖，梳理現有的登錄模式和信息結構；
第二步：梳理業務流程，把每一步操作都流程化，做好各種情況的處理方案（梳理流程非常非常非常重要）；
第三步：畫出草圖/線框圖，對頁面元素和布局進行初步設計；
第四步：交互設計，對每一項頁面元素、頁面跳轉、操作反饋、異常處理、按鈕和頁面的各種狀態等做出設計；
第五步：自檢測試，對線框圖和交互設計進行自檢，最好是用Axure等交互軟件進行交互設計操作，建立自己的自檢清單；
第六步：輸出PRD、線框圖和交互設計稿。
三、設計規范
1.賬號
1.1 賬號有無格式的要求，如果只是手機號碼，前端是否需要驗證手機號碼的有效性？
1.2 手機號碼為純數字，是否彈出純數字鍵盤方便用戶快速填寫及避免用戶來回切換？
1.3 手機號碼的數字如何呈現？哪種格式？
2.驗證碼
2.1 驗證碼的格式，是四/六位數字驗證碼，還是英文+數字驗證碼，英文是否區分大小寫？
2.2 按鈕默認顯示狀態、用戶輸入信息后按鈕顏色變化效果，該如何設計比較好？
2.3 倒計時如何設置？button還是label ？用哪個好？如何設計？
3.密碼
3.1 最少和最多字符設置，提示文字為“位”還是“字符”？如“請輸入6-16位字母或數字”？
3.2 密碼是否要限制特殊字符？如“空格”、“/”等，為什么要限制？有沒有安全方面的考慮？
3.3 密碼設置好后，注冊按鈕如何變化？點擊“注冊”后，在網絡較慢的情況下，頁面和按鈕如何響應，是否要加鎖屏浮層+緩沖提示語？
4.錯誤提示
4.1 錯誤時的報錯提示文字是什么，提示格式是彈窗、Toast、還是在當前頁面文字顯示？
4.2 Toast是沒有焦點的，而且Toast顯示的時間有限，過一定的時間就會自動消失。
4.3 彈框會阻斷用戶操作，需要手動點擊確認以后才會消失。
4.4 在當前頁面文字顯示的話，提示文字擺放的位置，頁面格式根據提示文字的變化，需要有怎樣的視覺效果
5.異常提示
5.1 點擊【獲取驗證碼】，檢測手機號已被注冊，如無置灰設置，輸入框為空，手機號碼無效的情況，故需提示：
5.1.1 手機號已被注冊，是否提示用戶登錄？
5.1.2 手機號不能為空，多次為空狀態點擊是否給出頻繁操作提示？
5.1.3 手機號碼不正確，“請輸入正確的手機號碼”是不是比“手機號碼錯誤”好些？
5.2 點擊【注冊】時，可能會有輸入框為空，驗證碼無效等情況，如無置灰設置，故需提示：
5.2.1 短信驗證碼不能為空
5.2.2 驗證碼已被使用，然后給出什么操作呢？
5.2.3 驗證碼已過期，過期了給出彈窗嗎？在彈窗直接獲取驗證碼？
5.2.4 驗證碼錯誤，弱提示？
5.2.5 驗證碼已達到最大嘗試次數，最大是多少次？
6.短信驗證碼
6.1 短信驗證碼一般通過第三方通道發送，在技術側做規避，還需要在產品規則上做一定限制；
6.2 驗證碼的格式需要簡單明了，如“885267，XX驗證碼?！綳XX】”
6.3 驗證碼的字數限制，4位或者6位純數字
7.邀請碼
7.1 注冊是否為邀請注冊？如是邀請注冊，邀請碼格式如何設計？
7.2 邀請碼錯誤提示？填寫了邀請的用戶和沒填的用戶，在注冊成功后有何區別？有邀請碼的用戶是否有獎勵？
8.注冊成功后的提示、狀態變更及頁面跳轉
8.1 注冊成功后同時切換為登錄狀態，登錄狀態賬號密碼保存是否設置期限？
8.2 給予注冊成功的提示并跳轉到相應頁面，目標頁面狀態如何是否有緩存，是否需要緩存？
8.3 之前是在需要token的頁面跳轉到注冊頁面的話，注冊成功后需自動跳轉回之前的頁面
8.4 注冊之前有第三方登錄，用戶注冊后還需要用戶綁定第三方賬號嗎？
四、其他注意事項
- 輸入框
1.1 手機號碼輸入框，手機號碼顯示一般是344格式，這樣便于用戶檢查號碼是否正確，如：138 8888 8888；
1.2 驗證碼輸入框，長度一般比較短；
1.3 密碼輸入框，默認一般為密文顯示，為了更好的交互可以設置明文顯示按鈕，最好只設置1次密碼，為什么這樣？
1.4 其他輸入框，如郵箱、邀請碼、昵稱、個人信息等根據使用場景的不同自行設計；
1.5 不同的輸入框需要有不同的提示內容和顯示狀態。
2.按鈕
1.1 按鈕設計，提交按鈕和文字按鈕的位置和主次布局設計；
1.2 按鈕狀態的設計，不同的狀態操作都要考慮，默認置灰和高亮的條件，按鈕置灰的意義何在？
1.3 按鈕提交反饋，點擊操作要給出響應或反饋。
3.驗證碼
3.1 驗證碼的格式，字母、數字、字符等，一般為數字4位或者6位；
3.2 驗證碼的有效時間，根據不同的產品設計不同的有效時間，在有效時間內的驗證碼操作需要給出明確的反饋；
3.3 驗證碼的獲取次數上限，技術限制和產品設計限制同步，避免被無限制獲取；
3.4 驗證碼獲取時間，一般為第三方發送，但時間最好限定在5.5秒內讓用戶獲取到（不要問我為什么是5.5秒，因為我也不知道）
3.5 驗證碼是怎么觸發得到的？為什么有些設計為點擊下一步或者獲取驗證碼后在頁面跳轉時就獲取，有些頁面跳轉后再次點擊按鈕才能獲?。繛槭裁从胁煌?/p>
3.6 觸發后倒計時狀態有何變化？重新獲取驗證碼后，原驗證碼如何處理？
3.7 短時間內多次獲取驗證碼，是否還要給用戶發送驗證碼？還是提示驗證碼已發送請輸入？
4.返回按鈕
4.1 在注冊、找回密碼、第三方登錄等操作流程中，返回時需要特別注意點擊返回后的操作提示；比如注冊手機的修改，驗證碼提交后設置密碼等。
4.2 點擊返回時，干擾了正常流程的操作一般需要強提示，提示彈窗注意文案和按鈕文字怎么設計好？
4.3 點擊返回后，當前頁面和目標頁面狀態是否變化？例如從填寫驗證碼返回到填寫手機號碼頁面，手機號碼是置空還是顯示已輸入過的手機號碼？
4.4 瀏覽應用過程中進入登錄頁面，登錄頁面是否需要有返回按鈕？
5.虛擬鍵盤
5.1 虛擬鍵盤何時彈出？觸發條件是什么？
5.2 彈出的虛擬鍵盤是什么類型的？數字鍵盤、字母鍵盤？系統自帶輸入法還是第三方輸入法？
5.3 鍵盤上的”Go”按鈕是否有變化？變成”完成“或者”登陸“等后點擊有何交互？
5.4 鍵盤如何隱藏？怎么觸發？自動隱藏？按鍵隱藏？
5.5 鍵盤上的刪除按鈕和一鍵清除按鈕是否有區別？有何區別？有無必要設計一鍵清除？
6.異常提示
6.1 登錄時，賬戶是否在其他設備登錄，是否允許多端同時登陸？不允許同時登陸，之前登錄設備的賬戶是否要下線？給出怎樣的提示？
6.2 密碼第一次錯誤給出什么提示？第二次仍然輸入錯誤，錯誤提示是否需要強提示并給出找回密碼的按鈕？在彈窗點擊找回密碼，手機號碼在新頁面是否需要重新填寫？密碼連續多次輸入錯誤是否要做出禁用限制？
6.3 注冊流程中，檢測到手機號碼已經注冊，是否可以繼續獲取驗證碼？或者驗證后直接登錄免去頁面跳轉和輸入密碼？
6.4 找回密碼和重置密碼都有哪些區別？
6.5.網絡狀態不好，都該給出怎樣的反饋或提示？
6.5.1 用戶所處環境網絡信號不好（用戶向服務器請求超時），是否需要檢查用戶的網絡狀態？還是只給出提示？
6.5.2 服務器沒有正常接收請求或沒有回復，給出怎樣的提示較好？
6.5.3 手機停機，驗證碼、數據傳輸如何處理？
6.5.4 手機沒開wifi或者流量，如何指導用戶進行設置？
7.第三方登錄
7.1 昵稱的長度設置，不同平臺的賬戶昵稱的長度要求不同，該如何獲??？
7.2 綁定多個第三方賬戶，公開信息如何獲取？公開信息不同如何處理？
7.3 用戶注冊前使用過第三方登錄，是否還有綁定手機號碼？
7.4 用戶在PC網頁和APP分別進行第三方登錄，是否有1個第三方賬號生成2個本地賬號的情況？
And so on……
五、蘋果手機鎖屏機制：
前面5次：前面5次輸入錯誤密碼時，手機會震動并提示密碼不正確，但是可以繼續輸入，而且不需要任何等待時間。
第6次：第6次輸錯密碼時，會顯示“iPhone已停用，請1分鐘后再輸入一次”。在接下來的一分鐘內，手機處于鎖定狀態，即使想輸入正確密碼，也無法輸入。
第7次：第7次輸錯密碼，顯示“iPhone已停用，請5分鐘后再輸入一次”，5分鐘內無法操作；
第8次：第8次輸錯密碼，15分鐘內無法操作；
第9次：第9次輸錯密碼，60分鐘內無法操作；
第10次：第10次輸錯密碼，顯示“iPhone已停用，連接iTunes”。這種情況下，無論等待多長時間都沒有機會再出現密碼框，哪怕是一萬年也不行。
