注冊/登錄幾乎是每一個産品都會有的基礎功能，在專門研究了一段時間後，發現雖然注冊/登錄的體系已經非常成熟了，但是裡面還是有着許多坑。所以特别寫了一篇文章來記載這一段時間的一些收獲。

需要特别說明的是：

1. 這篇文章所說的産品對象和我研究的産品對象，如果沒有特别說明，一般都是指移動端。
2. 因為關于注冊/登錄的流程網上已經有許多詳細的寫的非常好的文章，所以我希望能從更底層的邏輯來探讨這件事情。
3. 如果本文有寫的不對或者不完善的地方，歡迎大家來一起來探讨(ง_•)ง。

一、用戶賬号設立目的

維基上這麼解釋“用戶賬号”：

用戶可以通過賬号向系統服務進行身份驗證，并獲取相關權限，但身份驗證并不代表授權。為了會計、安全、數據收集和資源管理，用戶通常需要一個密碼或其他證明以登錄賬号。

我認為這段話已經很好概括了用戶賬号的目的，把這段話提取出關鍵詞就是賬号、系統（服務器）、某種證明方式以及權限。

1. 從現在的移動端産品來看，賬号大多是指：手機号、郵箱以及自定義用戶名等，一些金融類産品還包括身份證等。
2. 系統指的是産品的後台。
3. 某種證明方式則是指：手機号驗證碼、密碼和郵箱驗證等，現在還有少數産品有人臉識别，語音識别等。

權限則根據産品的不同而千差萬别，比如：知乎需要登錄才能進行點贊和評論，B站也需要在登錄後才能調高清晰度。當然對于很多産品來講，注冊/登錄獲得的是可以繼續使用的權限。

圖一.賬戶通過密碼等證明方式獲得權限

從更宏觀角度講，每一個賬戶是構成我們賬号系統的基礎。一個賬号系統的用處自是非常大，我們可以基于我們産品的用戶系統進行大數據分析、設計用戶畫像、運營分析等。所以如果旗下有許多産品的話，設計時最好能讓用戶打通多款産品。

圖二.餓了麼第三方登錄中包括淘寶

而“注冊/登錄”功能就是一個賬戶的基礎構成之一，也是用戶使用大多數産品的第一個門檻。

二、注冊/登錄的目的

從用戶賬号的對于用戶來說，注冊/登錄應該需要達到兩個目的。

1. 安全。特别是對于金融類産品來說。所以常常在注冊該類産品時候需要身份證，真人照等信息。
2. 在安全的基礎上獲得權限。這個權限指的就是前言中提到的各類産品的特性，也可以認為是産品對于用戶需求的滿足。對于一些産品來說，用戶所獲得權限是一樣的。但是對于設立會員制或者其他用戶分層的産品，權限則不相同。

安全需求是用戶隐性需求，用戶隻有在遇到問題時才會需要，比如賬号被盜等情況。而通常用戶更關注注冊/登錄的便捷性。

對于産品方，或者說産品經理來說，注冊/登錄需要達成的目的是

1. 安全風險把控：對于産品方來說，安全問題同樣是至關重要，為防止惡意刷号或者其他安全風險，大多數産品會要求進行手機号綁定。這也是為什麼許多産品在第三方登錄之後，還會要求手機号驗證的原因之一。還有對于大部分金融産品來說，身份證或者身份證和真人照片是必須的注冊時環節之一。
2. 采集信息：這也是因産品而異，通常來講，越是核心的業務需要采集的信息越多。不過為避免降低用戶體驗，通常将這一步與注冊/登錄分開來。比如：電商産品需要地址、郵編等，但通常是在購買時才會要求填寫這些信息。
3. 大數據分析：這包括了産品用戶分析、用戶畫像采集等。
4. 用戶激勵與召回：相信許多人遇到過，産品通過郵箱或者手機來激勵用戶使用産品，或是在用戶流失之後嘗試召回。

從以上幾種情況來看，在設計注冊/登錄時，我認為應該從以下幾點考慮：

1. 安全性：隻要是安全問題，那麼必須放在首要位置考慮。當然，也不必極端到用1%的安全可能去影響99%的用戶體驗。對用戶和系統來說，安全問題是否存在，如果存在，是否嚴重。
2. 快捷性：也是用戶自身最關心的，也是接觸最直接的地方。用戶是否能很快注冊成功，注冊時門檻是否過高，後續登錄是否方便快捷。
3. 業務性：也就是PM方自身的需求，PM和運營人員是否能得到想要的數據。這不僅于注冊/登錄流程和需要的信息有關，也跟PM怎麼埋點和考核指标計算有關。

三、注冊/登錄各類方式

圖三.注冊/登錄各類方式

通常來講，注冊的方式比較單一，而登錄的方式比較多樣化。注冊現在移動端最常見的是手機号 驗證碼的形式和第三方登錄，同時，現在也有許多産品的注冊和登錄為一體。也就是通過手機号 驗證碼的方式，如果是第一次使用，系統會自動注冊一個賬戶。

圖4.美團登錄界面

3.1 是否将注冊/登錄設為第一道門檻

用戶在産品中的遇到需要注冊/登錄的時候情況可以分為兩種：

