文章篇幅較長，奉上本文導圖。（如下，點擊可查看大圖）

一、賬號體系的概念及價值

賬號體系是用戶在各平臺上的通行證。

平臺給與用戶可持續(xù)的服務，用戶在平臺上獲取價值，中間的媒介，便是賬號體系。

阿境將其理解為維系用戶與平臺之間的樞紐。

注：本文中，賬號=賬戶，二者概念一致。

我們都知道，產品的最終服務方是“人”，那么，人拿什么來證明，我是這個產品的服務對象呢？可以想象一下，我們去銀行的時候，銀行讓我們開“戶”，提供了身份證，辦了銀行卡，卡號為6367********6318，那么，銀行卡便是我們的賬戶；我們去屈臣氏的時候，結賬時讓我們辦個卡，提供了手機號，辦了會員卡，卡號為QCS3***3，那么，會員卡便是我們的賬戶。

在這兩個例子當中，身份證跟手機號都是我們在這個世上唯一的標識，可以作為注冊賬號的憑據(jù)。而我們提供了個人的唯一識別碼（例如身份證、手機號等）后，不同的平臺，將其轉換為平臺用戶唯一的標識碼（例如上文提到的銀行卡號及會員卡號等）。

那么，有了賬戶，我們便可憑借著“通行證”在平臺上獲取服務。

賬號體系存在的價值在于：

• 提升系統(tǒng)的持續(xù)迭代能力，為后期產品擴張預先鋪墊；

• 加強賬戶相關功能模塊的可行性，保證系統(tǒng)的穩(wěn)定性；

• 賬戶融合能力提升，產品生態(tài)圈布局一站式賬戶通行證；

并且，隨著產品周期的逐步遞進，賬號體系的長尾價值會日益明顯。

二、賬號體系的需求分析

賬號體系在對于用戶與平臺的意義在于，保障用戶使用產品服務，產品提供個性化服務，同時滿足企業(yè)的商業(yè)需求。

那么，賬號體系的需求點在于何處？

①用戶的信息可被證實（如郵箱確認，手機驗證碼確認等），保障用戶的真實性。

②一個人有多個手機、多個郵箱、多個第三方賬號，但其擁有者均為同一個人，需要將其合并為同一個賬號，即保障用戶的唯一性。

③用戶手機可能更換，存在手機號被注冊情況，需解綁舊手機號同時綁定新手機號，即保障用戶賬號的賬戶安全性。

④用戶進行交易服務時，采取的保障措施，即保障用戶的資金安全性。

⑤用戶采用第三方登錄時，同時搭建自身的賬號體系。

......

以需求的強弱來說，賬號體系又可分為強需求和弱需求。

賬號體系在對于社交類、互動類的產品來說，是重中之重，為強需求。賬號體系是一切產品功能的基石，這類型產品，大多需要互動，建立用戶數(shù)據(jù)等，那么就需要賬號體系的搭建及維系。在這當中，賬號體系展現(xiàn)的是核心價值，通過記錄用戶自身各類數(shù)據(jù)，將用戶利益關聯(lián)在其賬號下，提供可持續(xù)的服務。

而對于工具類的產品，賬號體系相對來說則是弱需求，無賬號體系也可正常運作及使用，但有了賬號體系，可更加精準的進行后續(xù)的用戶畫像建立，前期可能不重要，后續(xù)在進行更多版本迭代的時候，便可能派上用場。在這當中，賬號體系展現(xiàn)的是擴展價值及商業(yè)價值，通過沉淀的用戶數(shù)據(jù)，提供個性化服務，更高效的滿足用戶需求，提升用戶體驗。

總的來說，賬號體系是為了解決用戶信息唯一性、真實性、安全性的問題，于所有產品而言，賬號體系并不是必備的，其搭建時間可在產品規(guī)劃前期也可在產品規(guī)劃后期，取決于產品類型。

三、賬號體系的類別及歷史淵源

賬號體系分為多種，從互聯(lián)網(wǎng)發(fā)展至今，可歸納為四種，自定義賬號、郵箱賬號、手機號賬號、第三方登錄賬號。

1、自定義賬號

自定義賬號為“賬號+密碼”的形式，一般賬號為用戶自行定義，是比較久遠的的賬號體系。在互聯(lián)網(wǎng)野蠻生長的前期，各大平臺尚未建立，且智能手機還未出世，使用平臺均為PC端，則賬號需用戶自行擬定。

