完美“登錄”,從去掉“注冊”開始
道理太多,先上車,路上慢慢說~
登錄分析
一、什么是登錄?
供多人使用的網站或程序應用系統為每位用戶配置了一套獨特的用戶名和密碼,用戶使用這套用戶名和密碼進入系統的過程,以及系統驗證進入是成功或失敗的過程,稱為“登錄”。
二、為什么要登錄?
登錄成功后,系統能識別該用戶的身份,從而保持該用戶的使用習慣或使用數據。
三、什么時候需要登錄?
當前操作/行為與服務器發生雙向互動時,就需要登錄。
社交類:瀏覽其他用戶的公開資料無需登錄,向對方發送好友請求則需要登錄。
購物類:瀏覽商品信息無需登錄,加入購物車無需登錄,下單結算則需要登錄。
四、誰在登錄?
- 正常用戶:新用戶、老用戶
- 假用戶:微商、競品拉用戶
- 非法用戶:詐騙、駭客、‘短信轟炸機’、‘呼死你’
五、怎么登錄?有哪些登錄方式?
- 手機號+驗證碼
- 第三方快捷方式
- 系統賬號通行證
- 中移動“和通行證”
- 賬號+密碼
- 指紋
- 聲紋
- 人臉識別
- 虹膜等其他生物識別技術
第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協議
天吶,這么細致,一個登陸得寫上半天吧~收藏了~
至少三天吧 ?
好想知道…開發周期是多久….
在用戶還沒有輸入完就按照輸入格式錯誤來出現錯誤提醒 是一種很不友好的交互方式
是的,那樣體驗不好。
所以,你再仔細看看圖。
我想問一下,手機號 密碼登錄的方式。更換手機號你有什么好的處理方式。用戶賬戶下有購買的權益和訂單信息。
綁定新號碼,解綁舊號碼。
或者把手機號、微信、QQ設定為同等級,至少需要綁定其中一個才行。
手機驗證碼也會有風險嗎?
對于企業來說,風險就是被轟炸利用。
請問這PRD書寫方式,公司的態度是怎樣的。。。
公司又不管具體工作方式,只要團隊配合效率高就行
1.驗證碼安全問題,僅僅讓運營商限制次數是不夠的。更高級的防刷機制是圖形驗證碼之類的。
2.第三方登錄實際上為偽登錄(偽注冊)環節,事實上,第三方進去成功進入你家產品的時候,還需要填寫相關的信息。為了獲取用戶數據這個步驟自然少不得。所以可以理解手機號的不可缺少的重要性。自然賬號密碼可以省掉也是演變趨勢。
3.嗯,謝謝分享,一起學習。
1.短信安全方面,不是讓運行商限制短信次數,而是在自己后臺,按設備或手機號限制次數。還有,防刷校驗碼,上面也貼圖了,但這東西確實影響體驗,能不用還是不用好。起碼第一次不能出現,如果頻繁獲取驗證碼或登錄接口,再出現也不遲。
2.關于偽登錄,最好還是在進入App之后,結合實際需求,再向用戶索取手機號。像那些微信登錄后緊接著要手機號的,我認為已經屬于欺騙了,起碼和預期不符,不生氣才怪。
3.果然,現在社會,問題比答案更值錢,和你交流,讓我想到幾個可以改進的地方。謝謝,我再去優化一下。 ??
驗證碼之前被轟炸的很厲害,技術出身,嘗試著對手機號碼,和后臺傳輸信息進行2次加密,不用加圖形驗證碼,再也沒有被轟炸成功過
這個就厲害了,我記一下
如果大神能再詳細解釋一下,就更好了 ??
大神,能解釋一下怎么二次加密么?沒想明白。
請問下在新用戶手機號登錄時,點擊灰色按鈕,比如“倒計時”為什么要有反饋呢?灰色按鈕不是本來就是給用戶不可點擊的暗示嗎?
求大神解答~
灰色按鈕代表不可點狀態,這個邏輯單獨看是沒問題的。
但是把它放進一個更大的環境中,就不夠完整了。
你告訴了用戶這里有問題(不可點),但是沒告訴用戶怎么去解決(等待or轉語音)。
昨天琢磨你這個問題,我又想到一點可優化的地方,哈哈,謝謝
贊!收藏了!
謝謝 ?? ??
賬號和密碼,風險大的話,那為什么現在的qq還是用帳號密碼登錄呢?
QQ的根骨已經長成,沒得辦法呀~
想當年,盜QQ號都能形成產業鏈….
pro還可以這樣寫,受教了
哈哈哈,可以稱為 Pro 版 PRD …
流程圖給個下載地址唄。
?? 流程圖…除去異常頁面,總共不到10個頁面,流程圖太簡陋了,所以才沒好意思貼出來…
非常好的資料??
?? 很榮幸能對你有幫助
溜了溜了 ??
哈哈哈,謝謝 ??
66666666666 這種方式,學到了, 如果能分享下原型就好了
?? 原型里的頁面已經都貼出來了,自己整理一下啦~
這是Ax原型??
是的,Axure原型
綁定合并的問題,是否有過客訴?合并的兩個賬號均為非空賬號,對于該賬號的原有數據比如照片等等,用戶后面有沒有對應的流程可以找回?
賬號合并部分,并沒有用于實踐。
個人認為還是根據實際情況決定怎么設計吧,如果是不涉及重要資料、重要資產的App,合并也無所謂。
如果實在重要,也可以加一個銷毀期限,像QQ號和手機號的回收那樣,過期/欠費后,再給個回收期。時間到了徹底清除賬號信息,可以把這個寫到用戶協議里面去。
有原型可分享一份嗎?
登錄環節的原型頁面已經都貼出來了
很棒啊,很細致
?? ??
想的非常細致,標注也很新穎實用。贊?。。?/p>
謝謝 ?? ?
寫的很棒,值得參考 ??
謝謝 ?
很棒很棒~
謝謝
?? 謝謝謝謝!
天吶,這是政治錯誤,我得趕緊改…
。。。
直接用AXURE設計動態效果不就好了么,這樣一個頁面一個頁面的展示說明太浪費時間了,而且沒有動態效果來的直接。
—-產品新手一枚,求解答(無意冒犯?。?/p>
扁平化是提高效率的,沒有浪費時間。如果模塊太大,分成小模塊平鋪展示。
我在PRD中還有類似目錄的分類指引性標記,并不是鋪展開一大片。
我就想知道設計一個產品的登錄你需要畫多少個頁面,設計多少個交互。
頁面數量倒是不多,加上細節,40個頁面左右。
但是改的次數比較多,第一次做完,放兩天,再看一遍,鐵定有更好的方案。這樣改個兩邊,差不多就是最終方案了。
沒有了賬號密碼等亂七八糟的東西,那就要把修改手機號等功能做的更簡單、方便。
修改手機號,兩個環節:
1. 確認身份;(原手機號的驗證碼,或者用第三方登錄、郵箱、生物識別技術,來確認是本人使用)
2. 設置新號碼。(新號碼的驗證碼)
這樣看的話,應該也挺簡單,不會產生什么意外流程。
看~看不懂就去打PM!??!
全文就調皮了這一句,都被你發現了 ??
詳細 專業 不過我只關注了了一個,取消賬號+密碼 哈哈哈哈
是吧,哈哈哈!
去掉之后,真的很爽,大家都很爽。
產品、UI、開發、測試、用戶,都省事。
開發和用戶并不省事。 只提供手機驗證登錄加重了維護成本和運營成本,用戶并沒有覺得省事(有做過調研,手機信號,短信攔截,查看驗證碼再進行輸入,這些都是問題)
?? 你這是在哪看的調研數據呀?
0.開發不省事,如果是自己架設短信驗證碼服務器,確實不省事。但用戶一定是省事的。
1.成本確實有,但我認為這是合理的開支。而且,注冊的時候,你不用驗證碼嗎?
2.短信攔截不存在,如果存在,那是企業自己的問題。
3.查看驗證碼,Android都可以直接復制,iOS可以一邊看一遍輸入,沒有麻煩的地方。
反過來看:
注冊環節,去掉登錄密碼,不讓用戶選擇注冊還是登錄,等等,這一定是省事的。
登錄環節,如果用戶忘掉密碼呢?驗證碼一定是比找回密碼省事的。
自己的用戶調研過。所有我們提供了賬號密碼登錄+驗證碼登錄+第三方登錄3種方式。
你說的沒錯。這種有利有弊,所以不是應該給予用戶選擇。簡化并不是替用戶做選擇。登錄方式應該由用戶自己的喜好和習慣去選擇。
你上面的設計中直接就把賬號密碼登錄砍掉了。這個太絕對了。
這個簡單,可以看看活躍用戶的數據,來驗證他們有沒有在調研中真實的傳達了自己的想法,也就是看看他們是怎么做的。
比如可以看一些這樣的數據:
1.手機號注冊和第三方注冊的比例。
2.找回密碼總次數 / 密碼登錄總次數 = 忘掉密碼的用戶的比例。
說實話,我連我自己支付寶的登錄密碼和網頁支付密碼都不知道。還有,我常用的十幾個App,最近一年從來沒使用過退出功能…
這個我們自己的產品已經驗證過了。賬戶密碼登錄還是占最大的,驗證碼最低。不知道你這個設計是否已經上線檢驗過了。
檢驗過,登錄環節,不區分登錄和注冊。
首次登錄時,無需設置登錄密碼,登錄之后,可以設置登錄密碼。妥妥的沒問題,各項數據都有提升。
是的,現在需要記住的東西太多了,但大家又越來越懶了,所以傻瓜式操作,才是后續的主流,簡單操作,從注冊開始,哈哈哈,
內容很好,棒棒噠
謝謝
看完兄弟的Axure文檔,再看看我弄出來的線框圖,我決定棄用Axure了
你平時用什么呀?
規范一下元件尺寸,加個圓角,認真對齊,就是我這樣了。
簡單點的用墨刀,復雜點的用Mockplus,想要高保真就sketch畫完在用墨刀的插件導出做效果
寫得不錯!
謝謝