問題看上去很簡單，但如果在初始設計時能避免，可以少走些彎路。

我供職于唯品會，是移動前端的一位產品經理，主要負責“個人中心”內各產品模塊的管理及維護。

如果各位有下載唯品會APP，吶，“個人中心”的入口在APP首頁左下角的人像點進去：

這個入口，里面的產品模塊主要有幾個：

1. 訂單管理（完成結算后的訂單，取消、退貨、換貨等）
2. 菜單管理（菜單增減可配置、紅點可配置、運營文案可配置等）
3. 賬戶體系產品（登錄/注冊/聯登/忘記密碼/完善賬戶信息等）
4. 另外還有各種其他業務的菜單入口（如唯品花、唯品客服等）

其中，我負責的部分主要是2、3，其余由另外的產品負責。今天，主要主要講講注冊。

首先，我們談談為什么會有注冊。

我認為，從用戶使用場景來講，注冊并非用戶的直接需求——并沒有用戶會為了注冊而注冊。言下之意即——用戶操作注冊的具體使用場景，總是有其他的目的。比如：為了把某件商品加購物車、收藏某個心儀的商品、領一張滿100減20的優惠券等等。

私以為，注冊其實是系統的需求。系統需要一個唯一的ID去標識某一個用戶，這樣才可以把與其相關的數據匯總、對應起來。所以，大部分工具型產品，并沒有做注冊或登錄。

說到這里。其實需觸發登錄、注冊的場景，需遵循一個原則：如無必要，勿增實體——不需要登錄注冊的場景，應盡量避免增加登錄態的觸發點，避免打擾用戶的使用場景（進入某寶的個人中心必須登錄/注冊，而唯品會APP不需要，可以思考一下為什么）。

另外，讓我們談談賬戶體系。

總覽業內關于登錄/注冊的文章，我發現大部分的談論一般僅僅局限在登錄和注冊。而沒有一個賬戶體系的全視角視圖（也可能是有人寫了但我沒碰到哈）。從唯品會的業務視角來看，完整的賬戶體系，實際上包含了一串兒業務：密碼登錄、手機號注冊、短信驗證碼登錄、忘記密碼、聯登、完善賬戶信息、登錄保護、設置綁定手機、修改綁定手機、賬戶安全等。

而注冊流程，位于賬戶體系的頂端，它的設計，直接或間接地決定了其余流程的設計——因為注冊流程決定了賬號的基本必要信息。

唯品會從08年創立，設計注冊流程之初難免有考慮不周之處，因此，在流程迭代的過程中，去兼容老用戶的正常使用（俗稱補坑），也成為了一項非常艱巨的工作。

讓我們設計一個不好的注冊流程

最近在讀一本書《數學之美》，這本書除了干貨滿滿，其中提到一點我很欣賞。大意是：與別人分享不好的方法，可以讓他人避免走一些彎路。至于什么方法好，相信總會有更牛逼的人會想出來。下文所述，也算拋磚引玉了。

唯品會APP注冊 1.0

初代注冊流程邏輯（APP 5.1之前的版本）：可使用郵箱/手機號注冊，注冊僅需輸入手機號或郵箱和密碼即可，不校驗手機號、郵箱的真實性；注冊成功后，將手機號/郵箱設為賬號的賬號名（祭上一張珍藏的陳年老圖）：

舊注冊流程產生的賬號，包含的信息：

• 賬號名（形式為郵箱或手機號，不可更改。用于登錄；也可以用于忘記密碼）
• 密碼（用于密碼登錄）
• 性別（翻出這張圖，我才想起來原本還有這個，著實多余）

眼尖的同學可能已經發現，這套注冊流程存在的最大漏洞即：未鑒別用戶手機號/郵箱的真偽性。因此，在這段時間里，使平臺產生了大量的一個用戶多賬號的問題，任意注冊的賬號甚至會影響真實的手機號、郵箱使用者注冊（因為賬號不能重復注冊）。

唯品會APP注冊 2.0

更新版流程（APP 5.1之后的版本）：注冊僅支持手機號注冊，去除郵箱注冊。注冊時，需校驗手機號的真實性（通過短信驗證碼），并設置密碼；注冊成功后，會將手機號同時設為賬號名和綁定手機號。

更新后的注冊賬號會包含的信息：

• 賬號名（形式為手機號，不可更改。與密碼配合，可用于登錄；也可以用于找回密碼）
• 密碼（用于登錄）
• 綁定手機（可修改。作為身份驗證的一種方式，用于提現、支付、登錄保護、忘記密碼等環節）

這套注冊流程修復了原流程存在的手機號真偽鑒別問題。但是，隨著唯品會賬號突破9位數，一個小概率事件發生的頻率提升了：手機號易主問題。

手機號易主是一個常見的生活場景。

手機號與人的關系是不穩定的，同一個手機號可能會換主人（運營商回收后重新派號），換號的原因有很多：上大學去了異地；因為聯通的3G流量很便宜，棄了移動；跟女友手機號運營商不同，用不了短號，話費成本高等等。但是賬號與人的關系是基本固定的（換了手機號，你會換銀行卡號嗎）。