缺點的話，相信經歷過的伙伴記憶尤深，經常拿著個小本子記錄著不同的賬號密碼。QQ一個，某游戲平臺一個，某社交平臺一個......若設置得不同，則增加了用戶的記憶負擔。

放在互聯(lián)網(wǎng)發(fā)展初期，則較為適用，而對于現(xiàn)在如此多的平臺，“賬號+密碼”的方式已經開始慢慢逐步被替代。

2、郵箱賬號

在互聯(lián)網(wǎng)蠻荒時代的過去，為了解決“降低用戶記憶負擔”的問題，適逢各類郵箱盛行，QQ郵箱、網(wǎng)易郵箱、新浪郵箱等各大巨頭爭相搶占市場，郵箱已成為當時用戶的常用工具，記憶難度遠比隨意取得賬號名更為簡單，所以被用以“郵箱號+密碼”的登錄方式。

而郵箱作為注冊方式，優(yōu)點是像對于自定義賬號的體系，郵箱更能夠降低用戶記憶負擔，缺點也很明顯，郵箱的認證環(huán)節(jié)較為冗長，需要打開郵箱接收郵件并確認，容易在這個過程當中流失用戶。

且在以往，PC端占據(jù)主導，如今，移動端占領大半江山，大多數(shù)用戶不會在手機上安裝一個郵箱應用，那么，在移動端接收郵箱驗證信息的時候，難度增加，流失率也會增多。

所以對于目前移動端主導市場的情況來說，”郵箱+密碼“的賬號體系，也已經開始慢慢地淡出人們視野。

3、手機號賬號體系

據(jù)數(shù)據(jù)資料顯示，截止2018年，智能手機的市場份額占據(jù)比已經達到98.6%，那么，可以說基本人手一機。

每個人可能沒有社交賬號（微信、QQ等），但一定會有手機號。

優(yōu)點的話，對于用戶來說，記住賬號可能困難，但記住自身的手機號較為簡單，且安全性高；對于平臺來說，利利用手機號登錄，可以搭建起自身的賬號體系，便于后續(xù)的精細化運營（活動通知，用戶召回等等）；由于目前手機號都是運營商實名，可減少垃圾營銷號的賬號。

缺點的話，其一，“手機號+驗證碼”登錄需要支付一定的短信費用，好在價格不多，但需要防范黑客的惡意攻擊，這里也涉及到賬號體系的風控機制，后續(xù)會談到；其二，在信號差的地方，接收不到驗證碼；其三，手機號存在換號情況，需要考慮解綁邏輯及換號邏輯。

注意點：手機號賬號體系的便捷點在于，可將注冊與登錄流程合為一體，若未注冊，則在獲取驗證碼后登錄的同時，系統(tǒng)自動幫用戶注冊，減少了用戶的操作成本，提高便捷性。

但同時，由于其便捷性，也有其局限性，用戶可能變更手機號，所以需要在用手機號注冊之后，引導用戶設置密碼，減少風險。

4、第三方賬號體系

隨著各大超級APP的誕生及趨于成熟，衍生出了“第三方登錄”的這個概念。

第三方賬號體系是指用戶通過授權，將第三方資料綁定到自身賬號體系上。當查詢到用戶第三方的帳號已經綁定了平臺的某個user_id時，直接登錄對應的帳號，實現(xiàn)一鍵注冊與一鍵登錄。

優(yōu)點的話，對于用戶來說，授權方便，當擁有主流社交賬號（如微信、QQ、微博等），即可一鍵注冊及一鍵登錄，無需浪費太多時間。且可獲取第三方平臺的一些基礎資料，填充了賬號前期的空白（例如頭像、昵稱等）

缺點的話，主要針對于平臺，無法形成自身的賬號體系，依托于第三方，有一定的風險（第三方倒閉之類的），但可通過后續(xù)進入到平臺，引導綁定手機號等操作來彌補。

考慮采用第三方登錄，還需要考慮到，立即綁定與延時綁定這兩種情況。通常在第三方授權后，系統(tǒng)僅能拿到頭像昵稱等部分信息，若考慮后續(xù)自身的賬號信息，那么需要要求用戶進行綁定相應信息，則便涉及到立即綁定與延時綁定。

