用戶系統(tǒng)設(shè)計:前端設(shè)計和多平臺賬號打通(一)

16 評論 54519 瀏覽 370 收藏 11 分鐘

用戶系統(tǒng)是很多產(chǎn)品最基礎(chǔ)的構(gòu)成之一,但是越是基礎(chǔ)越是開源設(shè)計想要完善也更難。在設(shè)計用戶系統(tǒng)的時候,首先想到的關(guān)鍵詞是注冊和登錄。但并不是有這兩者就足夠了,更加完善用戶系統(tǒng)本身還需要考慮:多平臺賬號打通,同平臺賬號之間綁定與解綁,賬號安全等及需要怎樣的前端設(shè)計才是滿足這個產(chǎn)品本身定位和用戶操作的設(shè)計。

用戶系統(tǒng)的實現(xiàn)簡單來說有兩種方式:一是自己構(gòu)建用戶系統(tǒng);二是用第三方授權(quán)。第三方授權(quán)獲得的用戶信息有限且受制于人,而自己構(gòu)建用戶系統(tǒng)研發(fā)及用戶使用成本均不如第三方授權(quán)。所以更多的是兩者并存,相互補充。

由于工作需要從0到1設(shè)計一個用戶系統(tǒng),本人不是強技術(shù)型產(chǎn)品,所以在定義服務(wù)端字段或需求有不完善和不專業(yè)的地方,希望大家多提意見,共同完善。

一、總結(jié)需求

  1. 用戶系統(tǒng)基本注冊/登錄功能及前端頁面設(shè)計
  2. 多平臺賬號打通,即在單一app注冊的用戶,能夠使用此賬號登陸系統(tǒng)內(nèi)所有app
  3. 用戶相對獨立,對于單一app來說用戶身份唯一

二、前端設(shè)計

登陸注冊主流設(shè)計有三種(原型如下):

1

1. ?賬號密碼優(yōu)先

賬號密碼優(yōu)先是最常見的一種登錄注冊設(shè)計,適用于普遍場景,鼓勵用戶用注冊方式登錄,有利于產(chǎn)品引導(dǎo)用戶完善更多的資料,留存自己的用戶信息。例如知乎是以賬號密碼登錄為最優(yōu)先,且會隱藏第三方授權(quán)登錄?,F(xiàn)在的賬號密碼登錄都會以用戶注冊方式代替系統(tǒng)生成的userid作為賬號。純賬號密碼登錄是較為早期的設(shè)計,例如早期qq和飛信。

2. 手機號快捷登陸優(yōu)先

手機號快捷登陸,也叫免密登錄/短信驗證碼登錄,適用于用戶不登錄能夠完成大部分行為,只有在某種場景下必須獲得用戶身份時才需要用戶登錄,且此時用戶的想要完成的行為是被要求登錄操作打斷的。常見的如團購類產(chǎn)品,用戶在應(yīng)用內(nèi)進行了商品的瀏覽、篩選、添加到購物車,當要進行最后一步付款操作時,發(fā)現(xiàn)未登錄。這時繁瑣的注冊或者登錄都有可能導(dǎo)致這筆訂單甚至這個用戶的流失。所以這時獲取用戶身份的方式一定要盡可能便捷。

3. 第三方授權(quán)登陸優(yōu)先

第三方授權(quán)登陸,適用于對用戶資料和權(quán)限要求不高快速解約開發(fā)成本的產(chǎn)品。建議在應(yīng)用構(gòu)建用戶系統(tǒng)的前期可以首先接入第三方,快速的實現(xiàn)登錄功能。但是若想建設(shè)自身關(guān)系鏈還是需要完善自己的用戶系統(tǒng)。

用戶資料實際也屬于用戶系統(tǒng)等設(shè)計的內(nèi)容。是否要增加此項的判斷原則是根據(jù)這個產(chǎn)品對用戶資料的需求程度決定用戶注冊時是否要增加資料填寫頁,資料填寫頁是強制阻斷性的還是可跳過的,必填的資料項有哪些,希望填的有哪些。例如是需要關(guān)系鏈的那么注冊的時候就應(yīng)該強制用戶去填寫資料設(shè)置必要的昵稱和頭像,這樣的用戶對于此類應(yīng)用來說才屬于有效用戶,不然在app內(nèi)用戶點進資料頁,全是系統(tǒng)自動生成的垃圾信息,對于建設(shè)關(guān)系鏈和留存?zhèn)^大。

