用戶系統是很多產品最基礎的構成之壹，但是越是基礎越是開源設計想要完善也更難。在設計用戶系統的時候，首先想到的關鍵詞是註冊和登錄。但並不是有這兩者就足夠了，更加完善用戶系統本身還需要考慮：多平臺賬號打通，同平臺賬號之間綁定與解綁，賬號安全等及需要怎樣的前端設計才是滿足這個產品本身定位和用戶操作的設計。
用戶系統的實現簡單來說有兩種方式：1、自己構建用戶系統；2、用第三方授權。第三方授權獲得的用戶信息有限且受制於人，而自己構建用戶系統研發及用戶使用成本均不如第三方授權。所以更多的是兩者並存，相互補充。
在定義服務端字段或需求若有不完善和不專業的地方，希望大家多提意見，***同完善。
壹、總結需求
1.用戶系統基本註冊／登錄功能及前端頁面設計
2.多平臺賬號打通，即在單壹app註冊的用戶，能夠使用此賬號登陸系統內所有app
3.用戶相對獨立，對於單壹app來說用戶身份唯壹
二、前端設計
登陸註冊主流設計有三種（原型如下）
1. 賬號密碼優先
賬號密碼優先是最常見的壹種登錄註冊設計，適用於普遍場景，鼓勵用戶用註冊方式登錄，有利於產品引導用戶完善更多的資料，留存自己的用戶信息。例如知乎是以賬號密碼登錄為最優先，且會隱藏第三方授權登錄。現在的賬號密碼登錄都會以用戶註冊方式代替系統生成的userid作為賬號。純賬號密碼登錄是較為早期的設計，例如早期qq和飛信。
2. 手機號快捷登陸優先
手機號快捷登陸，也叫免密登錄／短信驗證碼登錄，適用於用戶不登錄能夠完成大部分行為，只有在某種場景下必須獲得用戶身份時才需要用戶登錄，且此時用戶的想要完成的行為是被要求登錄操作打斷的。常見的如團購類產品，用戶在應用內進行了商品的瀏覽、篩選、添加到購物車，當要進行最後壹步付款操作時，發現未登錄。這時繁瑣的註冊或者登錄都有可能導致這筆訂單甚至這個用戶的流失。所以這時獲取用戶身份的方式壹定要盡可能便捷。
3. 第三方授權登陸優先
第三方授權登陸，適用於對用戶資料和權限要求不高快速解約開發成本的產品。建議在應用構建用戶系統的前期可以首先接入第三方，快速的實現登錄功能。但是若想建設自身關系鏈還是需要完善自己的用戶系統。
用戶資料實際也屬於用戶系統等設計的內容。是否要增加此項的判斷原則是根據這個產品對用戶資料的需求程度決定用戶註冊時是否要增加資料填寫頁，資料填寫頁是強制阻斷性的還是可跳過的，必填的資料項有哪些，希望填的有哪些。例如是需要關系鏈的那麽註冊的時候就應該強制用戶去填寫資料設置必要的昵稱和頭像，這樣的用戶對於此類應用來說才屬於有效用戶，不然在app內用戶點進資料頁，全是系統自動生成的垃圾信息，對於建設關系鏈和留存傷害較大。
交互細節上又可以延伸用戶進行註冊或登錄需要幾個步驟？這些步驟是在壹個頁面上承載還是壹步壹個頁面以多頁面去承載？單壹頁面承載的優勢是用戶能夠有很清楚的預期，他完成註冊需要進行哪些操作，但是劣勢是壹個頁面承載過多信息顯得雜亂，操作的次序也會不明確；多頁面承載的劣勢是用戶對完成註冊的具體行為沒有完整預期，更容易跳出，優勢是頁面整潔並且路徑單壹，能引導用戶完全按照通暢的預設路徑進行。我個人更推薦後者，因為用戶預期可以用頁碼／步驟管理用戶預期。
下面是我根據我們產品的定位和需求設計的用戶登錄／註冊系統原型：如上所說，我設計的用戶系統是需要承載多產品的，所以我設計融合賬號密碼登錄和手機號快捷登錄兩種方式，以用戶出發需要登錄的場景去切換展現在用戶面前的是哪壹種。
補充壹些貼心的小點：
1.申請讀取本機號碼權限，並幫用戶填寫
2.申請讀寫短信權限，獲取到驗證碼後自動填寫並點擊下壹步
3.應該前置到提醒：上次登錄方式，合法的手機號，正確的圖形驗證碼等等
三、服務端設計
很多產品，特別是沒有技術背景的產品不會去接觸和設計服務端需求，實際上我自己日常工作中接觸服務端需求也並不多，並不是說產品要負責設計壹個完善的用戶系統服務端，而是要學會以服務端同事能懂的方式表達清楚自己的訴求，兩邊對功能的實現不會有太多的偏差，這是產品設計服務端目的所在。
簡單的用戶系統服務端的基本功能需求為：判斷賬號身份（註冊/未註冊），賬號身份生成（新用戶分配id），賬號密碼驗證；這裏要設計的並不滿足於註冊登錄，需要考慮多平臺賬號打通的用戶系統並且要和在打通情況下單壹平臺或多個平臺之間，用戶的多個賬號之間綁定於解綁。現在先說壹下多平臺賬號打通需要考慮哪些問題：
1.用戶系統身份的創建，因為我們是多平臺的系統，所以用戶身份只能納入手機號註冊的用戶，若第三方授權註冊的也算用戶系統用戶，在賬號綁定的那壹關則會出現混亂；
2.實現多平臺賬號打通，要實現多平臺賬號打通，即所有接入多平臺都能夠查詢到此用戶身份；
3.平臺間用戶身份獨立，要實現平臺間用戶身份獨立，則需要在用戶系統用戶身份的基礎上創建壹個平臺的用戶身份；
(壹) 用戶系統多平臺打通
名詞解釋
1)Appid：接入用戶系統時首先分配，用於區別接入的各個app；
2)Unionid：用戶手機註冊時，由用戶系統根據手機號創建，在用戶系統作為用戶唯壹身份標識；
3)Appuserid：用戶註冊時，由app服務端根據union或者第三方授權的openid創建，在app內作為用戶唯壹的身份標識；
基本原則
1)手機號作為用戶系統賬號的註冊的唯壹途徑，根據手機號在用戶系統服務端創建並保存unionid；app服務端根據unionid創建並保存appuserid，且將unionid對應保存；
2)用戶系統同壹unionid可對應不同的appuserid
3)使用第三方openid授權的註冊用戶不計入用戶系統僅存在app服務端作為單app用戶，即unioid為空只生成appuserid；第三方授權包括微博微信，QQ，Facebook，Twitter
1. 主線流程圖
手機號註冊主流程為：
用戶註冊時，用戶系統服務端需要驗證手機號＋驗證碼是否為真，此手機號是否已有對應unionid；若有提示已註冊，請登錄；若無創建對應unionid，app服務端根據unionid創建appuserid。至此成功生成了用戶系統身份及當前app用戶身份。
手機號登陸主流程為：
用戶登錄時，用戶系統服務的驗證手機號＋密碼是否為真，此手機號是否有對應unionid，若有，則說明此用戶有用戶系統身份。
還需要app服務端需要查詢是否有對應的appuserid，若有說明此用戶有此app身份，直接用其appuserid登錄；若無則說明是用戶系統內其他聯合app註冊用戶根據unionid創建此app的用戶身份，至此登錄成功。
用戶系統是大多數app都會有多構成，單壹的用戶系統也並不那麽復雜，但是若要構建產品矩陣進行多平臺間的用戶打通，加上帳號綁定與解綁，並不是壹時半會能夠想清楚的需求，若大家感興趣為會繼續補充帳號綁定和賬號安全產品應該關心和設計的事情。謝謝：）