立即綁定會使得用戶操作繁瑣，容易造成流失，但能保證獲取用戶的信息。

延時綁定可保證用戶體驗，但卻容易在使用過程中，用戶填寫信息時，被拒絕。

至于采用哪種方式，就需要各位產品朋友在實際的產品設計當中進行取舍。

“魚與熊掌不可兼得”

四、如何設計賬號體系？

1、賬號體系的字段

要設計一個賬號體系，那么需要先了解，賬號體系包括哪些基礎字段。

• 用戶賬號（User Account，包括自定義、郵箱、手機號）

用戶賬號（User Account）為系統(tǒng)平臺內唯一的標識，不同的賬號體系類型，用戶賬號的展現(xiàn)形式也不同。

包括自定義賬號，郵箱號，手機號三種類型。

自定義賬號的，則用戶賬號由數(shù)字+字母或者中文組成。

郵箱的話，則為郵箱號，數(shù)字+英文組成。

手機號，則由11位數(shù)字組成。

通常處于隱私性及安全性的層面考慮，用戶賬號僅對個人可見，其余人不可見，是用戶個人的通行證。

• 用戶密碼（User Password）

用戶密碼（User Password）是基于“賬號+密碼”體系類的字段。

一般由字母跟數(shù)字組成，部分密碼會設置成包含符號。

這邊產品同學在設計的時候需要考慮“字母+數(shù)字”跟“字母+數(shù)字+符號”的不同情況。

• 用戶名稱（UserName）

用戶名稱（UserName）為用戶對外展示的名字標識。可以是用戶自定義，也可以是系統(tǒng)先自行分配設置，后續(xù)提供修改的權限，若是采用第三方授權登錄，則一般會以第三方的昵稱作為用戶名稱，后續(xù)可修改。

具體為用戶自定義還是系統(tǒng)分配，下文設計的時候會具體說明。

• 用戶唯一標識（UserID，簡稱UID）

用戶唯一標識（UID）為系統(tǒng)配置，一般為數(shù)字組成，不對用戶可見。用戶在注冊為系統(tǒng)的賬號后，則自動生成，不可更改，與每個用戶一一對應。

• 開放賬戶（OpenID）

借助第三方網(wǎng)站url驗證用戶身份，當用戶第三方授權登錄成功，系統(tǒng)通過獲取用戶的open ID生成user ID,同時也讀取用戶在第三方網(wǎng)站的身份昵稱以及頭像，該昵稱可作為首次的賬號名。

在技術層面上，OpenID也分為靜默授權與用戶授權，這點有興趣的朋友可以去了解下。

上圖賬號體系的信息框架圖。（源于網(wǎng)絡）

2、賬號體系的核心流程

賬號體系包含四個核心流程，分別為注冊流程、登錄流程、找回密碼流程、風控流程；

其中，注冊流程與登錄流程可合并為一起。

注冊+登錄流程

要設計一個登錄注冊流程，那么我們需要先簡單的進行該流程的具體分析。

賬號的注冊登陸流程，遵循三個原則，①安全性 ②普適性 ③便捷性。

簡單來說，登陸注冊流程，安全第一是前提，其次保證普適性的同時，追求便捷性。

那么，根據(jù)KANO模型來看，安全性為基本型需求，普適性為期望型需求，便捷性為興奮性需求。

上文提到，注冊登錄的幾個組合方式，賬號+密碼、郵箱+密碼、手機號+驗證碼、手機號+密碼+驗證碼、第三方登錄、第三方登陸+手機號綁定、第三方登錄+密碼、第三方登錄+密碼+手機號綁定.......

組合方式多樣，并不必刻意去記，遵循主流綁定方式的同時，綁定的信息（手機號、微信等）越多，于平臺來說風險越低，于用戶來說，安全性越高，但同時也會增加用戶操作成本。如何設計，取決于平臺的現(xiàn)狀及自身定位，不同產品，不同設計方法，并不能一概而論。

針對于安全性來說，綁定的方式越多，越安全；針對于便捷性來說，前期門檻可設置簡單的注冊登錄（例如市面上的“閃驗”登錄），后續(xù)再進行資料補充。

這邊有一個注意點，注意《用戶協(xié)議》的規(guī)劃設計。

