註冊登錄一直是應用中必不可少的一環，用戶打開應用可能第一步就是登錄頁面，這相當於一款應用的臉面，也是用戶使用產品的源頭。
今天的主題是和註冊登錄相關的內容，相對比較簡單，大家應該都很熟悉。
註冊登錄一直是應用中必不可少的一環，用戶打開應用可能第一步就是登錄頁面，這相當於一款應用的臉面，也是用戶使用產品的源頭。當然也是因為不常被用到所以更最容易被忽視，它作為一項基礎功能，使用場景一般是用戶初次使用應用或者退出登錄，又或是大版本更新和登錄過期才會使用到。
註冊登錄的意義就在於給用戶獨有的個人中心，包括數據的同步，或是用戶註冊後會通過用戶已完善的資料進行相關的內容推薦。
登錄相對而言屬於高頻次的操作，註冊、修改密碼等屬於相對低頻次的操作，但是他們都會關聯到產品內的個人資料和設置模塊。幾乎所有的社交應用都是需要註冊登錄的，用戶擁有了個人帳號才能繼續使用產品。
當然也有一些系統的應用是不需要註冊登錄就可以使用的，比如：系統自帶的計算器、日曆、天氣等或是一些第三方的輕應用，這裡就不多贅述了，下面主要還是說說需要用到註冊登錄功能的情況。
還是先來看一下整體結構：
（以下圖片來源於應用截圖，僅作為學習交流使用）
一、註冊登錄的方式1. 只使用第三方帳號註冊登錄這種方式比較少但是無疑是最快捷的方式，相信大家平時應該用這種方式也比較多，因為可以避免使用手機註冊帶來的繁瑣步驟，可以節約很多時間。
你在第三方應用中進行授權後產品會直接調用接口，生成ID登錄後，你的頭像、暱稱等個人信息甚至可能同時會獲取你的好友列表，讓你知道還有哪些好友也在使用產品，可以有效地減少對產品的陌生感，同時也便於應用在第三方中進行分享。
當然這種方式對產品也很有利，因為相信很多用戶在不了解產品的情況下，用戶可能只是想初步了解一下產品，但是又不想進行手機註冊那麼麻煩，所以就直接使用第三方進行註冊吧，待進入應用初步使用了解後，再通過產品的用戶引導（比如：紅點標記或是局部引導等）功能再進行手機號/郵箱/微信/微博等帳號的綁定，這樣做對新用戶的產生有積極作用。
我遇到過當已經使用了第三方應用註冊登錄了之後，會立即出現讓用戶綁定手機號的頁面，這樣做是想快速產生新用戶，出發點是好的，但是我覺得用戶在不了解產品的情況下，綁定手機號的可能性很低。
所以最好可以在綁定手機號頁面有「跳過」功能，給用戶選擇的餘地，不要強制用戶，待初步了解產品後再通過引導進行綁定，這樣做最佳。
2. 只使用手機號註冊登錄使用手機號獲取驗證碼是目前最常用的註冊登錄方式，這種方式的優勢不必多說，相信大家都很熟悉流程，通過發送簡訊獲取驗證碼在60-90秒內進行註冊登錄，這麼做是為了確認用戶擁有該手機號的使用權。手機號+密碼是用戶常用的方式，而手機號+驗證碼是比較簡便的方式。
這裡注意一點的是在輸入手機號後，為了讓用戶查看是否輸入正確，建議手機號顯示樣式為3-4-4模式（比如：156 5555 5555），這些都是細微之處，雖然無關大雅，但是可以看出一個產品的用心之處，比如：下圖可以對比一下，明顯圖二更優。
手機號也是商家進行用戶維護的有效手段，畢竟手機都是隨身攜帶，可以在節假日發送祝福或是促銷簡訊，也可以在你長期未使用產品，進行簡訊提示，避免你將產品遺忘，但是過度的簡訊轟炸則會讓用戶感到反感。
另外使用手機號註冊登錄，需要做一個判斷，是否是第一次登錄，是的話就跳轉引導頁，不是的話就跳轉至首頁。
這裡插一句題外話，你們有沒有遇到過在已經註冊成功後，但是還需要重新輸入帳號密碼登錄的情況，其實這種做法個人覺得是比較多餘的，可能2次輸入帳號密碼可以加強用戶的記憶。但是可能很多人用手機號註冊都是用的一個同密碼，因為現在的應用可選擇的餘地實在是太多了，如果每個應用都使用不同的密碼可能很難記得住。
3. 使用手機號/第三方帳號註冊登錄這種樣式是最常見的，也是上面兩種樣式的結合，這種樣式給用戶留有選擇的餘地，自願使用手機號或是第三方。但是一般這樣的組合方式多數是希望用戶使用手機號註冊，所以手機註冊登錄比較突出，第三方註冊會置於頁面底部，相對弱化。
但是還有一類是希望用戶使用第三方登錄，弱化手機號註冊登錄的情況。BAT旗下的眾多應用，會使用一個帳號或是進行帳號關聯，比如：阿里旗下的應用閒魚、菜鳥裹裹等，登錄時為了用戶數據之間連接，會推薦用戶使用淘寶帳號進行登錄，從而弱化了手機號註冊登錄，這是出於產品屬性或是戰略需求考慮，無可厚非。
4. 使用郵箱註冊登錄使用郵箱進行註冊登錄也是比較常用的方式，多數用於pc端，郵箱容易記憶，便於頻繁使用的產品，註冊後郵箱會收到驗證連結，驗證成功後會自動跳轉進入該網頁首頁。因為web端屏幕較大，還是和移動端有點差別，需要填寫的表單可能也會比較多，關於表單的設計可以參照我早期的文章：《進行表單設計需要注意這十點》
當然移動端也有使用郵箱註冊的，可能是國外的應用居多，比如：facebook、twitter、dribbble…或是國內的應用同時擁有網頁和移動端，可以將用戶數據進行同步。
5. 先體驗後註冊登錄這種方式也很多見，一般多為閱讀類、遊戲類或是電商類產品，用戶多為遊客狀態，可能只是進來逛逛，可能暫時還沒有使用到添加、收藏、關注、評論、購買等功能，如果使用這些功能就必須要進行註冊登錄了，注意在完成註冊登錄後記得頁面要回到之前瀏覽的頁面，而不是回到首頁。
6. 簡訊註冊比較少見的一種方式，通過編輯簡訊發送至XXX後，可獲取帳號和密碼。這種方式屬於早期的一種方式，現在基本用不到了，就不多說了。
二、註冊登錄頁面要點1. 簡潔風 VS logo+輸入框iOS 11更新帶動了新的設計趨勢，大標題+留白被廣泛使用，註冊登錄也不例外，現在很多產品都使用相對簡潔的設計（下面左圖），僅使用大標題和必要的線框和提示語，讓用戶只聚焦註冊登錄本身，去除多餘的幹擾元素，可以節省用戶的時間。
相對早期的設計手法是在頁面中加入logo（下面右圖），好處是可以進一步強化用戶對產品品牌的記憶點。兩種方式各有優點，沒有對錯，產品可以酌情使用。
2. 分步驟註冊登錄現在有很多應用是採用分步驟進行註冊的，比如先輸入手機號，點擊「下一步」的同時，系統查詢該手機號是否可以註冊，通過的話則進入輸入驗證碼頁面，這樣做的好處是可以及時反饋給用戶，避免了用戶在輸完手機號和驗證碼之後出現錯誤toast的情況。
需要注意的是步驟不宜過多，建議3步以內，如果你的產品對用戶來說不是非用不可，可能會有很多用戶會放棄註冊。
3. 註冊登錄合二為一這種方式和分步驟註冊類似，將註冊和登錄合到一起，不管你是否有註冊，只要輸入手機號再填寫驗證碼，成功後即可使用產品，比如：小黃車就是使用這一方式。
4. 輸入框提示語輸入框提示語是必不可少的，措詞需要簡潔，大部分的做法是點擊輸入框後提示語自動消失，這樣做也是可以，畢竟需要填寫的選項不是很多，用戶不易忘記。當然更好的做法是保留提示語，比如：星巴克的登錄頁面，在點擊輸入框後，提示語會上移，依舊保留，只是這樣的開發成本可能會稍大一點。
5. 忘記密碼忘記密碼的功能一般都是放在登錄頁面，因為兩者有較強的關聯性。使用忘記密碼功能一般是通過手機號發送驗證碼，驗證通過後再進行新密碼的設置。如果起初是用郵箱註冊登錄的話，就要到郵箱中進行驗證，驗證通過後再進行新密碼的設置。
6. toast提示這裡的toast提示一般用於有錯誤發生的情況下，比如：帳號不存在、帳號已被佔用、密碼錯誤、驗證碼錯誤等，及時的反饋給用戶註冊登錄不成功的地方在哪裡，以免用戶摸不著頭腦，憤而離開應用。
三、其他要點1. 安全碼出於安全考慮，有些應用會讓用戶輸入圖形驗證碼、字符驗證碼、旋轉圖片、滑動驗證等方式，目的是確認是人為註冊而非軟體惡意註冊。
2. 用戶協議用戶協議看似非常的不起眼，用戶也很少會去點擊查看，出現在註冊頁面的情況居多。早期一般是默認被選中狀態或是點擊註冊即視為同意協議條款（圖一），用戶填完帳戶密碼之後點擊註冊就完成了。
但是前去年支付寶默認用戶協議被選中導致的一系列新聞提醒我們，用戶協議最好需要用戶自己去點擊確認，現在很多應用也開始這麼做，在沒有勾選用戶協議之前，「註冊」button是無法點擊的（圖二）。
3. 密碼眼睛開合出於使用場景考慮，比如：在戶外或是註冊登錄時身邊有人，為了有效保護用戶的密碼隱私，可在輸入密碼時關閉眼睛icon，只顯示密碼點。開啟眼睛icon時是為了讓用戶清楚的看見自己的密碼，避免密碼輸入錯誤。
4. 一鍵刪除帳戶名/密碼這個功能是給用戶在註冊登錄頁面輸入有誤或是切換帳戶時使用，可以有效減少用戶的點擊次數，提升用戶體驗。
5. 保留帳戶名數據在用戶曾登錄過的情況下，應該保留用戶的帳戶名數據，這樣用戶重新登錄時只需填寫密碼或驗證碼即可。當然，用戶如果想重新輸入帳戶名，一鍵刪除數據的功能也顯得很有必要。
還有一點是多帳戶之間的登錄切換，在登錄時可以選擇多個帳號，這個功能在to C類應用比較少，一般是to B類應用可能會用到，因為企業可能會擁有多個帳號，這個功能就會顯得很有必要。
6. 帳號後綴關聯這種針對使用郵箱註冊，比如說在用戶填寫帳戶名輸入@的同時，關聯出@qq.com、@163.com等，可以減少用戶的輸入，體驗也會更好。
7. 去除雞肋操作在註冊登錄時也會有一些比較多餘的操作，比如：二次確認密碼、完善個人資料等，這些操作最好是放置在個人中心或是設置裡讓用戶自行填寫，在註冊登錄頁面只保留必須填寫的內容。
總結綜上所述，註冊登錄看似是很簡單的頁面布局，並且容易忽視，但是它的地位是不可忽視的，其中的交互方式和細微之處還需要我們多多考慮，不同的產品需要根據自己的屬性來選擇符合自己的方式。
如有遺漏，歡迎大家留言補充，一起交流~
作者：EasonZhang，公眾號：Eason張UED（ID：EasonZhangUED）
本文由 @EasonZhang 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議