起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識賬號體系產品設計思路
當用戶花上50M流量下載你的APP時，請在登錄時對他好點。
用戶使用產品的時候會根據他的需求來使用里面的場景，作為產品端，肯定是想獲取用戶的信息。所以賬號體系的搭建，互通賬號有無肯定是需要去思考其中的場景。
用戶使用場景
社交類產品：其本質是連接人與人，用戶需要產生個人內容促進互動，通過互動直接建立和維系關系。這一切都要建立在賬號體系的基礎上，因為里面都是個人數據。
服務類產品：其本質是連接人與服務，那么用戶為了獲取某項服務（培訓課程，購物，特定視頻等），需要使用賬號體系來記錄他們的個性化行為，完成服務的交易，同時又能從中享受到個性化服務。
工具類產品：其本質就是用技術手段幫助用戶省時省力用最簡單的方式解決需求。比如看新聞，輸入法，辦公軟件，百度地圖等。用戶為了享受云服務，在WEB,移動端,網絡端能接觸到自己所需的資源，需要賬號體系。同時又能從中享受到個性化服務。
無論是什么類型的產品，從用戶的使用場景來看，賬號體系產品其實不是用戶的直接需求，而是他們為了獲取某項服務所需要的，比如從社交中建立關系和維系關系，從服務產品中獲取某項服務，從工具產品中獲取增值服務。
所以賬號體系產品其本質是企業滿足用戶的其他持續性需求而提供的支持性產品。
當然如果一家企業產品只是一次性交易或者單純的工具而沒有其他增值服務，那么其實也就沒有建立的必要。
賬號體系產品需要解決什么問題？（需求分析）
首先來分析一下，為了保證用戶順利地使用產品服務，能夠獲取用戶的個性化行為，為其提供個性化的服務，來滿足企業的商業需求。賬號體系產品需要解決哪些問題呢？
1.保證賬號的真實性，用戶信息可證明用戶真實存在。（不驗證郵箱/手機號則無法建立與用戶聯系渠道，無法確認賬號的真實性。）
2.保證用戶ID與用戶信息的唯一對應性，即一個用戶信息與一個用戶一一對應，不會出現多個用戶信息對應一個用戶，或者一個用戶信息對應多個用戶的情況。（一個用戶的的信息只能與一個人綁定，不能一個郵箱一個賬號，一個手機號一個賬號，一個第三方登錄一個賬號，這些信息必須與一個人唯一對應起來。）
3.解決用戶使用被別人注冊過的手機號之后能夠順利建立新賬號，同時解除新手機號與原來用戶信息的綁定關系，避免用戶數據被泄露。（新用戶在使用新手機號注冊時發現已經被注冊過啦，有些產品設置快捷登錄，這樣得會會泄露之前用戶的數據，還有些產品直接就不能登錄，這些都會導致用戶的流失。所以需要重新注冊并且解除之前的綁定關系。）
4.第三方登錄后，需要重新注冊，來建立個人賬號體系，不允許出現沒有賬號，密碼的新賬號信息。（新用戶第三方登錄后再注冊對用戶來說確實操作麻煩，而且還有些被欺騙的感覺，但是如果不注冊則產生的虛擬賬號對平臺和用戶都沒有什么價值，所以需要進入注冊流程，但是可以在這個流程給用戶點心理安慰。）
5.解決用戶變更手機號等注冊賬號信息變更后，通過用戶信息和綁定賬號還能找回之前的數據。（很多時候老用戶換了地方，換個套餐，或因為某些原因更換了手機是很正常的，但是不能因為換了手機號就無法再使用之前的數據，特別是有資金或者隱私的數據，必須得讓用戶可以主動更換手機號，或者很多時間用戶忘了也能得通過第三方綁定賬號，信息驗證找回其個人信息。）
6.保證賬號服務交易時的安全性及用戶資金的安全性。（假如用戶手機不見啦，交易沒有保護的話，那么用戶的資金就極不安全。）
7.用戶登錄的安全性保證，采用雙重保護政策，登錄手勢，指紋解鎖等（現在很多軟件都是自動登錄的，即登錄一次后不退出則一直保持登錄狀態，有些軟件為了保證用戶資金的安全性，使用登錄保護驗證。）
8.用戶實名制，建立可以運用于現實世界的信息檔案（當用戶需要利用平臺的服務資源運用于現實世界中，比如培訓證書，項目經歷等則需要實名制等手段將真實的用戶綁定到虛擬的平臺中。）
9.保證用戶使用數據是人為的登錄行為（在WEB端，為了避免利用代碼自動登錄行為，可以通過圖形驗證，圖形拼圖等方式增加機器登錄的難度。）
10.用戶換號后重新注冊的用戶數據與綁定第三方賬號用戶數據可以進行合并，以手機號賬號信息為主，合并其他的個人信息。（比如老用戶手機換號了，原來手機號又被新用戶重新注冊呢，那么該用戶信息不是一個登陸賬號但包含了第三方賬號信息，個人資料及用戶行為數據，而缺乏手機賬號和密碼，可以通過用戶信息驗證綁定新的手機號的密碼。那么可能用戶會利用新手機號重新注冊，然后再綁定社交賬號，發現可以找回之前的數據，那么久存在著一個賬號信息合并的問題。）
怎么解決這些問題？（產品設計）
解決賬號真實性和唯一性，以及用戶新手機號被注冊過后解綁注冊問題，保證用戶注冊順暢，以便用戶可以快速獲取自己想要的服務。其中注冊模塊功能點包括手機號，手機驗證碼，密碼，用戶協議及注冊。其重點在于通過業務邏輯保證體系的完善性，通過優化用戶使用流程及交互體驗來是產品變得易用性，提高用戶的轉化率。
業務邏輯圖
用戶使用流程
用戶使用流程（常規）：輸入手機號-發送驗證碼-輸入驗證碼-輸入密碼-同意用戶協議-點擊注冊-轉到登錄頁面-輸入用戶名-輸入密碼-登錄。
流程優化：輸入手機號-發送驗證碼-輸入驗證碼-輸入密碼-同意用戶協議（默認同意）-點擊注冊-轉到登錄頁面（自動）-輸入用戶名（自動讀取）-輸入密碼-登錄
從用戶使用場景中可以發現，用戶進入注冊/登錄頁面的目的是為了獲取某項服務，所以對流程要求就是快。那么當用戶注冊成功后，就可以調用剛才的用戶名省去登錄中再次輸入用戶名，只需要用戶輸入密碼就可以啦。
交互設計邏輯
交互設計
聯合登錄-重新注冊賬號，通過聯登解決老用戶因為換手機導致原手機賬號已被解綁不能登錄，重新綁定新手機的問題。其中聯登模塊功能點包括聯登確認和注冊流程。
聯合登錄邏輯圖
?忘記密碼邏輯圖
主動更換手機邏輯圖
登錄邏輯圖
更換第三方賬號邏輯圖
以上是總結的一些。有更多補充的 可以私信。
總之，當用戶花上50M流量下載你的APP時，請在登錄時對他好點。
本文由 @john 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基于CC0協議
想請教下怎么進入解綁流程，在重置手機號流程中，判斷手機號是否已經注冊，如果新的手機號已經注冊，就進入解綁流程；
如果新的手機號確實有別的人在用，怎么把控賬號被盜用的風險；
通過驗證碼
這篇文章比隔壁那篇標題為賬號體系的文字好到不知道哪里去了。
您的描述看起來是挺詳細的，但邏輯并不是很清晰，甚至有點問題
存在邏輯問題
很詳細，贊一個！
這流程畫的有點亂。建議業務邏輯的流程不要加入交互細節。
如果賬號001下只有手機號A存在關聯。手機號A又被別人解綁了，那么這個賬號001怎么找回？
可以通過郵箱 或者通過賬號更換手機號
你的賬號體系，允不允許用戶賬號下只存在（注意：是只存在）關聯手機號，如果存在，該賬號下的手機號被其他賬號關聯走了，那么這個賬號怎么找回來。因為我看你的原型是靠手機號登錄。
流程圖畫的有點難懂