《用戶協(xié)議》是制約用戶濫用違法的手段干擾系統(tǒng)運行的手段，是注冊流程中不可缺少的部分，卻也是最容易忽略的部分。

有幾種方式可以設計，僅供參考。

• 展示可供勾選的用戶協(xié)議，根據(jù)產品的業(yè)務形態(tài)可以選擇是否默認勾選的方式。

• 注冊時，強制彈出，用戶需先同意后才進行后續(xù)操作。避免了后續(xù)因不同意浪費的時間。

• 注冊即表示同意用戶協(xié)議。
  

找回密碼流程

常見的幾種找回密碼的方式：手機號、郵箱、銀行卡、人工申訴。

①手機號驗證

若密碼丟失，則可通過“原手機+驗證碼”的形式來進行重設密碼，但會有運營商二次放號的情況，那么需要在系統(tǒng)設計中規(guī)劃多個“受信任手機”或“受信任設備”的情況。

②郵箱找回

郵箱找回的方法是以往PC端的經典方法，PC時代=郵箱時代。QQ、網(wǎng)易等主流郵箱占據(jù)了整個市場，自然通過郵箱找回最為方便。但隨著移動時代的到來，郵箱找回的方式逐漸被遺棄，且在賬號體系若無通過郵箱為主的賬號方式，則一般也很少會在體系當中要求用戶綁定郵箱。

在移動時代，郵箱找回較為麻煩且用處不大，但可作為手機號找回的輔助方式。

③驗證銀行卡

若在體系當中涉及到銀行卡綁定的，則銀行卡可作為個人的唯一標識，通過“銀行卡+預留手機號+驗證碼”的驗證方式來驗證個人信息，從而明確是否本人的方式，來找回密碼。

④人工服務

在各類驗證方式都走不通的情況下，只能通過人工服務來進行找回密碼。需要先讓用戶上傳身份證等個人確切信息之后，客服在一定的工作日內進行處理，會耗費相應的客服資源，且反饋時間較長。

風控流程

風控流程的本質在于確保用戶身份的合法性及正確性。防止部分不法分子惡意攻擊及注冊，影響原本體系的安全。

賬號作為用戶登錄系統(tǒng)的“通行證”，其重要性不言而喻。而保護好賬號的安全，也是至關重要的。其在于注冊、登錄流程上，被黑客惡意注冊，導致平臺資源浪費；賬號信息泄露，導致用戶信息受損；不論是對于平臺還是對于用戶，都是極大的損失。

對于風控措施，可從惡意注冊賬號、IP、盜取等方向來思考。

阿境列舉了以下幾項針對于賬號體系的風控措施，可供參考。

針對于惡意注冊賬號，浪費平臺資源

• 禁止非正常的、大量的“驗證賬號是否存在”的操作請求，防止不法份子通過不停的輸入大量賬號，去獲取該賬號是否存在的數(shù)據(jù)。

• 郵箱注冊時增加郵件驗證碼功能或者通過郵件進行激活確認。
  

• 通過短信驗證時，進行短信次數(shù)限制，保護短信通道不被惡意者大量刷短信，造成堵塞。
  

• 驗證方式升級，通過圖像驗證碼、文字驗證碼甚至題目驗證碼等，加大驗證難度。
  

• 唯一手機號，保證一機一號。
  

• 通過IP對請求上限做出限制，防止惡意用戶大量發(fā)起注冊請求，攻擊服務器。若多次請求，數(shù)據(jù)錯誤，則對賬號進行梯度時間凍結。
  

針對于盜取賬號，影響賬號安全性

• 確保用戶訪問的真實性，進行手機號驗證或手機掃碼登錄。

• 異常操作，非本人IP/手機進行通知提醒。
  

• 高風險的賬號操作，系統(tǒng)后臺運行后，重新進入，需要重新輸入驗證信息（指紋、手勢等），常用在支付類系統(tǒng)。
  

3、賬號體系的頁面展示

頁面僅為部分邏輯展示，目前發(fā)展到了現(xiàn)在，登錄注冊的頁面展現(xiàn)形式各異，依據(jù)系統(tǒng)的定位來規(guī)劃及設計即可。

五、賬號體系的合并與打通

在各大系統(tǒng)中，存在多個系統(tǒng)，多個賬號，互相交雜的情況，那么，延伸出了賬號的合并問題與打通問題。