交互細節(jié)上又可以延伸用戶進行注冊或登錄需要幾個步驟?這些步驟是在一個頁面上承載還是一步一個頁面以多頁面去承載?單一頁面承載的優(yōu)勢是用戶能夠有很清楚的預(yù)期,他完成注冊需要進行哪些操作,但是劣勢是一個頁面承載過多信息顯得雜亂,操作的次序也會不明確;多頁面承載的劣勢是用戶對完成注冊的具體行為沒有完整預(yù)期,更容易跳出,優(yōu)勢是頁面整潔并且路徑單一,能引導(dǎo)用戶完全按照通暢的預(yù)設(shè)路徑進行。我個人更推薦后者,因為用戶預(yù)期可以用頁碼/步驟管理用戶預(yù)期。

下面是我根據(jù)我們產(chǎn)品的定位和需求設(shè)計的用戶登錄/注冊系統(tǒng)原型:如上所說,我設(shè)計的用戶系統(tǒng)是需要承載多產(chǎn)品的,所以我設(shè)計融合賬號密碼登錄和手機號快捷登錄兩種方式,以用戶出發(fā)需要登錄的場景去切換展現(xiàn)在用戶面前的是哪一種。

2

補充一些貼心的小點:

  1. 申請讀取本機號碼權(quán)限,并幫用戶填寫
  2. 申請讀寫短信權(quán)限,獲取到驗證碼后自動填寫并點擊下一步
  3. 應(yīng)該前置到提醒:上次登錄方式,合法的手機號,正確的圖形驗證碼等等

三、服務(wù)端設(shè)計

很多產(chǎn)品,特別是沒有技術(shù)背景的產(chǎn)品不會去接觸和設(shè)計服務(wù)端需求,實際上我自己日常工作中接觸服務(wù)端需求也并不多,并不是說產(chǎn)品要負責設(shè)計一個完善的用戶系統(tǒng)服務(wù)端,而是要學會以服務(wù)端同事能懂的方式表達清楚自己的訴求,兩邊對功能的實現(xiàn)不會有太多的偏差,這是產(chǎn)品設(shè)計服務(wù)端目的所在。

簡單的用戶系統(tǒng)服務(wù)端的基本功能需求為:判斷賬號身份(注冊/未注冊),賬號身份生成(新用戶分配id),賬號密碼驗證;這里要設(shè)計的并不滿足于注冊登錄,需要考慮多平臺賬號打通的用戶系統(tǒng)并且要和在打通情況下單一平臺或多個平臺之間,用戶的多個賬號之間綁定于解綁。

現(xiàn)在先說一下多平臺賬號打通需要考慮哪些問題:

  1. 用戶系統(tǒng)身份的創(chuàng)建,因為我們是多平臺的系統(tǒng),所以用戶身份只能納入手機號注冊的用戶,若第三方授權(quán)注冊的也算用戶系統(tǒng)用戶,在賬號綁定的那一關(guān)則會出現(xiàn)混亂;
  2. 實現(xiàn)多平臺賬號打通,要實現(xiàn)多平臺賬號打通,即所有接入多平臺都能夠查詢到此用戶身份;
  3. 平臺間用戶身份獨立,要實現(xiàn)平臺間用戶身份獨立,則需要在用戶系統(tǒng)用戶身份的基礎(chǔ)上創(chuàng)建一個平臺的用戶身份。

3

1. 用戶系統(tǒng)多平臺打通

名詞解釋

  1. Appid:接入用戶系統(tǒng)時首先分配,用于區(qū)別接入的各個app;
  2. Unionid:用戶手機注冊時,由用戶系統(tǒng)根據(jù)手機號創(chuàng)建,在用戶系統(tǒng)作為用戶唯一身份標識;
  3. Appuserid:用戶注冊時,由app服務(wù)端根據(jù)union或者第三方授權(quán)的openid創(chuàng)建,在app內(nèi)作為用戶唯一的身份標識。

