這個不起眼的「小」功能(登錄),也有這么多門路
這是一篇講「登錄」功能的文章。我相信看到文章的你們對它一定不會陌生,但是,它背后的門道很多,你都知道嗎?
為什么要寫這一篇文章呢?
因為人生之前找工作的時候,面試題有一題是要我畫出登錄流程圖,當時我畫得很差。究其原因是我之前所供職的公司有一個專門的團隊負責用戶數據(包括登錄),所以那時候,我壓根沒有意識到「登錄」的存在感。恰好近期團隊讓我負責登錄功能的開發,于是有了這樣一個「一雪前恥」的機會。
在做登錄的時候,我遇到以下三個大問題:
- 用第三方社交賬號還是自建帳號體系?
- 如何設計登錄流程?
- 如何驗證流程是否合理?
下面一個個部分來講述我的思考。
賬號體系
大家都知道,任何東西存放在別人手里,總讓人覺得沒有安全感,特別是賬號信息這樣重要的東西。而第三方相對于自建賬號來說登錄 / 注冊快捷(掃碼授權即可)、能夠直接獲取一些信息(昵稱、頭像等)。另外,就國內的互聯網環境來說,「3Q 大戰」等事件層出不窮,保不齊某位爸爸不開心,把接口封掉,所有的努力將付之東流。
那么該如何選擇?
我做了如下分析:
- 國內的特殊環境,要求互聯網服務提供方必須要求用戶實名驗證(大家通常用手機驗證);
- 第三方社交賬號登錄比傳統輸入賬號密碼更方便;
- 考慮到公司的業務需要,賬號體系是為整個產品線去服務。
最后我們決定以自建賬號為主,第三方賬號為輔的方式。
那么這樣下來又會有幾個問題了:
- 如何權衡主次?
- 2. 如何決定默認選擇登錄還是注冊?
- 如何將兩種賬號結合
下面是我的思考:
回答一:默認的登錄為自建賬號登錄,第三方登錄只放在一個不怎么起眼的位置。
回答二:根據當前你的產品的用戶曲線和實際產品力來決定,以我們的產品為例,由于賬號體系是首次開發,所以理論上來說,我們的用戶量應該有一個長期且穩定的大量的增長過程,但是考慮到我們屬于某個垂直領域的付費產品,所以我還是決定將登錄放在優先的位置。(相關的案例,可以看看知乎,它將注冊放在優先的位置)
回答三:我們以用戶注冊時輸入的一個唯一的 ID 為主,第三方賬號都綁定在它之下,第三方賬號(包括手機號 / 郵箱)可以修改,但是這個 ID 不可修改。即便用戶使用第三方登錄 / 注冊,也是需要設置此 ID 和綁定手機號。
一句話總結就是:以我的自建賬號為主,這一步你按照規矩好好走,以后都讓你舒舒坦坦。
那么,如何設計登錄流程
第一步明確目標是什么?
上面有說過,我的目標有兩個:實名驗證、為公司產品線服務。結合這兩個重點那么我制作了如下的思維導圖:
通過這張圖,就能很直觀知道你的流程圖中需要有哪些步驟了。
接下來繪制邏輯圖:
以模塊為主來繪制流程圖,避免遺漏,分別是:自建賬號登錄 + 手機驗證檢測(因為有國外賬號需要轉區)、找回密碼、注冊、第三方登錄。
最后的流程圖如圖所示:(因為涉及到一些公司產品的邏輯,所以行了打碼處理,請見諒)
當然有了這一些還不夠,如果有一些極端情況出現,那該怎么辦?例如:手機丟了(或者手機號長時間不用,被注銷)。
如果用戶量不多,讓用戶通過郵件來申訴其實沒有什么問題,但是當用戶量很大的情況下,這無疑是增加了公司的人力成本。所以,我將找回密碼或者解綁(手機、郵箱、第三方)這兩個地方的驗證設置為使用郵箱或者手機驗證通過即可。
接下來就需要你去制作原型圖了,這里就不給出我那跛腳的設計和審美能力啦。
如何驗證整個流程是否合理?
驗證產品是否合理的前提是你的產品邏輯上不能出問題,也就是說,不能有隱患存在。再此基礎上,我們要通過數據驗證這個產品的設計是否合理。
對于一個注冊登錄流程來說,最重要的一點在于用戶轉化,也就是新用戶的注冊率(可粗略估計為:日新增用戶 / 注冊頁面 UV)。有了這樣的一個清晰認識,后面就好辦了。
那么數據怎么得來?
通過你此前在網頁端的埋點。
如果將整個注冊流程看成一個漏斗,統計注冊流程中每一個頁面的 UV ,通過一層層的數據對比,就能看到用戶在流程的哪個階段跳出較多(即用戶流失較多),這樣就能很清晰得出你的注冊流程有哪個地方需要做優化。如圖:
有一點需要說一下,某一天或者某個特殊事件節點的數據不能夠說明問題,數據分析應該是基數越大越有說服力。所以,這就需要你盡可能多的進行統計,并注意關注它的變化。(如果需要匯報,將數據制作成圖表更加直觀)
以上,就是我在設計登錄和注冊功能時的想法??赡軙幸徊糠峙笥巡毁澩业挠^點,但是有一點我需要說明一下,任何功能都不是脫離產品本身而存在的,就像你做生意的時候,需要考慮到國情,什么能做,什么不能做以及該怎樣做。
所以,當你在批評我的時候,請你結合一下我之前的鋪墊(前提條件),覺得我確實有問題,并給出理由(用實例)說服我,我會虛心接受。
制作本文使用到的工具:
- 思維導圖工具:XMind
- 流程圖繪制:OmniGraffle
- 原型圖(這里沒有給出):Sketch
作者:殘照以為記,微信公眾號:以為記(imanlimu)
本文由 @殘照以為記 原創發布于人人都是產品經理。未經許可,禁止轉載。
看不清流程圖啊
流程這個東西,我覺得還是自己來畫一下會比較好,加上為了保護產品信息,所以隱藏了(雖然不是什么很神秘的東西,但是還是需要注意一下),希望能夠理解。
第三方社交帳號登錄實際上就是一個很好的解決方案,但是這個需要根據你自己的產品對于帳號體系的需要來決定,誰主誰次。第三方帳號登錄注冊固然方便,但是有時候還是需要做一些取舍。
?? 有道理啊,樓主大大謝謝你~
最后一句話手殘,打錯字了,應該是「如果你不考慮自建賬號的話」
寫代碼?還是流程?
我還特意往上看了一下前提,之前我也有想過,所以想交流下;
1.有沒有覺著產品的屬性不同,自建賬號體系和第三方登錄體系是有側重點的?并不是所有產品都優先使用自建賬號體系的
2.驗證功能,比如手機號/郵箱的格式驗證,錯誤提示,這些是做在前端的,即使輸入錯誤了也可以減少與服務器的交互,從而減小了網絡的影響
你說的對,不同產品需需要用根據產品屬性,來確定賬號體系的側重點。
提示的交互是實際上確實做在前端的,文章寫的時候,為了保護一些公司內部的消息,所以當時寫文章的時候是重新做了一個思維導圖,沒有去仔細審查,這一點著實不該,謝謝提醒。
你說得對,不同產品需要用根據產品屬性,來確定賬號體系的側重點。拿我們公司的產品來說,就對于自建帳號體系依賴比較重,因為有一整套服務。
提示的交互(像格式判斷之類)實際在開發的時候是做在前端的,寫文章的時候是(純靠印象)重新做了一個思維導圖,沒有去仔細審查,這一點著實不該,謝謝提醒。
沒關系的,都是一個相互交流的過程嘛,我也經常會有不漏的情況
流程圖看不清呢~不止作者大大可否給張清晰的 ??
因為這種流程圖涉及到公司整個產品的登錄邏輯,所以我給打碼了,其實,按照我文章中講到的幾個注意點,你可以自己模擬出來。
明白惹,感謝回復