同個系統(tǒng)中，存在的問題是合并問題

• 同類型的賬號合并

• 不同類型的賬號合并

不同系統(tǒng)中，存在的問題是打通問題

• 單向數(shù)據(jù)打通  

• 雙向數(shù)據(jù)打通

1、賬號體系的合并

賬號的合并指的是，在一個系統(tǒng)內，一個用戶的多個賬號合并成為同一個賬號。

賬號分為同類型與不同類型兩種。同類型指的是注冊類型相同，例如同一個人用兩個手機號注冊兩個賬號；不同類型指的是注冊類型不同，例如有手機號注冊，有微信注冊，有郵箱注冊，但其擁有者均為同一個人。

那么此時，用戶發(fā)起合并，將其所擁有的賬號合并為同一個。

處理方式為：保留其中一個主賬號，將數(shù)據(jù)累加到主賬號當中，其余賬號數(shù)據(jù)清空。

2、賬號體系的打通

賬號的打通指的是，在不同的系統(tǒng)，賬號數(shù)據(jù)的互通。在這當中，“互通”又分為單向打通與雙向打通。

單向打通指的是一個系統(tǒng)有權使用另外一個系統(tǒng)的部分數(shù)據(jù)。這里的“有權使用”我們可以理解為“授權”。

第三方授權便是這個原理，某APP授權微信，則由于微信的開放平臺數(shù)據(jù)，某APP可獲取其名稱頭像等數(shù)據(jù)，進而采用這些數(shù)據(jù)在系統(tǒng)中流轉。

雙向打通指的是兩個不同的系統(tǒng)，數(shù)據(jù)相通，多用于合作模式的系統(tǒng)，情況不多。

例如A與B兩個系統(tǒng)，部分數(shù)據(jù)是公用的，那么，在A系統(tǒng)中修改了個人信息，在B系統(tǒng)中的個人信息也隨之修改，共用的是同一套數(shù)據(jù)。

這當中的核心為數(shù)據(jù)流通，一個用戶在多個系統(tǒng)內，局部數(shù)據(jù)流通（單向或雙向），數(shù)據(jù)總量不變。

六、賬號體系設計的幾個要點

（劃重點，這個要考）

1、搭建適合自身產品的賬號體系

選擇賬號體系基于四個維度來判定，分別是

①終端類型  ②產品類型  ③用戶類型  ④產品發(fā)展  四個方面。

（1）終端類型

目前對于終端，分別是PC端與移動端。對于以往PC端時代來說，郵箱是最盛行的，隨手打開郵箱即可接收驗證信息，拿到現(xiàn)在移動時代，如此操作便略顯繁瑣了。

（2）產品類型

不同的產品類型，由于其本身性質的不同，應設計不同的賬號體系。

設計的核心在于盡量靠近產品主流業(yè)務所使用的信息，來設計賬號體系。

例如，打車平臺、外賣平臺是必須要知道用戶手機號的，那么可直接采用手機號登錄的方式來設計賬戶體系。

（3）用戶類型

用戶類型的不同，也需要考慮不同的賬號體系。

拿三類用戶來舉個例子，學生、年輕人、老年人。

對于學生來說，考慮到部分學生是沒有手機號的，則若僅限制用手機號注冊，便會流失這部分的用戶，而QQ幾乎是人手一個，那么采用第三方登錄是最合適的方法。

對于年輕人來說，手機號、各類主流第三方賬戶，郵箱均有，那么設計最適合的登錄方式即可。

對于老年人來說，賬號密碼的登錄體系由于其復雜性，必然不適合。那么采用手機號登陸較為合適，考慮到老年人這個特殊群體，需要設計較為簡單的操作流程，可采用目前較為流行的“本機號碼一鍵登錄”的方式，將注冊登錄融為一體。

（4）產品發(fā)展

產品在前期發(fā)展的時候，需要快速占領市場，時間緊任務重，那么可直接采用接入第三方登錄的方式。在發(fā)展到一定體量的時候，那么便有必要構建一套自己的賬戶體系了。

2、根據(jù)產品類型設定賬號是否強制登錄

（1）先瀏覽再登錄

