完美“登錄”,從去掉“注冊”開始
道理太多,先上車,路上慢慢說~
登錄分析
一、什么是登錄?
供多人使用的網站或程序應用系統為每位用戶配置了一套獨特的用戶名和密碼,用戶使用這套用戶名和密碼進入系統的過程,以及系統驗證進入是成功或失敗的過程,稱為“登錄”。
二、為什么要登錄?
登錄成功后,系統能識別該用戶的身份,從而保持該用戶的使用習慣或使用數據。
三、什么時候需要登錄?
當前操作/行為與服務器發生雙向互動時,就需要登錄。
社交類:瀏覽其他用戶的公開資料無需登錄,向對方發送好友請求則需要登錄。
購物類:瀏覽商品信息無需登錄,加入購物車無需登錄,下單結算則需要登錄。
四、誰在登錄?
- 正常用戶:新用戶、老用戶
- 假用戶:微商、競品拉用戶
- 非法用戶:詐騙、駭客、‘短信轟炸機’、‘呼死你’
五、怎么登錄?有哪些登錄方式?
- 手機號+驗證碼
- 第三方快捷方式
- 系統賬號通行證
- 中移動“和通行證”
- 賬號+密碼
- 指紋
- 聲紋
- 人臉識別
- 虹膜等其他生物識別技術
第1~4條,新、老用戶都適用;第5~9條,僅老用戶適用。
Ps:本文中,“新用戶登錄”就是指傳統意義的“注冊”概念。
六、登錄環節的目標?
主要分為兩類:①安全問題;②轉化成功率。
1. 企業安全問題
- 第5條中,【駭客】【短信轟炸機】【呼死你】對企業有安全威脅。
- 第6條中,【賬號+密碼】對企業有重大安全威脅。
解決辦法:
- 使用驗證碼登錄,把駭客風險轉移給運營商;
- 對短信驗證碼設定限制,如:30分鐘內最多獲取3條;
- 對語音驗證碼設定限制,如:每天最多獲取10次;
- 去掉‘登錄密碼’概念。
2. 用戶安全問題
- 第6條中,【賬號+密碼】對用戶有重大安全威脅。
- 每年都發生的登錄憑證數據庫泄露事件,讓撞庫登錄的威脅度越來越高。
解決辦法:
- 去掉‘登錄密碼’概念。
3. 老用戶便捷
- 移動互聯網時代,老用戶幾乎是1~2年(換手機)才用一次登錄。
- 登錄密碼使用頻率極低,極易忘記密碼,而找回密碼又太麻煩。
解決辦法:
- 去掉‘登錄密碼’概念。
4. 新用戶轉化率
- 首次登錄,對用戶來說是被迫行為,容易引起反感。操作和步驟越少,轉化率越高。
解決辦法:
- 去掉“注冊”概念,新/老用戶都使用“登錄”。
- 這樣,設置密碼、找回密碼、密碼/驗證碼切換登錄、密碼格式判斷、明/密文開關、登錄行為異常判斷、登錄憑證數據庫安全防護……等這一系列的功能和麻煩不攻自破。
七、總結
賬號體系,是一款App的根骨,只有一次加點的機會,請慎重。
其實,郵箱時代,也是可以使用郵件驗證碼來精簡掉“注冊”模塊的。
登錄——每頁只能有一個焦點
一、新 / 老用戶,登錄入口的默認設定不同
根據上文分析,得出登錄頁面的設計原則:
- 每頁只有一個視覺主焦點;
- 要有不影響主焦點的平行備選方案出口,或異常解決的出口。
- 登錄頁本質,就是讓用戶登錄成功,所以第三方登錄最佳。
- 老板:“手機號,盡量引導一下,但也要兼顧登錄轉化率?!?;
- 產品:“……”
以上原則不包括特殊類型的App:
- 例如滴滴,它必須用手機號為用戶提供服務,所以只能通過手機號登錄。
- 例如婚戀類,沒有性別就沒法向用戶展示任何內容,反而最合適微信登錄(自帶性別)。
在工作中,我學習臻龍大神,用 Axure 寫 PRD。然后又集各家所長,結合自己的一些創新,形成了我自己的PRD風格,如上圖(為了投稿,樣式稍微優化過)。在寫了無數說明文檔、畫了無數流程圖,電子的、紙質的都試過之后,無奈發現開發哥哥們根本不看那玩意兒~~~
開發哥哥姐姐們說:(都是真實回答)
1. 從不看產品文檔,跟著UI圖做,看不懂就去打PM。
2. 太多了,看的眼暈。基本是做一步看一步。
3. 哦,這樣啊~,我是靠著感覺寫的,那我改改。
從產品角度想,PRD的用戶是開發哥哥們,人家不看說明是PRD寫的有問題。遇到問題解決問題,就形成了上圖右側的文檔形式。文檔用兩組 if else,詳解了左側兩個頁面的業務邏輯。這樣的說明文檔,對程序員來說,效率高、邏輯清晰、兼具高可讀性。這些優點,是流程圖和純文字文檔是無法做到的。
當然,細節也很重要,比如:像素級的對齊、【圖二】輸入框中沒有光標…
二、言歸正傳,手機號登錄,如下圖:
第三方登錄無需頁面,常見問題:第三方App未安裝、App互相拉起權限、返回數據異常等等,只需服務器處理異常即可,這里只說手機號登錄:
在這個頁面,輸入框是重點。手機號框,要用很大的字號,并分段顯示。驗證碼框,增加粘貼按鈕,方便Android用戶粘貼。另外,遵循平行備選方案出口原則,在用戶輸入手機號之后,不隱藏掉第三方登錄,只弱化處理。
初始登錄頁到驗證碼登錄頁,一定要使用動效,用動效把兩個頁面連接起來,讓用戶感覺只是同一頁面的微小變化,一切盡在掌握,避免產生負面情緒。
三、獲取驗證碼后,超時未輸入
Android的智能化越來越成熟,但是權限系統也日趨完善。在驗證碼輸入環節,這二者就產生沖突了。在用戶首登時就彈窗索取權限,顯然不太友好。但如果不授權,就無法使用自動填寫驗證碼這樣的功能。這里根據自身情況設定,如果后續會頻繁使用驗證碼,或判斷出是老用戶,則可以先要權限。
接聽語音驗證碼,我將其定義為“解決異常情況的一個出口”,所以默認不顯示,只有短信驗證碼超時未填寫時,才會出現。兼顧頁面整潔和場景需求。
四、登錄模塊的其他頁面
選擇登錄方式時,主流程都未被打斷過,這些頁面當然也不能打斷主流程。
- 左側標簽欄下滑可關閉彈層,右側下滑到頂,繼續下滑可關閉彈層。
- 右側內容區域,上滑到底,繼續上滑可切換左側下一個標簽。
- 雙語為中文和目標國家語言。
- 國家名字太長的,用縮寫。
- iOS 和 Android 的操作列表不同。
- 點擊撥打,跳轉到系統撥號界面。
- 點擊復制,Toast提示復制成功…。
- 用戶協議,每次打開都從服務器獲取網頁內容,不讀取本地緩存數據。
- 文本可滾動,滾動時能查看到文本區域邊界。
五、登錄環節的異常情況
上圖,自動執行時出現的錯誤提示,也要遵循一個焦點原則。
- 圖一,是在輸完11位號碼后,自動檢測號碼格式錯誤,出現的提示,修正后才消失。
- 圖二,是在自動執行登錄時,服務器返回驗證碼錯誤,出現的提示,內容發生變化才消失。
———————————分割線———————————
上圖,手動觸發的錯誤提示。
- 圖一,號碼格式錯誤 or 未輸完,點擊獲取驗證碼?or 登錄,出現的提示,2秒后消失。
- 圖二,驗證碼為空 or 未輸完,點擊登錄,出現的提示,2秒后消失。
- 圖三,倒計時未結束,點擊倒計時,出現的提示,2秒后消失。
———————————分割線———————————
上圖,防作弊與兩種吐司展示
- 圖一,防作弊環節,對轉化率傷害還是挺大的。我在PRD中寫過,如果能收到運動傳感器數據,可判斷為真人,可去掉校驗碼。(傳感器這些基礎權限,系統默認開啟的)
- 圖二,登錄-Loading,不可進行其他操作;全局吐司樣式,2秒。
- 圖三,Android的SnakBar還是挺好用的,建議 iOS 手動實現一下。2秒。
———————————分割線———————————
觸發安全機制導致的登錄信息過期,再次登錄時,需要進行兩種安全驗證才能登錄。
———————————分割線———————————
此處細節還是挺多的,比如:會員時長、相冊、好友、動態、資料,這些信息能否合并?合并后,被解綁的賬號是真刪除還是假刪除?
這些細節,極特殊情況時才需要考慮,比如企業收購導致賬號體系合并。
去年雙十一阿里贈送的優酷會員,需使用支付寶登錄優酷,然而賬號不能合并。結果就是優酷新增了用戶,阿里送禮長了面子,用戶則一臉懵逼。
相信已經是優酷會員的,且之前未綁定支付寶的,誰也沒用過阿里送的優酷會員。
你們是嗎?
以上,登錄環節的異常情況也就差不多了,網絡異常吐司提示即可。權限獲取失敗,前面也提到過,盡量不要在登錄環節向用戶要權限。
iOS 11 暫時還沒研究;Android 方面,華為市場的默認權限不統一,同一分類的App,安裝后,初始權限數量不等,有的多有的少,暫時還沒搞清楚原因。不知是否可以向華為花錢買初始權限,有了解的大神,可以在評論區指點一下,謝謝!
六、登錄頁 – 其他形態
基礎功能不登錄也能使用的App,使用彈層登錄頁更好。注意遮罩的透明度,要保證頁面整潔。
———————————分割線———————————
臨時退出,或者安全機制退出,可用生物識別登錄。疊加使用更安全。
七、探索永無止境
我在PRD中,每個大功能模塊下面都有一個探索頁面,放不同的設計和方案,做 A/B 測試能用到。最主要的還是當做終極力量,威懾程序猿們。
需求這種武器,腦洞有多大,威力就有多大。
對于登錄模塊的探索,有些有意思的資料和想法:
中移動的和通行證:
- 三個功能:一鍵免密登錄(SDK)、本機號碼校驗(SDK)、二次號查詢。
- 這兩套SDK,都需要“撥號”和“讀取本機識別碼”權限。
- 如果你的App默認擁有這兩個權限,用著很不錯,手機號都不用輸,一鍵登錄。
- 小米 MIUI 9 已經全面接入了和通行證,全體系支持一鍵登錄。
- 本機號碼校驗,可用于安全驗證。
- 客服:“目前三網都支持,但是為了保障以后的使用,建議找回各自運營商對接?!?/li>
登錄頁,定制鍵盤:
- 第三方登錄、撥號盤、刪除、清空、粘貼、語音輸入、登錄按鈕,都融合在一個鍵盤上,一點兒也不擁擠,哈哈哈。
- 其實語音輸入手機號,還是很方便的,目前還沒見過有App使用。
八、完結
在實際PRD中,我把每個頁面的內部規則也寫到文檔中。例如:
- 手機號、驗證碼輸入框,只能輸入數字;
- 檢測鍵盤高度,防止遮擋到登錄按鈕;
- 驗證碼為4位數字,30分鐘有效。
- 30分鐘內最多獲取3次驗證碼,且內容相同。
- 每天最多獲取10次驗證碼。
- 不同種類的驗證碼,分別計數。如:語音和短信驗證碼。
- 不同種類的驗證碼,規則不同。如:登錄和支付驗證碼。
- 登錄成功,獲取哪些數據,檢查哪些接口等等。
準備的素材基本用完了,文章結束。
PRD內自用的流程圖就不貼出來了,反正開發大哥大姐們都不看。
本文由 @?微臣有bug要揍 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自unsplash,基于CC0協議
“其實語音輸入手機號,還是很方便的,目前還沒見過有App使用。”第一很多人有口音,語音識別不了的話,會讓用戶有挫折感。第二手機號念出來會暴露個人信息,旁邊的人聽見了記下號碼打電話騷擾你可咋整?能不能提供一套去掉涉密內容的完整PRD文檔?想看看除了登錄注冊,是否還有其他比較細的功能可以學習。
阿里系的風格
換手機號碼了怎么辦?數據怎么找回
沒辦法,但是通過運營商可以檢測二次號,確保數據安全。如果想要找回數據,只能在App內設置其他安全信息,比如實名認證、郵箱綁定、微信綁定。
現在,換號碼是個低頻事件,可以不予考慮。
有兩個問題:1、輸入手機號的時候,手機號合法便自動獲取驗證碼,是不是欠妥,用戶有很大概率輸錯手機號但手機號合法
2、手機號正確,獲取驗證碼后,(在測試的角度)修改之前輸入的手機號,但驗證碼正確,如何反饋
1.大號字體,分段顯示,在原型圖里都有說明,為的就是減少錯誤。如果再做更多反饋,就屬于過度設計了。
2.修改后的手機號,和之前的驗證碼傳給服務器,服務器返回錯誤,則按驗證碼錯誤給用戶反饋,無需做過多處理。
總結,頁面設計和邏輯流程都簡單明了,像第2點這種問題,復用已有邏輯是最好的選擇。