産品設計路上爬過的(de)坑之：注冊登錄設計
- 發布時間: 2016-01-30 15:10:15
- 浏覽次數: 1775
1.0 非常基礎
1.1 因「私有化」而存在
不是所有的(de)産品都需要注冊/登錄，除非[私有內(nèi)容/私有操作]具有足夠的(de)吸引力。
-
注冊：用戶告訴系統Who is Tom；系統記錄Tom和(hé)口令；
-
登錄：用戶告訴系統I am Tom；系統辨别Tom和(hé)口令；
1.2 Passport産品線及近親
通常把注冊、登錄、找回密碼、修改密碼、賬戶關聯這幾件事歸為(wèi)Passport産品線；它的(de)近親是Profile産品線，包含用戶資料、個人設置等。
1.3 登錄是高(gāo)頻，其他是低(dī)頻
注冊、找回密碼、修改密碼都是低(dī)頻操作，但都屬于迫切程度比較高(gāo)，也最容易引發挫敗感，導緻用戶投訴及放棄使用産品。
1.4 術語：查重、校驗、驗證、匹配
-
查重，"查詢是否有重複存在"的(de)簡稱，比如(rú)：排除以手機為(wèi)主鍵的(de)重複注冊；
-
校驗，檢查數據是否符合格式，比如(rú)：輸入的(de)時候為(wèi)一(yī)個手機号碼；
-
驗證，确認真實性，比如(rú)手機和(hé)郵箱真的(de)是用戶本人使用，指紋、人臉識别；
-
匹配，用戶提交的(de)數據是否與存儲中的(de)數據一(yī)緻。
1.5 術語：Spam與Anti-Spam
Spam指使用腳本、機器人進行惡意批量提交或遍曆破解的(de)行為(wèi)； Anti-Spam指防止Spam的(de)系統措施。
1.6 術語：單點登錄OOS
也就是所謂的(de)通行證，注冊/登錄一(yī)次，可(kě)在所有的(de)子(zǐ)産品（跨域）中通用一(yī)個Passport和(hé)相同的(de)Profile信息。
2.0 注冊主鍵選擇
主鍵是數據庫設計中的(de)一(yī)個概念，為(wèi)了保證唯一(yī)性，新增用戶時必須進行[主鍵查重]。
2.1 以用戶名為(wèi)主鍵注冊
Anti-Spam：非常弱（批量Spam賬戶）。 擴展性：高(gāo)，随時可(kě)切換為(wèi)以其他數據為(wèi)主鍵。 使用場景：私有內(nèi)容/私有操作較少的(de)情況，比如(rú)僅提供了回複、投票(piào)、點贊等[輕操作]； 産品雛形期，進行測試的(de)新産品（開發比較容易）。
便利設計：
-
注冊和(hé)登錄可(kě)合并在同一(yī)個界面（不考慮找回密碼時）；
-
注冊時可(kě)順便把用戶名當作昵稱搜集。
注意事項：
-
為(wèi)了讓用戶找回密碼，必須設置密保問題，找回密代價很高(gāo)（把自(zì)己用戶名給忘記了）。
2.2 以郵件地(dì)址為(wèi)主鍵注冊
Anti-Spam：中等（自(zì)從QQ郵箱出來，被遍曆攻擊的(de)事兒也是不少啊）。 擴展性：中，可(kě)以随時切換為(wèi)手機主鍵。
使用場景： 郵箱容易記憶，适長(cháng)期頻繁使用的(de)産品；适合在web端需要依賴Newsletter進行營銷的(de)産品；非實名用戶系統，郵件主鍵的(de)代價最小，轉化率較好。
便利設計：
To B産品使用企業郵箱注冊，自(zì)動關聯企業主賬戶。
注意事項：
郵箱是隐私，掩碼顯示，如(rú)果包含社交功能，注冊時可(kě)能需要采集昵稱；
進入各大郵件運營商的(de)白名單，是一(yī)件頭疼的(de)事兒，搞不好就直接進垃圾郵件了。
2.3 以手機為(wèi)主鍵注冊
Anti-Spam：弱（各種遍曆、各種騷擾，需要采取措施）。
擴展性：低(dī)，幾乎不可(kě)逆（用戶也不答應）。
使用場景：帶有支付功能的(de)電商、消費類産品；實名用戶系統，需要用戶的(de)絕對信任，初期轉化率低(dī)，最好從郵件主鍵過度；隻有移動版本的(de)産品。
便利設計：
根據手機号自(zì)動匹配地(dì)區城市、電信運營商（也有一(yī)部分用戶是攜号轉網的(de)#_#）。
注意事項：
手機是絕對隐私，能不顯示就不顯示，顯示必須掩碼，如(rú)果包含社交功能，注冊時可(kě)能需要采集昵稱；國外手機号幾乎不可(kě)以，短(duǎn)信通道(dào)需要至少雙備，如(rú)果驗證短(duǎn)信中包含一(yī)些根本想不到的(de)敏感詞，會很慘；用戶更換手機，運營商回收舊(jiù)号碼賣給新用戶，都會大量存在，請一(yī)定給出解決方案。
2.4 由第三方賬戶創建（并登錄）
Anti-Spam：高(gāo)（等于是把驗證權交給别人了）。 擴展性：高(gāo)，可(kě)以在第三方驗證後再創建自(zì)有賬戶。
使用場景：幾乎适合各種類型的(de)用戶自(zì)主注冊賬戶。
便利設計：可(kě)以根據第三方授權拿來一(yī)大堆Profile裏邊的(de)信息（除了密碼）。
注意事項：把雞蛋放在了别人的(de)籃子(zǐ)裏，一(yī)定要心甘情願；登錄之後再創建自(zì)有賬戶，會存在一(yī)定的(de)轉化率損失；去(qù)第三方申請授權，要有耐心，而且通常在産品初期拿不到太多的(de)Profile數據。
2.5 社會卡證類主鍵（身份證、信用卡）注冊
Anti-Spam：高(gāo)，因為(wèi)規律性比較差，但也不排除社會工程hack手段。 擴展性：都到了這步了，算是個終極。。 使用場景：特殊場合和(hé)人群，需要展示特殊的(de)功能；實名用戶系統，需要用戶的(de)絕對信任；必須關聯在線支付/移動支付才能使用的(de)産品；通常都不會包含社交功能。
便利設計：
直接關聯到用戶真實身份和(hé)征信。
注意事項：
通常驗證都是通過第三方信用組織進行，比如(rú)提交信用卡關聯的(de)身份信息，由支付機構或銀行匹配之後發送一(yī)個驗證短(duǎn)信/郵件/二維碼；同樣是把雞蛋放在别人的(de)籃子(zǐ)裏（通常是親爹的(de)籃子(zǐ)）。
2.6 其他主鍵
用汽車牌照做(zuò)主鍵，真的(de)可(kě)以有；不是不可(kě)以，但是盡量還是别摸着石頭過河；注冊主鍵在真實社會裏一(yī)定是具有非重複且個人專有的(de)特點。
2.7 多主鍵複合注冊
當然可(kě)以啦，注冊時沒必要提示用戶哪個是主鍵，反正登錄的(de)時候會提示。
2.8 切換主鍵時注意事項
其切換主鍵之前，一(yī)定要對數據進行篩查，情況可(kě)能是這樣的(de)，用戶使用郵件主鍵生成了一(yī)個用戶，當系統切換手機為(wèi)主鍵時，用戶會因迷惑而創建另外一(yī)個新賬戶，此時可(kě)能涉及到用戶數據合并的(de)問題。如(rú)果這些沒有想清楚，就不要随便更換主鍵。
3.0 個人注冊（To C）
3.1 查重錯誤，不要在注冊環節随便給出
填寫一(yī)個手機号碼，異步查詢是否可(kě)以注冊，雖給用戶帶來了方便，但也給駭客提供了可(kě)乘之機：寫一(yī)個腳本就能遍曆出來哪些号段多少個号碼注冊過産品！ 請在驗證碼正确之後給出結果，或者單獨跳轉URL給出查重類錯誤
3.2 前端校驗和(hé)後端校驗都要進行
跨域攻擊是最簡單的(de)手段咯，注冊這麽大的(de)事兒，一(yī)定要進行前後校驗（登錄之後，可(kě)以根據系統壓力再進行簡化，登錄之前，還是謹慎為(wèi)妙）。
3.3 以郵箱和(hé)手機注冊主鍵，第一(yī)步隻做(zuò)一(yī)件事：驗證主鍵
沒有驗證過的(de)郵箱和(hé)手機會弄髒用戶數據，髒庫是無法切換登錄主鍵的(de)！ 注冊的(de)第一(yī)步，隻做(zuò)一(yī)件事情就好了，不要讓用戶填寫其他信息（填寫密碼也不行）。
3.4 分步注冊，暫存數據
隻有在用戶提交密碼那一(yī)刻，才創建正式數據
如(rú)果第一(yī)步是校驗主鍵，那麽應該暫存數據，隻有在主鍵驗證完畢，下一(yī)步用戶填寫密碼并提交之後，再創建正式數據。
（這個坑是這樣的(de)：用戶第一(yī)步提交郵箱，但是驗證郵件沒收到，此時可(kě)能用戶會再次啓動注冊，如(rú)果前面已錄入正式數據，可(kě)能會顯示這個"這個Email已經注冊過了"）。
3.5 有必要重複确認密碼麽？
沒必要！設置這個的(de)初衷無非是避免用戶注冊時輸錯密碼，輸錯=忘記密碼，就去(qù)找回密碼咯。
3.6 隻采集必要數據，填寫項目越少越好
在注冊環節，标注[必填]是個爆弱的(de)設計，如(rú)果是選填，就别讓用戶在注冊環節提交。
3.7 包含社交的(de)産品一(yī)定要讓設置頭像成為(wèi)必填
注冊之後，需要很大的(de)運營代價才會讓用戶上傳頭像，因此這一(yī)步驟最好是前置。
3.8 昵稱需要查重麽？
需要！避免李逵和(hé)李鬼；盡量杜絕錄入火星文和(hé)特殊字符（視(shì)情況額定）。
3.9 驗證碼何時出現？
參考後面 章(zhāng)節7.3
3.10 讓用戶發送密碼短(duǎn)信到特定号碼進行手機注冊，這很矬
誰會用？有多少用戶願意自(zì)己付出短(duǎn)信成本？除非特别緊急的(de)情況下。
3.11 同意《用戶使用協議》
讓用戶勾選閱讀并遵守《用戶使用協議》，不如(rú)把注冊按鈕改為(wèi)"同意用戶協議，提交注冊"
3.12 邀請碼注冊要走單獨流程
輸入邀請碼或點擊邀請郵件中加密連接進行注冊，可(kě)關聯邀請者ID，需要的(de)單獨設計注冊界面。
3.13 注冊與登錄合并設計（快速注冊）
以用戶名和(hé)手機為(wèi)注冊主鍵的(de)時候，可(kě)以這樣設計；但以郵箱注冊的(de)時候，用戶需要跳出到郵件系統，快速注冊就沒意義了；快速注冊以後自(zì)動進入登錄狀态。
3.14 注冊結束後，必須讓用戶再登錄一(yī)次（快速注冊除外）
這不僅僅是個儀式感，而且是安全的(de)需要，增加自(zì)動腳本Spam賬戶的(de)難度。
3.15 注冊應該避免設計成light box（快速注冊除外）
注冊複雜程度不一(yī)，并且會經常叠代改善産品，因此校驗代碼和(hé)各種邏輯判斷非常多，如(rú)果做(zuò)成light box效果，可(kě)能會拖累很多界面的(de)加載速度，也會讓維護和(hé)測試變得麻煩。
3.16 注冊後的(de)（首次登錄後）歡迎與提醒，設立URL暫存池
注冊完成有結果提示和(hé)簡單的(de)歡迎，然後就需要讓用戶進行跳轉； 記錄用戶點擊注冊之前的(de)界面URL，在用戶跑完注冊/登錄流程之後，回到那個URL（"從哪裏來，就回到哪"）； 如(rú)果無法判斷用戶注冊登錄前的(de)URL，那麽跳轉到一(yī)個最核心的(de)私有內(nèi)容界面； 用戶可(kě)以選擇回到Profile管理(lǐ)；
4.0 企業商家注冊/入駐（To B）
4.1 商家注冊（申請）建立在個人賬戶基礎上
先完成個人賬戶注冊，再創建商家；在注冊商家的(de)同時，創建一(yī)個個人賬戶；以上兩種方法都可(kě)以。因為(wèi)商家賬戶的(de)管理(lǐ)者通常是員工，如(rú)果該員工離(lí)職，企業會要求進行管理(lǐ)權轉移，把商家挂在個人賬戶下面，靈活度最高(gāo)。
4.2 在注冊之前分流角色，而不是注冊過程中
企業商家用戶通常按行業分類，比如(rú)賣方需要提供代理(lǐ)證明，而買方需要填寫收貨地(dì)址；此時最好設置為(wèi)兩個入口，而不要在注冊的(de)過程中進行條件分支。
4.3 審核期過度界面
通常企業商家注冊都需要一(yī)個運營審核過程，此時，用戶可(kě)登錄個人賬戶使用一(yī)些基本功能，請把審核進度明示給用戶，同時給予企業商戶功能的(de)演示介紹。
4.4 企業子(zǐ)賬戶應該是邀請的(de)，而不是随便填寫的(de)
不要讓企業商戶管理(lǐ)員直接填寫子(zǐ)賬戶的(de)用戶名和(hé)密碼，建議企業子(zǐ)賬戶以email為(wèi)主鍵，走邀請的(de)流程，讓其他員工自(zì)己驗證郵件、填寫驗證手機和(hé)密碼，這樣做(zuò)責權清晰，安全性最高(gāo)。
4.5 企業管理(lǐ)員不能直接修改子(zǐ)賬戶密碼
企業管理(lǐ)員觸發一(yī)個驗證郵件給子(zǐ)賬戶，子(zǐ)賬戶可(kě)以自(zì)行通過加密連接修改密碼；必要時，管理(lǐ)員可(kě)以凍結那個強制要求修改密碼的(de)子(zǐ)賬戶的(de)權限。
5.0 登錄
5.1 登錄主鍵提示
在主鍵input當中，允許用戶填寫不同的(de)主鍵，雖然校驗比較麻煩，但是用戶便利了。
5.2 注意登錄錯誤信息抛出方法
單獨抛出"該用戶不存在"或者"密碼不正确"可(kě)能會是不科學(xué)的(de)，因為(wèi)很可(kě)能方便了别有用心的(de)人，比較安全做(zuò)法是"用戶名不存在或密碼不匹配"。
5.2 記住用戶和(hé)記住密碼是兩種不同的(de)功能
一(yī)種是保存"主鍵"，另外一(yī)種是保存"主鍵+口令"。記住用戶名，就一(yī)定要有切換用戶的(de)功能；保存口令，要看産品的(de)使用頻率，使用頻率越高(gāo)保存周期越短(duǎn)（在便利和(hé)安全之間的(de)平衡），保存周期最好不要超過3個月（甚至可(kě)以設置3個月強制更換密碼）
5.3 驗證碼何時出現？
參考後面 章(zhāng)節7.3
5.4 防止重複登錄
這個經常被忽略，同客戶端，後來登錄的(de)踢掉前面的(de)session;允許web、手機app、HDapp同時登錄，但每個終端智能保持一(yī)個session哦
5.5 盡量設計成light box或類似效果，登錄之後"從哪裏來，就回到哪"
注冊、登錄前暫存URL，還是一(yī)個很重要的(de)登錄彩蛋。
5.6 二維碼登錄
如(rú)果有移動app，通過App掃二維碼可(kě)以直接登錄web版本。
5.7 長(cháng)期未登錄、陌生移動設備登錄，加一(yī)個判斷，通知到郵件
長(cháng)期未登錄，突然在異地(dì)登錄，在陌生的(de)移動設備上首次登錄都屬于異常的(de)情況，此時要增加用戶判斷的(de)環節，并發送通知到郵件。（手機号碼可(kě)以換，郵件地(dì)址不會随便換吧(ba)）
6.0 找回密碼/修改密碼
6.1 密碼的(de)安全
除了足夠的(de)位數要求、大小寫和(hé)特殊字符要求，可(kě)以通過判斷要求用戶不允許把密碼修改為(wèi)曾經用過的(de)密碼（開發量略大），不能使用常見密碼、純數字密碼、生日密碼等。指紋、虹膜、手勢……密碼的(de)種類會越來越多的(de)。
6.2 按問題找回密碼，或創造問題找回密碼
直接輸入郵箱和(hé)手機就能找回密碼，不是一(yī)個好設計，應該還是要進一(yī)步判定身份；設置找回密碼問題是通常的(de)設計；可(kě)以嘗試"下面多用戶哪些是你曾經的(de)聯系人"、"請輸入你曾經用過的(de)密碼""下面哪些寶貝你曾經購買過"等等；為(wèi)了防止Spam，設置一(yī)個驗證碼也可(kě)以。
6.3 按郵箱找回密碼
發送一(yī)個密碼找回函，用戶通過加密連接修改密碼，密函有效期盡量短(duǎn)一(yī)些； 如(rú)果用戶說"郵箱密碼忘記了，或者郵箱不用了"，那就無法修改密碼，人工服務也不行！
6.4 按照手機找回密碼
手機發送要防遍曆Spam，手機驗證碼有效期越短(duǎn)越好，10~20分鍾就可(kě)以。
要提供"這個手機号碼已不再使用"的(de)解決方案，僅以手機為(wèi)主鍵，且手機丢失、号碼不再使用的(de)情況，要求進行驗證，比如(rú)：
-
"下面多用戶哪些是你曾經的(de)聯系人"
-
"請輸入你曾經用過的(de)密碼"
-
"下面哪些寶貝你曾經購買過"
等等
然後再進行解綁和(hé)重新綁定；必要時加入身份證信息上傳功能；實在不行了，再轉人工服務；
手機丢了怎麽辦？手機不是有屏保密碼麽？不設屏保密碼，那責任在誰？
6.5 找回密碼/修改密碼之後，必須讓用戶再登錄一(yī)次
依然是一(yī)個安全問題，也是給Spam腳本增加難度。
6.6 找回密碼/修改密碼與提醒
用手機找回密碼，就不要發手機提醒了，發個郵件是可(kě)以的(de)；
用郵件找回密碼，不需要特殊的(de)提醒； 隻用問題就找回密碼，發個郵件比較好；
郵箱本身有密碼，手機本身可(kě)能無密碼（易被濫用），因此，用郵箱找回密碼安全級别較高(gāo)。
6.7 人工密碼服務
必須通過系統內(nèi)保存的(de)郵件發送相關的(de)身份證明，不能随便找個郵箱或者qq就發送了； 不是修改密碼，而是人工發送一(yī)條密碼找回函到注冊時的(de)主鍵郵箱； 人工解綁、綁定手機的(de)這個功能，不推薦，道(dào)德風險比較大； 呼叫中心成本比較高(gāo)，現在流行用微信做(zuò)人工服務；
7.0 驗證郵件、驗證短(duǎn)信和(hé)驗證碼
7.1 要控制郵件發送的(de)頻率
雖然用戶可(kě)能不反感，但是郵箱提供商可(kě)能直接認為(wèi)是垃圾郵件地(dì)址了； 可(kě)以努力通過技術手段或者購買服務，進入各大郵件運營商的(de)白名單；
7.2 手機短(duǎn)信這個坑啊
如(rú)果大量依賴手機主鍵，短(duǎn)信運營商至少要找兩家，進行雙備份；要有[熔斷]機制，在某一(yī)時間段內(nèi)，不允許連續發送短(duǎn)信到某個手機（防止Spam）。曾經遇到過惡意的(de)将驗證碼連續發送到某個手機（當然不是黑客自(zì)己的(de)号碼），用戶直接投訴，整個短(duǎn)信通道(dào)被運營商封殺，直接跪了；多次沒收到短(duǎn)信，要給予時間間隔，此間不允許發送，要求客戶耐心等待；短(duǎn)信內(nèi)容要提前發送測試，總有一(yī)些敏感詞，臣妾想不到啊；
7.3 驗證碼何時出現
Anti-Spam的(de)驗證碼降低(dī)了用戶感受，因此，推薦在初次使用時不出現驗證碼，在1~3次錯誤之後，出現驗證碼；盡量讓驗證碼新奇好玩一(yī)些，減輕用戶反感。
8.0 Passport産品經理(lǐ)須知
8.1 需要專職的(de)産品人員和(hé)運營人員負責Passport？
如(rú)果是電商、線上交易類的(de)，幾乎必須專人負責了；如(rú)果包含支付環節，又木有專人負責，最好直接使用成熟的(de)登錄/注冊設計，不要标新立異；如(rú)果整個産品隻有一(yī)個人操辦，那麽恭喜了，這個文檔也許有些幫助。
8.2 注冊轉化率那點事兒
要看追求何種目标，如(rú)果是以注冊量為(wèi)KPI，注冊過程越簡單越好，在注冊之前盡量給與更多的(de)利益展示；
8.3 注冊統計
通過促銷活動注冊的(de)用戶，要單獨進行渠道(dào)統計，雖然理(lǐ)論上這些幾乎都不會成為(wèi)持久的(de)DAU，但總是需要知道(dào)各種渠道(dào)的(de)效果對比
8.4 與運營團隊配合解決問題
本文羅列的(de)問題，僅能算作一(yī)些基礎，實際運營過程中，用戶在注冊/登錄問題是千奇百怪的(de)，大家還是要有個心理(lǐ)準備。
為(wèi)1%的(de)用戶創建100%的(de)功能，得不償失，但産品經理(lǐ)總是要給出一(yī)些答案。