若是內容類、資訊類的產品，為了用戶體驗，一般不強制登錄，采用先瀏覽再登錄的方式。將登錄后置的一個重要原因在于留住用戶。根據(jù)漏斗模型可知，用戶操作步驟越多，流失越多。且降低瀏覽的門檻，能夠吸引用戶查看內容，當需要使用到賬號信息時（例如購買），再引導用戶去進行注冊登錄的操作。

那么，這么設計的缺點在于①注冊入口多，系統(tǒng)維護成本高  ②用戶信息需要分多環(huán)節(jié)設計。

（2）先登錄再瀏覽

若是社交類的產品，則一般采用先登錄再瀏覽的方式。其原因在于，針對于社交，賬號是唯一主體，且需要通過賬號來進行后續(xù)的操作，無法跳過注冊登錄的流程。

但是，部分內容類的產品這么設計，容易造成用戶流失。

（3）無需注冊登錄

若是工具類的產品，則賬號體系作為弱需求的存在，可有可無，在資源有限的情況下，可不做賬號體系，直接使用產品，便也無需注冊登錄。當然，上文有提到，針對于工具類的產品，賬號體系的意義在于后續(xù)的擴展價值及商業(yè)價值。

3、考慮賬號體系的安全機制（二次放號的情況）

上文提到，目前我們主流的賬號體系注冊方式，主要為①手機號賬號體系 ②第三方賬號體系。

那么，而以手機號作為核心的賬號體系，卻會延伸出不同的問題。

手機號更換且停用的情況，導致舊手機號丟失，運營商會有將廢棄的手機號二次回收再發(fā)放的情況。

舉個例子：號稱廈門吳彥祖的阿境先前用舊的號碼注冊了某健身平臺。有一天，他換了新的手機號，那么舊的號碼便注銷掉，運營商過了一段時間（大約四個月）重新將其投放入市場。

那么這個時候，便會遇到，有人拿這個舊的手機號進入這個健身平臺，篡改了阿境的賬號信息。

那么，如何避免這個問題呢？

本質在于，通過身份驗證來確保是用戶本人操作。

（1）好友輔助驗證

社交類產品多采用該方式，如QQ和微信，通過線下聯(lián)系好友，好友在號上進行確認操作，多位好友進行驗證之后，便通過。

安全性較高，但換來的也是操作復雜麻煩的代價，多用于社交類產品。

（2）歷史信息驗證

通過用戶自身回憶歷史的操作信息及個人信息，并回答相應問題，正確后即可通過驗證。

例如：“近期的購物產品是什么”“曾經用過什么密碼”“回憶一下最近的好友”“回憶一下近期使用過的頭像”等等

但當平臺逐漸增多，數(shù)據(jù)不斷交替更新的現(xiàn)在，歷史信息驗證這個方法的準確度逐漸下降，要讓用戶記住曾經設置的某些信息，越來越難，體驗遠沒有想象中的好。

（3）用戶身份驗證

倘若用戶在系統(tǒng)中留下了自身的信息，唯一且安全，那么，該信息便可用于自身的信息驗證。

例如人臉識別，身份證，銀行卡，社?？ǖ刃畔?。

（4）通過已添加的其他“受信任的手機號/設備”通過驗證

部分平臺在系統(tǒng)內，會增設多個“受信任手機號”的功能，添加多個手機號，當主手機號丟失的時候，可通過其余手機號發(fā)送短信的信息驗證，來驗證用戶自身的身份。

也可添加多個“受信任的設備”來認證登錄，此后，受信任的設備可將陌生設備踢下線。

（5）密保問題認證/郵箱認證

通過密保問題驗證及郵箱驗證，是互聯(lián)網(wǎng)早期PC時代時慣用的方式，通過“賬號密碼”的賬號體系，附帶設置密保問題的安全措施，保證用戶的賬號安全。

這個方式最大的問題便是密保問題的記憶，往往很多人還是會忘記。舉個例子，如今蘋果賬號依然是使用密保問題，如若無刻意去記憶，那么我想大部分人還是容易遺忘。

（6）客服申述等

在所有自身提交信息并認證的措施都嘗試之后，若還不行，那么只能通過客服申訴來找回賬號。

通過讓用戶填寫證明賬號信息的表單，提交客服，從而來人工判定賬號的歸屬人。

但此法容易占用客服資源，且費時費力，是下下之策。

4、一些能夠提升用戶體驗的設計

