關于登陸注冊設計,你需要注意這7個要點

15 評論 11519 瀏覽 148 收藏 16 分鐘

登錄注冊這件事說大也不算大,說小也能研究出諸多道理。這個流程的設計,也能側面反應出整體產品的認真程度。本文從登錄注冊的流程方式、交互體驗、設計細節等方面,分析登錄注冊這個流程的設計要點。

一、從最簡單的部分開始

最基本的板塊包括“登錄”、“注冊”、“密碼找回”這三大功能。其中每一項也包含有多種不同的方法,將我見過的所有的類型總結如下:

那么,我的產品要包含哪幾種呢?是不是所有的登錄注冊方式都要包含,以給用戶最多的選擇?為什么還見到有的產品包含有“郵箱登錄”這種上古時代的登錄方式?為什么有時第三方登錄以后卻還要綁定手機號?

這些問題都沒有確定的答案,需要根據產品的各種需求確定:

  • 可能自家產品在pc時代就出現了,因此很多用戶只有或習慣用郵箱登錄的賬號,因此為了照顧老用戶提供了郵箱登錄;
  • 可能產品中正好要體現性別、地區等信息,微信登錄即快捷又能自動獲取信息自是大好,要特別突出;
  • 可能產品排斥用戶擁有太多賬號,因此在第三方后邊加了手機號綁定,把多個第三方賬號結合在一起。

選用什么方式,設置什么流程,都是根據產品的特征和以后的需求確定的,需要仔細權衡,做出適合自己的選擇。

下面就從多個角度,分析這個過程中經常見到的問題,以及可能的優化方案。

二、什么時候登陸?登陸完以后做什么?

那么第一個問題就是,在什么時刻提示用戶擺脫游客身份去登錄?

概括的來說,一些對用戶ID沒有要求的內容性的功能(例如瀏覽文章、商品等)是游客身份;一些需要定位到某一個用戶ID才能進行的功能(例如收藏、關注、評論、發布內容等)需要用戶登錄。

除此以外,運營需求也對此有要求。例如游客只開放基礎功能,更核心的付費功能需要注冊;參與產品活動之后領取活動獎勵到賬號時,必須注冊賬號領取等等。

最后就是細節的“時機”了——登錄轉化應該放在一系列連續過程的最后/最關鍵一步,例如用戶瀏覽了很久商品,添加了購物車,生成了訂單,在最后準備付款的時候,讓用戶去登錄,這里就是最佳時機。

利用“沉沒成本”效應,用戶前邊付出了那么多步驟,眼看就要成功了,這時的轉化率是最高的。

第二個問題,在游客去登錄的過程中需要注意什么?

這個過程步步都是轉化的關鍵點,流程盡量精簡,盡量偏重用戶體驗。

提供隨時退出的按鈕。在登錄注冊板塊中,也有流程性比較強,分很多頁的地方(例如密碼找回),這時要給用戶一鍵跳出此流程的選擇。

因為有可能用戶是點擊比較無關緊要的功能進入了登錄流程,用戶陷入了麻煩不想登錄,就放過他吧,一層層跳出挺麻煩的。

上面的一條也不是絕對的,如果產品很想在此處撈一把注冊數量,或者這個功能對用戶很有吸引力很重要,就要千方百計把用戶鎖在里面。例如點擊退出登錄時出現彈窗,詢問“真的要放棄注冊嗎?”。

第三個問題,登錄完之后怎么辦?

首先必須要做到的是,不論是走完了流程還是中途退出流程,都要回到進入流程之前的那個頁面,讓用戶繼續之前的任務。

從游客身份進入正式用戶身份后,以游客身份進行過的操作要同步到正式用戶的賬號中。

例如成為正式用戶后,在“瀏覽記錄”功能下,曾經作為游客瀏覽過的東西還是要顯示出來的(做法是用戶ID一直不變,只更換一下“未注冊”和“已注冊”的標簽就好)。

三、“注冊”還要不要

現在越來越多的產品沒有了注冊流程,我認為這樣總體上來說還是優大于劣(但還是要根據業務的需求做取舍),原因包括:

  1. 降低用戶對注冊的反感,減少注冊過程中用戶流失的概率。
  2. 減少了過程中的步驟,界面更簡潔流程性更強,出錯概率降低。
  3. 使用手機驗證碼而不是密碼,企業和用戶的安全性均更高。
  4. 沒有了設置密碼和輸入密碼的過程,用戶忘記密碼;密碼輸入時的種種限制和提示;找回密碼流程等全部被精簡,使用和開發都更簡單。

