今天的主題是和註冊登錄相關的內容，相對比較簡單，大家應該都很熟悉。
註冊登錄一直是應用中必不可少的一環，用戶打開應用可能第一步就是登錄頁面，這相當於一款應用的臉面，也是用戶使用產品的源頭。當然也是因為不常被用到所以更最容易被忽視，它作為一項基礎功能，使用場景一般是用戶初次使用應用或者退出登錄，又或是大版本更新和登錄過期才會使用到。
註冊登錄的意義就在於給用戶獨有的個人中心，包括數據的同步，或是用戶註冊後會通過用戶已完善的資料進行相關的內容推薦。
登錄相對而言屬於高頻次的操作，註冊、修改密碼等屬於相對低頻次的操作，但是他們都會關聯到產品內的個人資料和設置模塊。幾乎所有的社交應用都是需要註冊登錄的，用戶擁有了個人賬號才能繼續使用產品。
當然也有一些系統的應用是不需要註冊登錄就可以使用的，比如：系統自帶的計算器、日曆、天氣等或是一些第三方的輕應用，這裡就不多贅述了，下面主要還是說說需要用到註冊登錄功能的情況。
還是先來看一下整體結構：
（以下圖片來源於應用截圖，僅作為學習交流使用）
一、註冊登錄的方式
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協議
閱讀更多 人人都是產品經理 的文章