1. 進入産品的開始；
2. 當使用某項功能時，提示需要注冊/登錄。

第一點是最常見的，對于許多社交類，金融類等産品來說，在一開始采集用戶的核心信息是非常必要的。而第二點多見于社區、視頻類産品等，對于這些産品來說一開始的吸引用戶非常重要。

所以直接開放了浏覽、關注等權限，在用戶想要繼續使用的時候在進行提示。

圖5.知乎在遊客點贊時跳出的界面

那麼我們應該将這一道門檻設置在什麼時候？

根據上文提到三要素，應該重點從第三點“業務性”上考慮，也就是根據産品自身的特性來決定。

通常來講如果你的核心業務必須依賴用戶的某些信息，或者是一款強運營驅動的産品，那麼應該将注冊/登錄設置到一開始的時候。如果産品是内容驅動，或者是工具類産品，那應該将注冊/登錄設置到用戶接觸到核心功能的時候。

3.2 第三方注冊/登錄

我們經常碰到一個問題，就是在使用第三方之後，産品會繼續要你提供手機号或者其他信息等。而用戶使用第三方的原因就是不想使用手機号，這樣會導緻用戶體驗下降。原因主要是第三方可以提供信息有限，産品和運營無法根據這些信息進行後續的用戶運營等，不利于後續的工作。

圖6.小紅書微信授權界面

當然第三方登錄優勢也很明顯，用戶可以快速登錄，極大程度上降低注冊/登錄的門檻。傳播和分享産品也可以利用第三方的産品等，同時也把賬号的安全性問題得到一定的解決。

另外，除了某些工具類産品，很少有産品會完全依賴第三方，也就是直接把自己的用戶系統交給第三方。這樣做會有一定的風險，如果第三方倒閉或者解約的話，會對産品造成極大的影響。所以，即使在一開始不需要用戶的手機号等信息，也會通過一些激勵措施鼓勵用戶綁定手機号等。

3.3 登錄是選擇手機 驗證碼還是手機 密碼

這個問題可能是某些PM遇到的問題，手機号 驗證碼的登錄形式十分方便，但是又有是弊端呢？

還是從安全性，快捷性和業務性三點考慮：

1. 安全性：手機号 驗證碼的形式容易被黑客劫持，或者惡意刷等情況。
2. 快捷性：網絡不好或者服務器出現問題的時候，用戶會收不到驗證碼。
3. 業務性：當後期用戶出現大規模增長的時候，服務費的支持會增大。

而手機号 密碼的方式，也存在會出現密碼忘記，同時也有一定的安全風險，輸密碼更麻煩的缺點。但相比驗證碼的形式更安全一點。

一個産品到底選擇哪一種方式，還是兩者兼有。應該從多方面考慮，如果你的産品更注重安全或者是賬号在多個平台共享的話，應該選用密碼的方式。如果更注重注冊轉化率，應該選用更快捷的驗證碼形式。如果産品處在增長期，也要考慮到成本的控制問題。

3.4 郵箱還是手機号

使用郵箱進行注冊/登錄，多見于PC端和國外的app。不過在移動端，由于郵箱的使用并不方便，而且國内許多用戶并沒有使用郵箱的習慣。所以我們現在很少看到國内的app會使用郵箱注冊/登錄，特别是近幾年的産品。

當然使用郵箱也有其優點，在賬戶丢失和手機号更改的的時候，用戶可以通過郵箱找回，而且郵箱的地址是一直存在的。有些産品用戶希望有多個賬号，比如：遊戲。這時候如果用手機的話，一般人隻有1、2個手機号，而用郵箱注冊/登錄就可以實現多賬戶使用。

同時，還有些情況會适用于郵箱注冊/登錄，比如：你的用戶群體比較特殊，更注重隐私。或者你的用戶群中有用郵箱的習慣，比如：外國人、商務人士等，這些情況是可以使用的郵箱的形式。

四、找回密碼

找回密碼的場景和需求可以大緻分為以下幾類：

1. 手機号沒有更換或丢失，用戶忘記密碼。
2. 手機号更換和丢失，但是有郵箱等其他安全證明關聯賬戶。
3. 手機号更換和丢失，且沒有郵箱等其他安全證明關聯賬戶。

首先，找回密碼的關鍵，在于找出用戶賬戶最安全的保證，并盡量設計其交互和流程簡單直接，現在app最簡便的也是比較安全的保證就是手機号。所以在第一種情況下，隻要設計手機号 驗證碼的形式就可以了，現在大部分app也是這麼做的。

對于第二點，如果有郵箱或者身份證照片等安全證明，也可以找回密碼。但是對于第三種，就隻能人工處理。

五、總結一下

1. 當我們設計注冊/登錄之前，可以先思考一下：我們的用戶是什麼樣的人？在他們注冊/登錄之後，我們可以給予權限是什麼？如果可以簡化流程，是不是可以分步給予相應的權限？
2. 具體設計注冊/登錄流程的時候，可以從安全性、快捷性和業務性。
3. 如果成本和資源允許的話，是否可以設計一種更具用戶體驗的方式。當然，不要忘記安全性。

本文由 @ 十一筆 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部