<ruby id="aeuc0"></ruby>
  1. <s id="aeuc0"></s>
    <source id="aeuc0"></source>

    將想法與焦點和您一起共享

    盤點注冊和登錄產品設計路上爬過的坑發布者:本站     時間:2021-12-23 11:12:49

    作為最基礎的常備功能, 注冊/登錄往往是產品第一個版本中最容易被忽視的環節,越是看似容易,陷阱越多。介紹相關產品思路的文章很多,講交互的多,結合運營的少。

    一. 非?;A

    1.1 因「私有化」而存在

    不是所有的產品都需要注冊/登錄,除非[私有內容/私有操作]具有足夠的吸引力。

    注冊:用戶告訴系統Who is Tom,系統記錄Tom和口令。

    登錄:用戶告訴系統I am Tom,系統辨別Tom和口令。

    1.2 Passport產品線及近親

    通常把注冊、登錄、找回密碼、修改密碼、賬戶關聯這幾件事歸為Passport產品線。它的近親是Profile產品線,包含用戶資料、個人設置等。

    1.3 登錄是高頻,其他是低頻

    注冊、找回密碼、修改密碼都是低頻操作,但都屬于迫切程度比較高,也最容易引發挫敗感,導致用戶投訴及放棄使用產品。

    1.4 術語:查重、校驗、驗證、匹配

    查重,“查詢是否有重復存在”的簡稱,比如:排除以手機為主鍵的重復注冊。

    校驗,檢查數據是否符合格式,比如:輸入的時候為一個手機號碼。

    驗證,確認真實性,比如手機和郵箱真的是用戶本人使用,指紋、人臉識別。

    匹配,用戶提交的數據是否與存儲中的數據一致。

    1.5 術語:Spam與Anti-Spam

    Spam指使用腳本、機器人進行惡意批量提交或遍歷破解的行為。 Anti-Spam指防止Spam的系統措施。

    1.6 術語:單點登錄SSO

    也就是所謂的通行證,注冊/登錄一次,可在所有的子產品(跨域)中通用一個Passport和相同的Profile信息。

    盤點注冊和登錄產品<a href=/design/ target=_blank class=infotextkey>設計</a>路上爬過的坑,PS教程,

    二. 注冊主鍵選擇

    主鍵是數據庫設計中的一個概念,為了保證唯一性,新增用戶時必須進行主鍵查重。

    2.1 以用戶名為主鍵注冊

    Anti-Spam:非常弱(批量Spam賬戶)。 擴展性:高,隨時可切換為以其他數據為主鍵。 使用場景:私有內容/私有操作較少的情況,比如僅提供了回復、投票、點贊等輕操作, 產品雛形期,進行測試的新產品(開發比較容易)。

    便利設計:注冊和登錄可合并在同一個界面(不考慮找回密碼時),注冊時可順便把用戶名當作昵稱搜集。

    注意事項:為了讓用戶找回密碼,必須設置密保問題,找回密碼代價很高(把自己用戶名給忘記了)。

    2.2 以郵件地址為主鍵注冊

    Anti-Spam:中等(自從QQ郵箱出來,被遍歷攻擊的事兒也是不少啊)。 擴展性:中,可以隨時切換為手機主鍵。 使用場景: 郵箱容易記憶,適長期頻繁使用的產品,適合在web端需要依賴Newsletter進行營銷的產品,非實名用戶系統,郵件主鍵的代價最小,轉化率較好。

    便利設計:To B產品使用企業郵箱注冊,自動關聯企業主賬戶。

    注意事項:郵箱是隱私,掩碼顯示,如果包含社交功能,注冊時可能需要采集昵稱。進入各大郵件運營商的白名單,是一件頭疼的事兒,搞不好就直接進垃圾郵件了。

    2.3 以手機為主鍵注冊

    Anti-Spam:弱(各種遍歷、各種騷擾,需要采取措施)。

    擴展性:低,幾乎不可逆(用戶也不答應)。

    使用場景:帶有支付功能的電商、消費類產品。實名用戶系統,需要用戶的絕對信任,初期轉化率低,最好從郵件主鍵過度。只有移動版本的產品。

    便利設計:根據手機號自動匹配地區城市、電信運營商(也有一部分用戶是攜號轉網的#_#)。

    注意事項:手機是絕對隱私,能不顯示就不顯示,顯示必須掩碼,如果包含社交功能,注冊時可能需要采集昵稱。國外手機號幾乎不可以,短信通道需要至少雙備,如果驗證短信中包含一些根本想不到的敏感詞,會很慘。用戶更換手機,運營商回收舊號碼賣給新用戶,都會大量存在,請一定給出解決方案。

    2.4 由第三方賬戶創建(并登錄)

    Anti-Spam:高(等于是把驗證權交給別人了)。 擴展性:高,可以在第三方驗證后再創建自有賬戶。

    使用場景:幾乎適合各種類型的用戶自主注冊賬戶。

    便利設計:可以根據第三方授權拿來一大堆Profile里邊的信息(除了密碼)。

    注意事項:把雞蛋放在了別人的籃子里,一定要心甘情愿。登錄之后再創建自有賬戶,會存在一定的轉化率損失。去第三方申請授權,要有耐心,而且通常在產品初期拿不到太多的Profile數據。

    2.5 社會卡證類主鍵(身份證、信用卡)注冊

    Anti-Spam:高,因為規律性比較差,但也不排除社會工程hack手段。 擴展性:都到了這步了,算是個終極。。 使用場景:特殊場合和人群,需要展示特殊的功能;實名用戶系統,需要用戶的絕對信任;必須關聯在線支付/移動支付才能使用的產品;通常都不會包含社交功能。

    便利設計:直接關聯到用戶真實身份和征信。

    注意事項:通常驗證都是通過第三方信用組織進行,比如提交信用卡關聯的身份信息,由支付機構或銀行匹配之后發送一個驗證短信/郵件/二維碼。同樣是把雞蛋放在別人的籃子里(通常是親爹的籃子)。

    2.6 其他主鍵

    用汽車牌照做主鍵,真的可以有,不是不可以,但是盡量還是別摸著石頭過河。注冊主鍵在真實社會里一定是具有非重復且個人專有的特點。

    2.7 多主鍵復合注冊

    當然可以啦,注冊時沒必要提示用戶哪個是主鍵,反正登錄的時候會提示。

    2.8 切換主鍵時注意事項

    其切換主鍵之前,一定要對數據進行篩查,情況可能是這樣的,用戶使用郵件主鍵生成了一個用戶,當系統切換手機為主鍵時,用戶會因迷惑而創建另外一個新賬戶,此時可能涉及到用戶數據合并的問題。如果這些沒有想清楚,就不要隨便更換主鍵。

    盤點注冊和登錄產品設計路上爬過的坑,PS教程,

    三. 個人注冊(To C)

    3.1 查重錯誤,不要在注冊環節隨便給出

    填寫一個手機號碼,異步查詢是否可以注冊,雖給用戶帶來了方便,但也給駭客提供了可乘之機:寫一個腳本就能遍歷出來哪些號段多少個號碼注冊過產品! 請在驗證碼正確之后給出結果,或者單獨跳轉URL給出查重類錯誤。

    3.2 前端校驗和后端校驗都要進行

    跨域攻擊是最簡單的手段咯,注冊這么大的事兒,一定要進行前后校驗(登錄之后,可以根據系統壓力再進行簡化,登錄之前,還是謹慎為妙)。

    3.3 以郵箱和手機注冊主鍵,第一步只做一件事:驗證主鍵

    沒有驗證過的郵箱和手機會弄臟用戶數據,臟庫是無法切換登錄主鍵的! 注冊的第一步,只做一件事情就好了,不要讓用戶填寫其他信息(填寫密碼也不行)。

    3.4 分步注冊,暫存數據,只有在用戶提交密碼那一刻,才創建正式數據

    如果第一步是校驗主鍵,那么應該暫存數據,只有在主鍵驗證完畢,下一步用戶填寫密碼并提交之后,再創建正式數據。(這個坑是這樣的:用戶第一步提交郵箱,但是驗證郵件沒收到,此時可能用戶會再次啟動注冊,如果前面已錄入正式數據,可能會顯示這個“這個Email已經注冊過了”)。

    3.5 有必要重復確認密碼么?

    沒必要!設置這個的初衷無非是避免用戶注冊時輸錯密碼,輸錯=忘記密碼,就去找回密碼咯。

    3.6 只采集必要數據,填寫項目越少越好

    在注冊環節,標注必填是個爆弱的設計,如果是選填,就別讓用戶在注冊環節提交。

    3.7 包含社交的產品一定要讓設置頭像成為必填

    注冊之后,需要很大的運營代價才會讓用戶上傳頭像,因此這一步驟最好是前置。

    3.8 昵稱需要查重么?

    需要!避免李逵和李鬼,盡量杜絕錄入火星文和特殊字符(視情況額定)。

    3.9 讓用戶發送密碼短信到特定號碼進行手機注冊,這很low

    誰會用?有多少用戶愿意自己付出短信成本?除非特別緊急的情況下。

    3.10 同意《用戶使用協議》

    讓用戶勾選閱讀并遵守《用戶使用協議》,不如把注冊按鈕改為“同意用戶協議,提交注冊”。

    3.11 邀請碼注冊要走單獨流程

    輸入邀請碼或點擊邀請郵件中加密連接進行注冊,可關聯邀請者ID,需要的單獨設計注冊界面。

    3.12 注冊與登錄合并設計(快速注冊)

    以用戶名和手機為注冊主鍵的時候,可以這樣設計。但以郵箱注冊的時候,用戶需要跳出到郵件系統,快速注冊就沒意義了??焖僮砸院笞詣舆M入登錄狀態。

    3.13 注冊結束后,必須讓用戶再登錄一次(快速注冊除外)

    這不僅僅是個儀式感,而且是安全的需要,增加自動腳本Spam賬戶的難度。

    3.14 注冊應該避免設計成light box(快速注冊除外)

    注冊復雜程度不一,并且會經常迭代改善產品,因此校驗代碼和各種邏輯判斷非常多,如果做成light box效果,可能會拖累很多界面的加載速度,也會讓維護和測試變得麻煩。

    3.15 注冊后的(首次登錄后)歡迎與提醒,設立URL暫存池

    注冊完成有結果提示和簡單的歡迎,然后就需要讓用戶進行跳轉。 記錄用戶點擊注冊之前的界面URL,在用戶跑完注冊/登錄流程之后,回到那個URL(“從哪里來,就回到哪”)。 如果無法判斷用戶注冊登錄前的URL,那么跳轉到一個最核心的私有內容界面, 用戶可以選擇回到Profile管理。

    盤點注冊和登錄產品設計路上爬過的坑,PS教程,

    四. 企業商家注冊/入駐(To B)

    4.1 商家注冊(申請)建立在個人賬戶基礎上

    先完成個人賬戶注冊,再創建商家。在注冊商家的同時,創建一個個人賬戶。以上兩種方法都可以。因為商家賬戶的管理者通常是員工,如果該員工離職,企業會要求進行管理權轉移,把商家掛在個人賬戶下面,靈活度最高。

    4.2 在注冊之前分流角色,而不是注冊過程中

    企業商家用戶通常按行業分類,比如賣方需要提供代理證明,而買方需要填寫收貨地址。此時最好設置為兩個入口,而不要在注冊的過程中進行條件分支。

    4.3 審核期過度界面

    通常企業商家注冊都需要一個運營審核過程,此時,用戶可登錄個人賬戶使用一些基本功能,請把審核進度明示給用戶,同時給予企業商戶功能的演示介紹。

    4.4 企業子賬戶應該是邀請的,而不是隨便填寫的

    不要讓企業商戶管理員直接填寫子賬戶的用戶名和密碼,建議企業子賬戶以email為主鍵,走邀請的流程,讓其他員工自己驗證郵件、填寫驗證手機和密碼,這樣做責權清晰,安全性最高。

    4.5 企業管理員不能直接修改子賬戶密碼

    企業管理員觸發一個驗證郵件給子賬戶,子賬戶可以自行通過加密連接修改密碼。必要時,管理員可以凍結那個強制要求修改密碼的子賬戶的權限。

    五. 登錄

    5.1 登錄主鍵提示

    在主鍵input當中,允許用戶填寫不同的主鍵,雖然校驗比較麻煩,但是用戶便利了。

    5.2 注意登錄錯誤信息拋出方法

    單獨拋出“該用戶不存在”或者“密碼不正確”可能會是不科學的,因為很可能方便了別有用心的人,比較安全做法是“用戶名不存在或密碼不匹配”。

    5.3 記住用戶和記住密碼是兩種不同的功能

    一種是保存“主鍵”,另外一種是保存“主鍵+口令”。記住用戶名,就一定要有切換用戶的功能。保存口令,要看產品的使用頻率,使用頻率越高保存周期越短(在便利和安全之間的平衡),保存周期最好不要超過3個月(甚至可以設置3個月強制更換密碼)

    5.4 防止重復登錄

    這個經常被忽略,同客戶端,后來登錄的踢掉前面的session。允許web、手機app、HDapp同時登錄,但每個終端智能保持一個session哦。

    5.5 盡量設計成light box或類似效果,登錄之后“從哪里來,就回到哪”

    注冊、登錄前暫存URL,還是一個很重要的登錄彩蛋。

    5.6 二維碼登錄

    如果有移動app,通過App掃二維碼可以直接登錄web版本。

    5.7 長期未登錄、陌生移動設備登錄,加一個判斷,通知到郵件

    長期未登錄,突然在異地登錄,在陌生的移動設備上首次登錄都屬于異常的情況,此時要增加用戶判斷的環節,并發送通知到郵件。(手機號碼可以換,郵件地址不會隨便換吧)。



    選擇我們,優質服務,不容錯過
    1. 優秀的網絡資源,強大的網站優化技術,穩定的網站和速度保證
    2. 15年上海網站建設經驗,優秀的技術和設計水平,更放心
    3. 全程省心服務,不必擔心自己不懂網絡,更省心。
    ------------------------------------------------------------
    24小時聯系電話:021-58370032
    關鍵詞標簽:上海網站建設 上海網站制作 網站優化 小程序開發
    性爱网站在线观看_免费无码国产_久久人91午夜亚洲精品无码区_久久精品国产99国产精品
    <ruby id="aeuc0"></ruby>
    1. <s id="aeuc0"></s>
      <source id="aeuc0"></source>