（1）手機號注冊，帶空格

在注冊登錄或綁定手機號等兩個流程，需輸入手機號的時候，自動為用戶空出空位出來，以3-4-4的方式，用戶在輸入的過程中隨時可更加方便校準所輸入的內容及位數(shù)是否正確。

在用戶需要輸入銀行卡的信息時，同理，以4-4-4-4-3的方式來設計。

（2）精準的錯誤提示

在賬號的表單輸入框中，若信息輸入錯誤，則需以精確的錯誤提示反饋給用戶。

舉個例子，在用戶輸入賬號密碼后，若信息不正確，則有兩種處理方式：①信息錯誤  ②賬號不存在/密碼錯誤。

很顯然，第二種處理方式會比第一種好得多，用戶可以清晰的知道自身的錯誤并修正，減少了多次嘗試的時間。

同時，根據(jù)泰斯勒定律“越簡單的前端使用，那么背后一定有復雜的邏輯支撐”，用戶獲得的錯誤提示越精準，則開發(fā)資源及時間需要付出的越多。

若產品前期急著開發(fā)上線，可犧牲部分交互及用戶體驗，優(yōu)先級排后，待穩(wěn)定后再做修改。

（3）輸入數(shù)字的時候，自動調起數(shù)字鍵盤

在輸入密碼的時候，若密碼要求純數(shù)字，則自動調起數(shù)字鍵盤，且強制不可轉換，以避免用戶誤操作輸入錯誤信息，增加不必要的用戶操作。

（4）有前置條件的按鈕可置灰，輸入信息后恢復可點擊狀態(tài)

若信息未達到系統(tǒng)要求信息，則按鈕置灰，減少不必要的點擊。

舉個例子，登錄時，需要輸入賬號與密碼，若用戶僅輸入賬號或密碼時，按鈕保持置灰狀態(tài)。當賬號及密碼均輸入且達到要求（例如6到16位），按鈕回復可點擊狀態(tài)。

（5）密碼提供顯示/隱藏按鈕

輸入安全性較高的信息時，給予用戶顯示/隱藏按鈕。

例如在輸入密碼時，用戶旁邊若有人，則輸入密碼的步驟的隱私性降低，提供顯示/隱藏按鈕，可讓用戶自行選擇是否顯示正在輸入的信息。

（6）必填與非必填項的提示

用戶首次注冊賬號登錄時，部分系統(tǒng)出于做前期用戶推薦的目的，要求用戶輸入部分信息，則信息作為表單，進行必填與非必填的提示，例如可使用*號作為區(qū)分。將操作的可控性前置到用戶輸入信息的時候。

寫在最后

賬號體系可大可小，一個看似小的功能點可以延伸出很多細微的知識。

重點在于產品的體量大小，是否值得如此深度的來設計。

剛開始的產品，賬號體系的作用可能僅限于可注冊登陸，且用戶量也少，那么并不怎么需要考慮風控及安全機制。而將自身主體業(yè)務做精做全之后，再來完善賬號體系也不遲，畢竟賬號體系說來也是一個龐大的工程量。

想必PM若沒有足夠的洞察力及充分模擬業(yè)務場景，也不一定能完全做好賬號體系（不僅僅在于搭建，還在于各類風控措施及安全機制）。

阿境在開始寫這篇文章的時候，從第一個字到現(xiàn)在，遠遠超過了預估的時間。

構思的時候，內心：“賬號體系這么多，歸納一下吧，也不難?！?/p>

剛開始寫的時候，內心：”還行，有點感覺。“

寫到一半，內心：“怎么好像有點難。”

寫到快結尾，內心：“天吶好難，寫完我要放棄產品這條路了！”

（開個玩笑）

原計劃三千字講清楚，現(xiàn)在磨磨蹭蹭到了小一萬。（也可能大部分都是因為我啰嗦 哈哈哈）

“切莫小看每一個看似細小的功能點”

永存敬畏之心是每一名PM都應該擁有的。

你好，我是阿境，見字如面。

野蠻生長，產品汪一枚，做過電商、醫(yī)療、教育行業(yè)項目。有百萬級流水產品經驗。

堅信"產品源于生活"，歡迎交流。

定律？模型？看這一篇就夠了（上）

定律？模型？看這一篇就夠了（下）

如何用PM的思維把妞/泡仔