基本原則

  1. 手機號作為用戶系統(tǒng)賬號的注冊的唯一途徑,根據(jù)手機號在用戶系統(tǒng)服務(wù)端創(chuàng)建并保存unionid;app服務(wù)端根據(jù)unionid創(chuàng)建并保存appuserid,且將unionid對應(yīng)保存;
  2. 用戶系統(tǒng)同一unionid可對應(yīng)不同的appuserid;
  3. 使用第三方openid授權(quán)的注冊用戶不計入用戶系統(tǒng)僅存在app服務(wù)端作為單app用戶,即unioid為空只生成appuserid;第三方授權(quán)包括微博微信,QQ,F(xiàn)acebook,Twitter。

主線流程圖:

4

  • 手機號注冊主流程為:用戶注冊時,用戶系統(tǒng)服務(wù)端需要驗證手機號+驗證碼是否為真,此手機號是否已有對應(yīng)unionid;若有提示已注冊,請登錄;若無創(chuàng)建對應(yīng)unionid,app服務(wù)端根據(jù)unionid創(chuàng)建appuserid。至此成功生成了用戶系統(tǒng)身份及當前app用戶身份。
  • 手機號登陸主流程為:用戶登錄時,用戶系統(tǒng)服務(wù)的驗證手機號+密碼是否為真,此手機號是否有對應(yīng)unionid,若有,則說明此用戶有用戶系統(tǒng)身份。

還需要app服務(wù)端需要查詢是否有對應(yīng)的appuserid,若有說明此用戶有此app身份,直接用其appuserid登錄;若無則說明是用戶系統(tǒng)內(nèi)其他聯(lián)合app注冊用戶根據(jù)unionid創(chuàng)建此app的用戶身份,至此登錄成功。

用戶系統(tǒng)是大多數(shù)app都會有多構(gòu)成,單一的用戶系統(tǒng)也并不那么復(fù)雜,但是若要構(gòu)建產(chǎn)品矩陣進行多平臺間的用戶打通,加上帳號綁定與解綁,并不是一時半會能夠想清楚的需求,若大家感興趣為會繼續(xù)補充帳號綁定和賬號安全產(chǎn)品應(yīng)該關(guān)心和設(shè)計的事情。

 

作者:王悠悠悠

來源:http://www.jianshu.com/p/088de40cb100

本文由 @王悠悠悠 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 為啥第三方不能作為用戶系統(tǒng)的用戶身份標志呢?第三方登錄拿微信平臺賬號舉例可以通過UnionID做用戶唯一身份標志與綁定···

    來自廣東 回復(fù)
  2. 單一app啥意思

    回復(fù)
  3. 寫得非常好,收藏學習了。對于樓下朋友的問題我補充一點,它應(yīng)該是歸類于第三方登錄才對

    來自廣東 回復(fù)
  4. 應(yīng)該就不是

    來自廣東 回復(fù)
  5. 我的微信號是:lehuo_sun,可以交流。我自己是市場出生的產(chǎn)品經(jīng)理,但是我自己帶了一年的技術(shù)團隊。

    來自廣東 回復(fù)
  6. 【1】多平臺賬號登錄,沒有這樣復(fù)雜,直接建一個公共的sesion存用戶賬號就行了。
    【2】多平臺,用第三方授權(quán)登錄,綁定用戶資料關(guān)系,并不會有問題

    來自廣東 回復(fù)
  7. 學習了

    來自廣東 回復(fù)
  8. 為何不在輸入手機號過后,點擊獲取驗證碼時就 判斷該手機是否合法和是否已經(jīng)注冊?

    來自重慶 回復(fù)
    1. 需要驗證手機號+驗證碼是否為真后再進行判斷是否已注冊,如果直接反饋手機號是否注冊會有用戶隱私泄露風險。

      來自浙江 回復(fù)
    2. 學習了,非常感謝!

      來自上海 回復(fù)
  9. 登錄+1

    來自江蘇 回復(fù)
  10. 學習了,雖然不是設(shè)計,不過在進行ue梳理的時候也有很多時候哭鬧頁面的擺放問題,交互這東西很是惱人啊…
    lz從表單等入手講解,看過之后也大概能舉一反三了 拜謝!
    ps:人人都是產(chǎn)品經(jīng)理3群 歡迎各位小伙伴入坑,虛位以待!217321695

    來自北京 回復(fù)
  11. 登錄。

    來自上海 回復(fù)
  12. 挺好的,受教了,求繼續(xù)!

    來自北京 回復(fù)
  13. 標題中登錄字錯了。??

    回復(fù)
  14. 不明白userid被替換?

    回復(fù)