而上述的兩種唯品會新舊注冊流程，產生的賬戶信息中，賬號名都是不可修改的。也就意味著：

手機號的舊主人，如果使用手機號156注冊了唯品會賬號（新流程），賬號名是手機號156，綁定手機是手機號156。這樣，用戶去操作密碼登錄、忘記密碼等流程時，仍需記憶舊手機號156。

而對于同一手機號的新主人。無法使用手機號A進行注冊，如果誤入忘記密碼流程，可能會進入找回其他人的賬號的流程。

唯品會APP注冊 3.0

當用戶基數小的時候，這個問題可能不明顯，但到達比較大的體量時（唯品會注冊賬號已達九位數），這個問題就慢慢凸顯出來了，會經常收到用戶的投訴。所以，該如何調整呢？簡單的思路如下：

目標1：解決已注冊用戶變更賬戶信息（手機號）的需求：

1、支持已注冊賬號的用戶修改登錄名（清理登錄名為手機號的賬號）

2、為了加強1的效果，可以采取一些運營引導措施，修改登錄名可領券之類的；

3、修改綁定手機流程，增加身份校驗的方式，比如：輸入綁定的銀行卡號、識別收藏過的商品等（目前線上的“修改綁定手機”需校驗用戶舊手機號后，方可綁定新手機號，與用戶使用場景脫節——舊手機號都不在我手上了怎么收短信？）；

（終于可以改手機號啦）

目標2：不繼續生成賬號名是手機號的賬號（不然目標1在填坑的時候，注冊流程在挖坑）

注冊流程，增加賬號名設置，需用主動設置一個賬號名。（業內也有自動生成的，各有利弊。從長遠角度來講，主動設置的用戶容易記??；短期利益來講，自動生成注冊轉化率會高一些）。手機號僅設為賬號的綁定手機。

（堵住水龍頭）

目標3：經過修改賬號名的賬號，或注冊主動設置賬號名的賬號，仍需支持其便捷地操作登錄、找回密碼

1、密碼登錄。在支持賬號名+密碼登錄的前提下，需支持綁定手機號+密碼登錄。

2、忘記密碼。在支持輸入賬號名找回的前提下，需支持輸入綁定手機號找回。

（“我只記得自己的手機號，該怎么登錄T.T”）

然而在具體的執行上，由于涉及改動的范圍比較大，為降低項目風險，宜拆分。目標3所述的內容應該先做（為啥捏？），做完后，目標1和目標2的順序沒有太大關系，因為互不影響，而且基本上都同等重要。

這也是近期重點在做的產品優化思路。涉及到賬戶體系整體各流程的微調。這也是前面提到過的——為什么注冊流程會直接或間接影響賬戶體系的其他流程的設計。預計會在接下來的APP版本會陸續上線，屆時可以供各位提前體驗一下。

哦，對了。

即使支持了賬號名可修改，如果手機號舊主人不去改賬號名和綁定手機，手機號易主造成的問題場景依然很多。在業內，據我了解，這個問題還沒有一個非常好的解決辦法（也可能因為我是井底之蛙哈）。如果各位有什么好主意也可以提出來?？奢o助的操作是進行一些運營手段，通過利益誘導用戶去完成修改（改賬號名派券呀什么的），或者客服肉身上陣，但并不能從根本上解決問題（僵尸用戶長時間不回訪你怎么辦）。

聯登注冊好像也很流行

除了常規的手機號注冊，業內比較常用注冊方式的還有聯登。（截圖手機京東APP）

而為了操作便捷，業內的聯登流程設計，比較常見的是一鍵聯登（OAuth 2.0 第三方授權、自動創建賬號）。而這種注冊方式產生的賬號明顯存在缺陷，屬于三無賬號：無用戶可辨識的賬號名、無密碼、無綁定手機號。這種注冊方式不但在商業合作上存在風險（如騰訊入主京東后，京東不再支持微博聯登）、加深一個人多賬號的問題，你也可以腦補一下這種賬號在其余的賬戶體系流程應該怎么走下去。。(╯‵□′)╯︵┻━┻p

所以，為了平臺的長遠發展，建議首次聯登流程，都應讓用戶進行一次選擇：登錄綁定已有的賬號，或注冊一個新賬號，完善賬號的必要信息。

總結一下

如果你想設計一個不好的注冊流程，應該：

• 不校驗手機號/郵箱的真偽；
• 將賬號名固定為手機號，不可修改；
• 第三方聯登，自動注冊，無需補充必要的賬號信息（賬號名、手機號、密碼）。

Well done！

而所謂賬戶體系的一些分支流程：”完善賬號信息“、”設置綁定手機“等等，都是在為上述注冊流程產生的缺陷賬號補坑。上面的問題看上去很簡單，但如果在初始設計時能避免，可以少走些彎路。

此篇內容偏向“術”，如有不足支持請多多指點。日后會盡量向“道”的方向深耕。共勉之。

（本文若未經作者本人授權，不允許轉載。部分圖片來自于百度搜索結果，并非原創。我搜了一下，說“侵刪”其實并沒什么卵用。）

作者：Joao_Zhang。微信公眾號：PathsVIVI

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