但是這也會帶來一些問題,總結出了下面這些問題以及應對措施。

四、“輸入密碼”這個小過程

雖然使用密碼登錄已經不再是主流方式,但是你想想啊,用戶一旦被逼迫到使用密碼登錄了那很可能是別的途徑走不通被逼無奈了,這個時候若再不帶給用戶便利那真是要把用戶逼走了。

但密碼這個東西,本身就很容易忘記;為了避免忘記,用戶就使用同一套號碼,反而又失去了保密的初衷;那你讓用戶設置一串巨復雜無比的密碼并且要定期更改,又被罵太麻煩……下面就總結了一下目前的優化方案。

也不能說做到上述優化就OK了,體驗感和安全性很難兩手抓,需要做出權衡和犧牲。

如果產品本身不涉及到非常需要保密的信息(例如工具類產品,娛樂類產品),密碼設置可以放寬,不必要非常嚴格的位數、符號、大小寫組合的規定,甚至不提供密碼登錄;

至于對用戶隱私十分重要的產品(金融類、理財類等),使用強硬的方式保證安全登錄就顯得很重要;至于中間地帶的產品,目前大部分還是使用具有一定格式規定的的密碼,降低被破解的可能性。

下面用兩種指紋登錄的方式來舉例說明:

1. 京東指紋填入密碼

  • 在初次登錄時詢問是否開通指紋輸入密碼;
  • 記住上一次登錄的手機號,在再次登錄時自動填入手機號,并詢問“是否使用xxxxxx手機號對應的密碼”;
  • 點擊確認后,使用指紋,自動填入密碼(類似開啟鎖屏);
  • 若選擇不使用指紋填入密碼,還可以用開啟鎖屏的密碼代替指紋輸入(類似開啟鎖屏);

這是種用戶體驗優先的做法,“打開手機和打開APP方式的統一”的方式,恰到好處地帶給用戶幫助,甚至有那么點“萬物互通一個身份走天下”的未來感~~

2. 招商銀行強制指紋登錄

  • 為了保證安全,每次打開全部不保留登錄狀態;
  • 然而首頁基本上全是敏感功能,點啥都要登錄,出現指紋識別登錄;
  • 識別指紋登錄;
  • 若選擇了取消指紋識別,還會再一次提示指紋登錄;

這個流程其實挺討厭的,操作步驟十分復雜。然而作為資產類的產品,如此用心地保護用戶安全,甚至給人一種使起來越復雜用戶越寬心的受虐感。

上述兩個例子可以看做“體驗”和“安全”的兩個極端,自家產品要做到什么程度靠實際狀況權衡。

五、第三方登錄后要不要綁定手機

第三方登錄之后,還要綁定手機號,這種行為從用戶的角度出發是十分不友好的:“我明明選擇第三方登錄就是為了簡便快捷,你居然還要我再綁定手機號?是在逗我嗎?!?/p>

但產品其實并不是做錯了流程,綁定手機號是基于以下幾點顧慮:

  1. 政策原因,必須獲得用戶真實身份信息;
  2. 如果沒有用戶手機號,之后的運營活動,與用戶的聯絡反饋都比較難進行;
  3. 如果沒有手機號作為賬號的綁定聯結,多次第三方登錄會產生多個賬號,出現一人多號的狀況,后續運營上和功能上帶來一系列麻煩。

所以,如果自家產品真的很看重上面這些點,考慮加入用戶手機號的綁定,可以嘗試優化:

  1. 在第三方登錄后,出現綁定手機號的界面,但是可以選擇性跳過,以后再找機會引導。
  2. 通過運營,后期引導用戶綁定,比如綁定后得到什么實惠啊,運營一個活動必須先綁定賬號啊之類的。
  3. 像京東這種“你不綁定手機號就別想使用產品,我就是厲害。你現在不想用總會有一天來用~”的大廠自信……也就沒啥話說了,直接在第三方登錄頁之后強制綁定手機號就OK。

六、一頁只做一件事

登錄注冊過程的表單其實并不多,就兩三步,為什么還非要分頁進行?原因可以分為業務和體驗兩類。

1. 業務原因

  • 有的產品先輸入手機號,判斷這個手機號是否已經注冊過,如果注冊過就進入輸入驗證碼登錄頁面;如果未注冊過就進入設置密碼注冊頁面。手機號的第一步作為分叉口,因此自己必須獨占一頁;
  • 分步的流程可以提升轉化率,這是經過實驗驗證的,相信科學就是了~

