起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識一文帶你讀懂賬號體系
經手過諸多項目，行業各異，類型各異，但卻有個共同點：均涉及到賬號體系，看似不難，但深究起來，卻也值得思考，細細品味。于是乎，便有了這篇文章。這次將從里到外仔細剖析，從概念類別到設計方法，來講講關于賬號體系的那些事。
文章篇幅較長，奉上本文導圖。（如下，點擊可查看大圖）
一、賬號體系的概念及價值
賬號體系是用戶在各平臺上的通行證。
平臺給與用戶可持續的服務，用戶在平臺上獲取價值，中間的媒介，便是賬號體系。
阿境將其理解為維系用戶與平臺之間的樞紐。
注：本文中，賬號=賬戶，二者概念一致。
我們都知道，產品的最終服務方是“人”，那么，人拿什么來證明，我是這個產品的服務對象呢？
可以想象一下，我們去銀行的時候，銀行讓我們開“戶”，提供了身份證，辦了銀行卡，卡號為6367********6318，那么，銀行卡便是我們的賬戶；我們去屈臣氏的時候，結賬時讓我們辦個卡，提供了手機號，辦了會員卡，卡號為QCS3***3，那么，會員卡便是我們的賬戶。
在這兩個例子當中，身份證跟手機號都是我們在這個世上唯一的標識，可以作為注冊賬號的憑據。而我們提供了個人的唯一識別碼（例如身份證、手機號等）后，不同的平臺，將其轉換為平臺用戶唯一的標識碼（例如上文提到的銀行卡號及會員卡號等）。
那么，有了賬戶，我們便可憑借著“通行證”在平臺上獲取服務。
賬號體系存在的價值在于：
- 提升系統的持續迭代能力，為后期產品擴張預先鋪墊；
- 加強賬戶相關功能模塊的可行性，保證系統的穩定性；
- 賬戶融合能力提升，產品生態圈布局一站式賬戶通行證。
并且，隨著產品周期的逐步遞進，賬號體系的長尾價值會日益明顯。
二、賬號體系的需求分析
賬號體系在對于用戶與平臺的意義在于，保障用戶使用產品服務，產品提供個性化服務，同時滿足企業的商業需求。
那么，賬號體系的需求點在于何處？
- 用戶的信息可被證實（如郵箱確認，手機驗證碼確認等），保障用戶的真實性。
- 一個人有多個手機、多個郵箱、多個第三方賬號，但其擁有者均為同一個人，需要將其合并為同一個賬號，即保障用戶的唯一性。
- 用戶手機可能更換，存在手機號被注冊情況，需解綁舊手機號同時綁定新手機號，即保障用戶賬號的賬戶安全性。
- 用戶進行交易服務時，采取的保障措施，即保障用戶的資金安全性。
- 用戶采用第三方登錄時，同時搭建自身的賬號體系。
- ……
以需求的強弱來說，賬號體系又可分為強需求和弱需求。
賬號體系在對于社交類、互動類的產品來說，是重中之重，為強需求。賬號體系是一切產品功能的基石，這類型產品，大多需要互動，建立用戶數據等，那么就需要賬號體系的搭建及維系。在這當中，賬號體系展現的是核心價值，通過記錄用戶自身各類數據，將用戶利益關聯在其賬號下，提供可持續的服務。
而對于工具類的產品，賬號體系相對來說則是弱需求，無賬號體系也可正常運作及使用，但有了賬號體系，可更加精準的進行后續的用戶畫像建立，前期可能不重要，后續在進行更多版本迭代的時候，便可能派上用場。在這當中，賬號體系展現的是擴展價值及商業價值，通過沉淀的用戶數據，提供個性化服務，更高效的滿足用戶需求，提升用戶體驗。
總的來說，賬號體系是為了解決用戶信息唯一性、真實性、安全性的問題，于所有產品而言，賬號體系并不是必備的，其搭建時間可在產品規劃前期也可在產品規劃后期，取決于產品類型。
三、賬號體系的類別及歷史淵源
賬號體系分為多種，從互聯網發展至今，可歸納為四種，自定義賬號、郵箱賬號、手機號賬號、第三方登錄賬號。
1. 自定義賬號
自定義賬號為“賬號+密碼”的形式，一般賬號為用戶自行定義，是比較久遠的的賬號體系。在互聯網野蠻生長的前期，各大平臺尚未建立，且智能手機還未出世，使用平臺均為PC端，則賬號需用戶自行擬定。
缺點的話，相信經歷過的伙伴記憶尤深，經常拿著個小本子記錄著不同的賬號密碼。QQ一個，某游戲平臺一個，某社交平臺一個……若設置得不同，則增加了用戶的記憶負擔。
放在互聯網發展初期，則較為適用，而對于現在如此多的平臺，“賬號+密碼”的方式已經開始慢慢逐步被替代。
2. 郵箱賬號
在互聯網蠻荒時代的過去，為了解決“降低用戶記憶負擔”的問題，適逢各類郵箱盛行，QQ郵箱、網易郵箱、新浪郵箱等各大巨頭爭相搶占市場，郵箱已成為當時用戶的常用工具，記憶難度遠比隨意取得賬號名更為簡單，所以被用以“郵箱號+密碼”的登錄方式。
而郵箱作為注冊方式，優點是像對于自定義賬號的體系，郵箱更能夠降低用戶記憶負擔；缺點也很明顯，郵箱的認證環節較為冗長，需要打開郵箱接收郵件并確認，容易在這個過程當中流失用戶。
且在以往，PC端占據主導，如今，移動端占領大半江山，大多數用戶不會在手機上安裝一個郵箱應用，那么，在移動端接收郵箱驗證信息的時候，難度增加，流失率也會增多。
所以對于目前移動端主導市場的情況來說，“郵箱+密碼”的賬號體系，也已經開始慢慢地淡出人們視野。
3. 手機號賬號體系
據數據資料顯示，截止2018年，智能手機的市場份額占據比已經達到98.6%，那么，可以說基本人手一機。
每個人可能沒有社交賬號（微信、QQ等），但一定會有手機號。
優點的話，對于用戶來說，記住賬號可能困難，但記住自身的手機號較為簡單，且安全性高；對于平臺來說，利利用手機號登錄，可以搭建起自身的賬號體系，便于后續的精細化運營（活動通知，用戶召回等等）；由于目前手機號都是運營商實名，可減少垃圾營銷號的賬號。
缺點的話，其一，“手機號+驗證碼”登錄需要支付一定的短信費用，好在價格不多，但需要防范黑客的惡意攻擊，這里也涉及到賬號體系的風控機制，后續會談到；其二，在信號差的地方，接收不到驗證碼；其三，手機號存在換號情況，需要考慮解綁邏輯及換號邏輯。
注意點：手機號賬號體系的便捷點在于，可將注冊與登錄流程合為一體，若未注冊，則在獲取驗證碼后登錄的同時，系統自動幫用戶注冊，減少了用戶的操作成本，提高便捷性。
但同時，由于其便捷性，也有其局限性，用戶可能變更手機號，所以需要在用手機號注冊之后，引導用戶設置密碼，減少風險。
4. 第三方賬號體系
隨著各大超級APP的誕生及趨于成熟，衍生出了“第三方登錄”的這個概念。
第三方賬號體系是指用戶通過授權，將第三方資料綁定到自身賬號體系上。當查詢到用戶第三方的帳號已經綁定了平臺的某個user_id時，直接登錄對應的帳號，實現一鍵注冊與一鍵登錄。
- 優點的話，對于用戶來說，授權方便，當擁有主流社交賬號（如微信、QQ、微博等），即可一鍵注冊及一鍵登錄，無需浪費太多時間。且可獲取第三方平臺的一些基礎資料，填充了賬號前期的空白（例如頭像、昵稱等）
- 缺點的話，主要針對于平臺，無法形成自身的賬號體系，依托于第三方，有一定的風險（第三方倒閉之類的），但可通過后續進入到平臺，引導綁定手機號等操作來彌補。
考慮采用第三方登錄，還需要考慮到，立即綁定與延時綁定這兩種情況。通常在第三方授權后，系統僅能拿到頭像昵稱等部分信息，若考慮后續自身的賬號信息，那么需要要求用戶進行綁定相應信息，則便涉及到立即綁定與延時綁定。
立即綁定會使得用戶操作繁瑣，容易造成流失，但能保證獲取用戶的信息。
延時綁定可保證用戶體驗，但卻容易在使用過程中，用戶填寫信息時，被拒絕。
至于采用哪種方式，就需要各位產品朋友在實際的產品設計當中進行取舍。
“魚與熊掌不可兼得”
四、如何設計賬號體系？
1. 賬號體系的字段
要設計一個賬號體系，那么需要先了解，賬號體系包括哪些基礎字段。
（1）用戶賬號（User Account，包括自定義、郵箱、手機號）
用戶賬號（User Account）為系統平臺內唯一的標識，不同的賬號體系類型，用戶賬號的展現形式也不同。包括自定義賬號，郵箱號，手機號三種類型。
- 自定義賬號的，則用戶賬號由數字+字母或者中文組成。
- 郵箱的話，則為郵箱號，數字+英文組成。
- 手機號，則由11位數字組成。
通常處于隱私性及安全性的層面考慮，用戶賬號僅對個人可見，其余人不可見，是用戶個人的通行證。
（2）用戶密碼（User Password）
用戶密碼（User Password）是基于“賬號+密碼”體系類的字段，一般由字母跟數字組成，部分密碼會設置成包含符號。
這邊產品同學在設計的時候需要考慮“字母+數字”跟“字母+數字+符號”的不同情況。
（3）用戶名稱（UserName）
用戶名稱（UserName）為用戶對外展示的名字標識?？梢允怯脩糇远x，也可以是系統先自行分配設置，后續提供修改的權限，若是采用第三方授權登錄，則一般會以第三方的昵稱作為用戶名稱，后續可修改。
具體為用戶自定義還是系統分配，下文設計的時候會具體說明。
（4）用戶唯一標識（UserID，簡稱UID）
用戶唯一標識（UID）為系統配置，一般為數字組成，不對用戶可見。用戶在注冊為系統的賬號后，則自動生成，不可更改，與每個用戶一一對應。
（5）開放賬戶（OpenID）
借助第三方網站url驗證用戶身份，當用戶第三方授權登錄成功，系統通過獲取用戶的open ID生成user ID,同時也讀取用戶在第三方網站的身份昵稱以及頭像，該昵稱可作為首次的賬號名。
在技術層面上，OpenID也分為靜默授權與用戶授權，這點有興趣的朋友可以去了解下。
上圖賬號體系的信息框架圖（源于網絡）
2. 賬號體系的核心流程
賬號體系包含四個核心流程，分別為注冊流程、登錄流程、找回密碼流程、風控流程。其中，注冊流程與登錄流程可合并為一起。
（1）注冊+登錄流程
要設計一個登錄注冊流程，那么我們需要先簡單的進行該流程的具體分析。
賬號的注冊登陸流程，遵循三個原則：①安全性 ②普適性 ③便捷性。
簡單來說，登陸注冊流程，安全第一是前提，其次保證普適性的同時，追求便捷性。:那么，根據KANO模型來看，安全性為基本型需求，普適性為期望型需求，便捷性為興奮性需求。
上文提到，注冊登錄的幾個組合方式，賬號+密碼、郵箱+密碼、手機號+驗證碼、手機號+密碼+驗證碼、第三方登錄、第三方登陸+手機號綁定、第三方登錄+密碼、第三方登錄+密碼+手機號綁定…….
組合方式多樣，并不必刻意去記，遵循主流綁定方式的同時，綁定的信息（手機號、微信等）越多，于平臺來說風險越低，于用戶來說，安全性越高，但同時也會增加用戶操作成本。如何設計，取決于平臺的現狀及自身定位，不同產品，不同設計方法，并不能一概而論。
針對于安全性來說，綁定的方式越多，越安全；針對于便捷性來說，前期門檻可設置簡單的注冊登錄（例如市面上的“閃驗”登錄），后續再進行資料補充。
這邊有一個注意點，注意《用戶協議》的規劃設計。
《用戶協議》是制約用戶濫用違法的手段干擾系統運行的手段，是注冊流程中不可缺少的部分，卻也是最容易忽略的部分。
有幾種方式可以設計，僅供參考：
- 展示可供勾選的用戶協議，根據產品的業務形態可以選擇是否默認勾選的方式。
- 注冊時，強制彈出，用戶需先同意后才進行后續操作，避免了后續因不同意浪費的時間。注冊即表示同意用戶協議。
（2）找回密碼流程
常見的幾種找回密碼的方式：手機號、郵箱、銀行卡、人工申訴。
①手機號驗證
若密碼丟失，則可通過“原手機+驗證碼”的形式來進行重設密碼，但會有運營商二次放號的情況，那么需要在系統設計中規劃多個“受信任手機”或“受信任設備”的情況。
②郵箱找回
郵箱找回的方法是以往PC端的經典方法，PC時代=郵箱時代。QQ、網易等主流郵箱占據了整個市場，自然通過郵箱找回最為方便。但隨著移動時代的到來，郵箱找回的方式逐漸被遺棄，且在賬號體系若無通過郵箱為主的賬號方式，則一般也很少會在體系當中要求用戶綁定郵箱。
在移動時代，郵箱找回較為麻煩且用處不大，但可作為手機號找回的輔助方式。
③驗證銀行卡
若在體系當中涉及到銀行卡綁定的，則銀行卡可作為個人的唯一標識，通過“銀行卡+預留手機號+驗證碼”的驗證方式來驗證個人信息，從而明確是否本人的方式，來找回密碼。
④人工服務
在各類驗證方式都走不通的情況下，只能通過人工服務來進行找回密碼。需要先讓用戶上傳身份證等個人確切信息之后，客服在一定的工作日內進行處理，會耗費相應的客服資源，且反饋時間較長。
（3）風控流程
風控流程的本質在于確保用戶身份的合法性及正確性，防止部分不法分子惡意攻擊及注冊，影響原本體系的安全。
賬號作為用戶登錄系統的“通行證”，其重要性不言而喻。而保護好賬號的安全，也是至關重要的。其在于注冊、登錄流程上，被黑客惡意注冊，導致平臺資源浪費；賬號信息泄露，導致用戶信息受損；不論是對于平臺還是對于用戶，都是極大的損失。
對于風控措施，可從惡意注冊賬號、IP、盜取等方向來思考。
阿境列舉了以下幾項針對于賬號體系的風控措施，可供參考。
針對于惡意注冊賬號，浪費平臺資源：
- 禁止非正常的、大量的“驗證賬號是否存在”的操作請求，防止不法份子通過不停的輸入大量賬號，去獲取該賬號是否存在的數據。
- 郵箱注冊時增加郵件驗證碼功能或者通過郵件進行激活確認。
- 通過短信驗證時，進行短信次數限制，保護短信通道不被惡意者大量刷短信，造成堵塞。
- 驗證方式升級，通過圖像驗證碼、文字驗證碼甚至題目驗證碼等，加大驗證難度。
- 唯一手機號，保證一機一號。
- 通過IP對請求上限做出限制，防止惡意用戶大量發起注冊請求，攻擊服務器。若多次請求，數據錯誤，則對賬號進行梯度時間凍結。
針對于盜取賬號，影響賬號安全性：
- 確保用戶訪問的真實性，進行手機號驗證或手機掃碼登錄。
- 異常操作，非本人IP/手機進行通知提醒。
- 高風險的賬號操作，系統后臺運行后，重新進入，需要重新輸入驗證信息（指紋、手勢等），常用在支付類系統。
3. 賬號體系的頁面展示
頁面僅為部分邏輯展示，目前發展到了現在，登錄注冊的頁面展現形式各異，依據系統的定位來規劃及設計即可。
五、賬號體系的合并與打通
在各大系統中，存在多個系統，多個賬號，互相交雜的情況，那么，延伸出了賬號的合并問題與打通問題。
同個系統中，存在的問題是合并問題：
- 同類型的賬號合并；
- 不同類型的賬號合并。
不同系統中，存在的問題是打通問題：
- 單向數據打通；
- 雙向數據打通。
1. 賬號體系的合并
賬號的合并指的是，在一個系統內，一個用戶的多個賬號合并成為同一個賬號。
賬號分為同類型與不同類型兩種。同類型指的是注冊類型相同，例如同一個人用兩個手機號注冊兩個賬號；不同類型指的是注冊類型不同，例如有手機號注冊，有微信注冊，有郵箱注冊，但其擁有者均為同一個人。
那么此時，用戶發起合并，將其所擁有的賬號合并為同一個。
處理方式為：保留其中一個主賬號，將數據累加到主賬號當中，其余賬號數據清空。
2. 賬號體系的打通
賬號的打通指的是，在不同的系統，賬號數據的互通。在這當中，“互通”又分為單向打通與雙向打通。
- 單向打通指的是一個系統有權使用另外一個系統的部分數據，這里的“有權使用”我們可以理解為“授權”。第三方授權便是這個原理，某APP授權微信，則由于微信的開放平臺數據，某APP可獲取其名稱頭像等數據，進而采用這些數據在系統中流轉。
- 雙向打通指的是兩個不同的系統，數據相通，多用于合作模式的系統，情況不多。例如A與B兩個系統，部分數據是公用的，那么，在A系統中修改了個人信息，在B系統中的個人信息也隨之修改，共用的是同一套數據。
這當中的核心為數據流通，一個用戶在多個系統內，局部數據流通（單向或雙向），數據總量不變。
六、賬號體系設計的幾個要點
（劃重點，這個要考）
1. 搭建適合自身產品的賬號體系
選擇賬號體系基于四個維度來判定，分別是：①終端類型 ②產品類型 ③用戶類型 ④產品發展四個方面。
（1）終端類型
目前對于終端，分別是PC端與移動端。對于以往PC端時代來說，郵箱是最盛行的，隨手打開郵箱即可接收驗證信息，拿到現在移動時代，如此操作便略顯繁瑣了。
（2）產品類型
不同的產品類型，由于其本身性質的不同，應設計不同的賬號體系。
設計的核心在于盡量靠近產品主流業務所使用的信息，來設計賬號體系。
例如：打車平臺、外賣平臺是必須要知道用戶手機號的，那么可直接采用手機號登錄的方式來設計賬戶體系。
（3）用戶類型
用戶類型的不同，也需要考慮不同的賬號體系。
拿三類用戶來舉個例子，學生、年輕人、老年人。
- 對于學生來說，考慮到部分學生是沒有手機號的，則若僅限制用手機號注冊，便會流失這部分的用戶，而QQ幾乎是人手一個，那么采用第三方登錄是最合適的方法。
- 對于年輕人來說，手機號、各類主流第三方賬戶，郵箱均有，那么設計最適合的登錄方式即可。
- 對于老年人來說，賬號密碼的登錄體系由于其復雜性，必然不適合。那么采用手機號登陸較為合適，考慮到老年人這個特殊群體，需要設計較為簡單的操作流程，可采用目前較為流行的“本機號碼一鍵登錄”的方式，將注冊登錄融為一體。
（4）產品發展
產品在前期發展的時候，需要快速占領市場，時間緊任務重，那么可直接采用接入第三方登錄的方式。在發展到一定體量的時候，那么便有必要構建一套自己的賬戶體系了。
2. 根據產品類型設定賬號是否強制登錄
（1）先瀏覽再登錄
若是內容類、資訊類的產品，為了用戶體驗，一般不強制登錄，采用先瀏覽再登錄的方式。將登錄后置的一個重要原因在于留住用戶。根據漏斗模型可知，用戶操作步驟越多，流失越多。且降低瀏覽的門檻，能夠吸引用戶查看內容，當需要使用到賬號信息時（例如購買），再引導用戶去進行注冊登錄的操作。
那么，這么設計的缺點在于①注冊入口多，系統維護成本高 ②用戶信息需要分多環節設計。
（2）先登錄再瀏覽
若是社交類的產品，則一般采用先登錄再瀏覽的方式。其原因在于，針對于社交，賬號是唯一主體，且需要通過賬號來進行后續的操作，無法跳過注冊登錄的流程。
但是，部分內容類的產品這么設計，容易造成用戶流失。
（3）無需注冊登錄
若是工具類的產品，則賬號體系作為弱需求的存在，可有可無，在資源有限的情況下，可不做賬號體系，直接使用產品，便也無需注冊登錄。當然，上文有提到，針對于工具類的產品，賬號體系的意義在于后續的擴展價值及商業價值。
3. 考慮賬號體系的安全機制（二次放號的情況）
上文提到，目前我們主流的賬號體系注冊方式，主要為：①手機號賬號體系 ②第三方賬號體系。
那么，而以手機號作為核心的賬號體系，卻會延伸出不同的問題。
手機號更換且停用的情況，導致舊手機號丟失，運營商會有將廢棄的手機號二次回收再發放的情況。
舉個例子：號稱廈門吳彥祖的阿境先前用舊的號碼注冊了某健身平臺。有一天，他換了新的手機號，那么舊的號碼便注銷掉，運營商過了一段時間（大約四個月）重新將其投放入市場。
那么這個時候，便會遇到，有人拿這個舊的手機號進入這個健身平臺，篡改了阿境的賬號信息。
那么，如何避免這個問題呢？
本質在于，通過身份驗證來確保是用戶本人操作。
（1）好友輔助驗證
社交類產品多采用該方式，如QQ和微信，通過線下聯系好友，好友在號上進行確認操作，多位好友進行驗證之后，便通過。
安全性較高，但換來的也是操作復雜麻煩的代價，多用于社交類產品。
（2）歷史信息驗證
通過用戶自身回憶歷史的操作信息及個人信息，并回答相應問題，正確后即可通過驗證。例如：“近期的購物產品是什么”“曾經用過什么密碼”“回憶一下最近的好友”“回憶一下近期使用過的頭像”等等
但當平臺逐漸增多，數據不斷交替更新的現在，歷史信息驗證這個方法的準確度逐漸下降，要讓用戶記住曾經設置的某些信息，越來越難，體驗遠沒有想象中的好。
（3）用戶身份驗證
倘若用戶在系統中留下了自身的信息，唯一且安全，那么，該信息便可用于自身的信息驗證。例如：人臉識別，身份證，銀行卡，社保卡等信息。
（4）通過已添加的其他“受信任的手機號/設備”通過驗證
部分平臺在系統內，會增設多個“受信任手機號”的功能，添加多個手機號，當主手機號丟失的時候，可通過其余手機號發送短信的信息驗證，來驗證用戶自身的身份。
也可添加多個“受信任的設備”來認證登錄，此后，受信任的設備可將陌生設備踢下線。
（5）密保問題認證/郵箱認證
通過密保問題驗證及郵箱驗證，是互聯網早期PC時代時慣用的方式，通過“賬號密碼”的賬號體系，附帶設置密保問題的安全措施，保證用戶的賬號安全。
這個方式最大的問題便是密保問題的記憶，往往很多人還是會忘記。舉個例子，如今蘋果賬號依然是使用密保問題，如若無刻意去記憶，那么我想大部分人還是容易遺忘。
（6）客服申述等
在所有自身提交信息并認證的措施都嘗試之后，若還不行，那么只能通過客服申訴來找回賬號。通過讓用戶填寫證明賬號信息的表單，提交客服，從而來人工判定賬號的歸屬人。
但此法容易占用客服資源，且費時費力，是下下之策。
4. 一些能夠提升用戶體驗的設計
（1）手機號注冊，帶空格
在注冊登錄或綁定手機號等兩個流程，需輸入手機號的時候，自動為用戶空出空位出來，以3-4-4的方式，用戶在輸入的過程中隨時可更加方便校準所輸入的內容及位數是否正確。
在用戶需要輸入銀行卡的信息時，同理，以4-4-4-4-3的方式來設計。
（2）精準的錯誤提示
在賬號的表單輸入框中，若信息輸入錯誤，則需以精確的錯誤提示反饋給用戶。
舉個例子，在用戶輸入賬號密碼后，若信息不正確，則有兩種處理方式：①信息錯誤 ②賬號不存在/密碼錯誤。
很顯然，第二種處理方式會比第一種好得多，用戶可以清晰的知道自身的錯誤并修正，減少了多次嘗試的時間。
同時，根據泰斯勒定律“越簡單的前端使用，那么背后一定有復雜的邏輯支撐”，用戶獲得的錯誤提示越精準，則開發資源及時間需要付出的越多。若產品前期急著開發上線，可犧牲部分交互及用戶體驗，優先級排后，待穩定后再做修改。
（3）輸入數字的時候，自動調起數字鍵盤
在輸入密碼的時候，若密碼要求純數字，則自動調起數字鍵盤，且強制不可轉換，以避免用戶誤操作輸入錯誤信息，增加不必要的用戶操作。
（4）有前置條件的按鈕可置灰，輸入信息后恢復可點擊狀態
若信息未達到系統要求信息，則按鈕置灰，減少不必要的點擊。
舉個例子：登錄時，需要輸入賬號與密碼，若用戶僅輸入賬號或密碼時，按鈕保持置灰狀態。當賬號及密碼均輸入且達到要求（例如6到16位），按鈕回復可點擊狀態。
（5）密碼提供顯示/隱藏按鈕
輸入安全性較高的信息時，給予用戶顯示/隱藏按鈕。
例如：在輸入密碼時，用戶旁邊若有人，則輸入密碼的步驟的隱私性降低，提供顯示/隱藏按鈕，可讓用戶自行選擇是否顯示正在輸入的信息。
（6）必填與非必填項的提示
用戶首次注冊賬號登錄時，部分系統出于做前期用戶推薦的目的，要求用戶輸入部分信息，則信息作為表單，進行必填與非必填的提示，例如可使用*號作為區分。將操作的可控性前置到用戶輸入信息的時候。
寫在最后
賬號體系可大可小，一個看似小的功能點可以延伸出很多細微的知識。
重點在于產品的體量大小，是否值得如此深度的來設計。
剛開始的產品，賬號體系的作用可能僅限于可注冊登陸，且用戶量也少，那么并不怎么需要考慮風控及安全機制。而將自身主體業務做精做全之后，再來完善賬號體系也不遲，畢竟賬號體系說來也是一個龐大的工程量。
想必PM若沒有足夠的洞察力及充分模擬業務場景，也不一定能完全做好賬號體系（不僅僅在于搭建，還在于各類風控措施及安全機制）。
阿境在開始寫這篇文章的時候，從第一個字到現在，遠遠超過了預估的時間。
構思的時候，內心：“賬號體系這么多，歸納一下吧，也不難。”
剛開始寫的時候，內心：”還行，有點感覺?！?/p>
寫到一半，內心：“怎么好像有點難?！?/p>
寫到快結尾，內心：“天吶好難，寫完我要放棄產品這條路了！”
（開個玩笑）
原計劃三千字講清楚，現在磨磨蹭蹭到了小一萬。（也可能大部分都是因為我啰嗦 哈哈哈）
“切莫小看每一個看似細小的功能點”永存敬畏之心是每一名PM都應該擁有的。
作者：阿境，熱愛產品的凡夫俗子。野蠻生長，產品汪一枚，做過電商、醫療、教育行業項目，有百萬級流水產品經驗。公眾號：夢想家阿境
本文由@阿境 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
專欄作家
阿境，微信公眾號：夢想家阿境，人人都是產品經理專欄作家。遇到過三位數的DAU，也有八位數DAU的經歷；擅長產品面試的指導，用戶需求的洞察，對社交領域有深入的見解。
本文原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
是否對于后臺賬號和C端用戶賬號也要區別，因為后臺賬號會涉及到員工信息，組織結構；而C端賬號只有賬號的基本信息
貌似缺少員工管理部分的內容了，員工管理+賬號管理才可以認為是完善的賬號體系吧，個人見解
謝謝作者的分享，系統的理解了
文中提到的“數據雙向打通”，中臺的用戶體系是否就是這種場景？
有沒有關于賬號安全更細節的介紹？
很細節，很全面 學到了知識。
感謝認可
很棒
公眾號：夢想家阿境
很細節全面 謝謝
希望對你有幫助。 ??