前言
用戶系統(tǒng)是很多產品最基礎的構成之一，但是越是基礎越是開源設計想要完善也更難宵喂。在設計用戶系統(tǒng)的時候或悲，首先想到的關鍵詞是注冊和登錄。但并不是有這兩者就足夠了怪与，更加完善用戶系統(tǒng)本身還需要考慮：多平臺賬號打通夺刑，同平臺賬號之間綁定與解綁，賬號安全等及需要怎樣的前端設計才是滿足這個產品本身定位和用戶操作的設計。
用戶系統(tǒng)的實現(xiàn)簡單來說有兩種方式：1遍愿、自己構建用戶系統(tǒng)存淫；2、用第三方授權沼填。第三方授權獲得的用戶信息有限且受制于人桅咆，而自己構建用戶系統(tǒng)研發(fā)及用戶使用成本均不如第三方授權。所以更多的是兩者并存坞笙，相互補充岩饼。
在定義服務端字段或需求若有不完善和不專業(yè)的地方，希望大家多提意見薛夜，共同完善籍茧。
一、總結需求
1.用戶系統(tǒng)基本注冊／登錄功能及前端頁面設計
2.多平臺賬號打通梯澜，即在單一app注冊的用戶寞冯，能夠使用此賬號登陸系統(tǒng)內所有app
3.用戶相對獨立，對于單一app來說用戶身份唯一
二晚伙、前端設計
登陸注冊主流設計有三種（原型如下）
1. 賬號密碼優(yōu)先
賬號密碼優(yōu)先是最常見的一種登錄注冊設計吮龄，適用于普遍場景，鼓勵用戶用注冊方式登錄咆疗，有利于產品引導用戶完善更多的資料漓帚，留存自己的用戶信息。例如知乎是以賬號密碼登錄為最優(yōu)先午磁，且會隱藏第三方授權登錄〕⒍叮現(xiàn)在的賬號密碼登錄都會以用戶注冊方式代替系統(tǒng)生成的userid作為賬號。純賬號密碼登錄是較為早期的設計漓踢，例如早期qq和飛信牵署。
2. 手機號快捷登陸優(yōu)先
手機號快捷登陸，也叫免密登錄／短信驗證碼登錄喧半，適用于用戶不登錄能夠完成大部分行為奴迅，只有在某種場景下必須獲得用戶身份時才需要用戶登錄，且此時用戶的想要完成的行為是被要求登錄操作打斷的挺据。常見的如團購類產品取具，用戶在應用內進行了商品的瀏覽、篩選扁耐、添加到購物車暇检，當要進行最后一步付款操作時，發(fā)現(xiàn)未登錄婉称。這時繁瑣的注冊或者登錄都有可能導致這筆訂單甚至這個用戶的流失块仆。所以這時獲取用戶身份的方式一定要盡可能便捷构蹬。
3. 第三方授權登陸優(yōu)先
第三方授權登陸，適用于對用戶資料和權限要求不高快速解約開發(fā)成本的產品悔据。建議在應用構建用戶系統(tǒng)的前期可以首先接入第三方庄敛，快速的實現(xiàn)登錄功能。但是若想建設自身關系鏈還是需要完善自己的用戶系統(tǒng)科汗。
用戶資料實際也屬于用戶系統(tǒng)等設計的內容藻烤。是否要增加此項的判斷原則是根據(jù)這個產品對用戶資料的需求程度決定用戶注冊時是否要增加資料填寫頁，資料填寫頁是強制阻斷性的還是可跳過的头滔，必填的資料項有哪些怖亭，希望填的有哪些。例如是需要關系鏈的那么注冊的時候就應該強制用戶去填寫資料設置必要的昵稱和頭像坤检，這樣的用戶對于此類應用來說才屬于有效用戶兴猩，不然在app內用戶點進資料頁，全是系統(tǒng)自動生成的垃圾信息缀蹄，對于建設關系鏈和留存?zhèn)^大峭跳。
交互細節(jié)上又可以延伸用戶進行注冊或登錄需要幾個步驟膘婶？這些步驟是在一個頁面上承載還是一步一個頁面以多頁面去承載缺前？單一頁面承載的優(yōu)勢是用戶能夠有很清楚的預期，他完成注冊需要進行哪些操作悬襟，但是劣勢是一個頁面承載過多信息顯得雜亂衅码，操作的次序也會不明確；多頁面承載的劣勢是用戶對完成注冊的具體行為沒有完整預期脊岳，更容易跳出逝段，優(yōu)勢是頁面整潔并且路徑單一，能引導用戶完全按照通暢的預設路徑進行割捅。我個人更推薦后者奶躯，因為用戶預期可以用頁碼／步驟管理用戶預期。
下面是我根據(jù)我們產品的定位和需求設計的用戶登錄／注冊系統(tǒng)原型：如上所說亿驾，我設計的用戶系統(tǒng)是需要承載多產品的嘹黔，所以我設計融合賬號密碼登錄和手機號快捷登錄兩種方式，以用戶出發(fā)需要登錄的場景去切換展現(xiàn)在用戶面前的是哪一種莫瞬。
補充一些貼心的小點：
1.申請讀取本機號碼權限儡蔓，并幫用戶填寫
2.申請讀寫短信權限，獲取到驗證碼后自動填寫并點擊下一步
3.應該前置到提醒：上次登錄方式疼邀，合法的手機號喂江，正確的圖形驗證碼等等
三、服務端設計
很多產品旁振，特別是沒有技術背景的產品不會去接觸和設計服務端需求获询，實際上我自己日常工作中接觸服務端需求也并不多涨岁，并不是說產品要負責設計一個完善的用戶系統(tǒng)服務端，而是要學會以服務端同事能懂的方式表達清楚自己的訴求吉嚣，兩邊對功能的實現(xiàn)不會有太多的偏差卵惦，這是產品設計服務端目的所在。
簡單的用戶系統(tǒng)服務端的基本功能需求為：判斷賬號身份（注冊/未注冊）瓦戚，賬號身份生成（新用戶分配id）沮尿，賬號密碼驗證；這里要設計的并不滿足于注冊登錄较解，需要考慮多平臺賬號打通的用戶系統(tǒng)并且要和在打通情況下單一平臺或多個平臺之間畜疾，用戶的多個賬號之間綁定于解綁。現(xiàn)在先說一下多平臺賬號打通需要考慮哪些問題：
1.用戶系統(tǒng)身份的創(chuàng)建印衔，因為我們是多平臺的系統(tǒng)啡捶，所以用戶身份只能納入手機號注冊的用戶，若第三方授權注冊的也算用戶系統(tǒng)用戶奸焙，在賬號綁定的那一關則會出現(xiàn)混亂瞎暑；
2.實現(xiàn)多平臺賬號打通，要實現(xiàn)多平臺賬號打通与帆，即所有接入多平臺都能夠查詢到此用戶身份了赌；
3.平臺間用戶身份獨立，要實現(xiàn)平臺間用戶身份獨立玄糟，則需要在用戶系統(tǒng)用戶身份的基礎上創(chuàng)建一個平臺的用戶身份勿她；
(一) 用戶系統(tǒng)多平臺打通
名詞解釋
1)Appid：接入用戶系統(tǒng)時首先分配，用于區(qū)別接入的各個app阵翎；
2)Unionid：用戶手機注冊時逢并，由用戶系統(tǒng)根據(jù)手機號創(chuàng)建，在用戶系統(tǒng)作為用戶唯一身份標識郭卫；
3)Appuserid：用戶注冊時砍聊，由app服務端根據(jù)union或者第三方授權的openid創(chuàng)建，在app內作為用戶唯一的身份標識贰军；
基本原則
1)手機號作為用戶系統(tǒng)賬號的注冊的唯一途徑玻蝌，根據(jù)手機號在用戶系統(tǒng)服務端創(chuàng)建并保存unionid；app服務端根據(jù)unionid創(chuàng)建并保存appuserid谓形，且將unionid對應保存灶伊；
2)用戶系統(tǒng)同一unionid可對應不同的appuserid
3)使用第三方openid授權的注冊用戶不計入用戶系統(tǒng)僅存在app服務端作為單app用戶，即unioid為空只生成appuserid寒跳；第三方授權包括微博微信聘萨，QQ，F(xiàn)acebook童太，Twitter
1. 主線流程圖
手機號注冊主流程為：
用戶注冊時米辐，用戶系統(tǒng)服務端需要驗證手機號＋驗證碼是否為真胸完，此手機號是否已有對應unionid；若有提示已注冊翘贮，請登錄赊窥；若無創(chuàng)建對應unionid，app服務端根據(jù)unionid創(chuàng)建appuserid狸页。至此成功生成了用戶系統(tǒng)身份及當前app用戶身份锨能。
手機號登陸主流程為：
用戶登錄時，用戶系統(tǒng)服務的驗證手機號＋密碼是否為真芍耘，此手機號是否有對應unionid址遇，若有，則說明此用戶有用戶系統(tǒng)身份斋竞。
還需要app服務端需要查詢是否有對應的appuserid倔约，若有說明此用戶有此app身份，直接用其appuserid登錄坝初；若無則說明是用戶系統(tǒng)內其他聯(lián)合app注冊用戶根據(jù)unionid創(chuàng)建此app的用戶身份浸剩，至此登錄成功。
用戶系統(tǒng)是大多數(shù)app都會有多構成鳄袍，單一的用戶系統(tǒng)也并不那么復雜绢要，但是若要構建產品矩陣進行多平臺間的用戶打通，加上帳號綁定與解綁畦木，并不是一時半會能夠想清楚的需求袖扛，若大家感興趣為會繼續(xù)補充帳號綁定和賬號安全產品應該關心和設計的事情。謝謝：）