2. 體驗原因

  • 如果一頁中有很多個輸入框,用戶每次進行下一項的輸入就要伸手點擊,鍵盤又在頁面下方,上上下下的增加了流程上的復雜。分步輸入可以在進入該頁時就自動獲取焦點彈出鍵盤,減少點擊次數;
  • 有些產品注冊時需要提供的信息很多(例如keep在注冊后跟著一大串體質測試),此時可以將必要的信息(手機號驗證碼,可能還有性別之類的)和非必要的信息(愛好、標簽、個人描述之類的)分開頁面,讓用戶自選填寫。

分步式流程的可以分為“拆分輸入框”和“分類大量信息”兩種(名字自己取的),在下面分別舉例說明需要注意的tips。

第一個例子是鯊魚記賬,是比較典型的“拆分輸入框”的類型。

另一個是keep,因為在注冊以后要填寫大量的冷啟動信息,因此使用了“分類大量信息”的類型。

七、登錄/注冊過程中有哪些錯誤和異常處理?

東西比較零碎,直接總結成表格展示。

有關錯誤提示本身,也有很多需要注意的點:

  1. 提示的形式采用toast,并且能自動消失。因為用戶的失敗只是暫時的,產品需要做的是在不打擾用戶任務進行的前提下,提示用戶異常情況,所以如果是彈框的話就太生硬了。(相對應的,如果是任務完成/成功提示,可以采用彈框,甚至是一整個頁面來展示)
  2. 提示語要溫和、容易理解、簡短,不要采用生硬的詞匯和專業詞匯。
  3. 提示語不能只告訴用戶“錯了”,還要告知“錯在哪里”,以及“該怎么辦”。

其實文章內容寫的都比較概括,很多板塊單獨拿出來就能寫一篇文章了~后續會找機會寫更加深度的分析的,給自己加個油。

筆者目前還處于自主學習階段,文章中一些觀點若有差錯,感謝各位前輩多多指點。

 

本文由 @雛 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. “分步的流程可以提升轉化率,這是經過實驗驗證的,相信科學就是了~”
    請問是什么實驗,能否說明一下?

    來自上海 回復
  2. 獲取位置

    回復
  3. 很好的干貨,對現有注冊登錄框架有了一個整體認識,收藏了,回頭好好研讀

    回復
  4. 您好,看了您的文章受益匪淺,但有一個疑惑。例如瀏覽設計類APP會收藏大量的圖片,如果使用手機號注冊登錄,換手機號之后之前收藏的圖片會歸零。針對這種情況是是不是使用第三方登錄和郵箱更好一些。

    回復
    1. 您好,我思考了一下這個問題,是這樣想的:您說的這個需求點是正確的,單獨拿同步圖片這個需求講,的確第三方登錄要更佳。但是考慮全部產品則不然?!盀g覽設計類APP”的話,以站酷舉例,會一直保持賬號登錄狀態,換手機號、卸載重裝這種需要重新登錄的狀況很少見。相對應的,它們會十分想拿到用戶手機號,為了舉辦活動,推銷網課之類的需求。這就帶來兩個矛盾的需求”為方便用戶同步圖片,而使用第三方登錄“和”為方便聯系用戶,而推薦手機號登錄“。考慮到需求的頻次,收益等因素,站酷還是選了后者。那么為了解決前者的困難,站酷提供了”密碼登錄“、”第三方登錄“等解決方案。所以說,需求的確定考慮因素很多,在這里有利在另一邊就不利,都是最終權衡的結果~不知我的這種解釋方式您是否認可 ??

      來自北京 回復
    2. 謝謝解答,受益匪淺 ??

      來自浙江 回復
  5. tql!

    回復
  6. 還有一種登錄方式可以加在登錄和注冊環節

    來自北京 回復
    1. 請問是哪一種呢?我考慮的還不太全面… ??

      來自北京 回復
  7. 很詳細的基礎技能,拜讀了

    回復
    1. 你回復的也很好哦

      來自上海 回復
  8. 4,5,6 老哥你最好,繼續努力鴨

    來自上海 回復
  9. 1,2,3 老哥你最棒

    來自上海 回復
  10. 說的很好 支持一個 希望你再接再離 謝謝優美作品

    來自上海 回復
    1. 謝謝~會繼續努力學習進步的 ??

      來自北京 回復