每次想要登錄的時候，發現不記得密碼或者用戶名了……你有試過這種情況嗎？不妨和本文一起探討低頻應用該如何讓用戶記住登錄賬號和密碼。

曉峰一邊幫女朋友搶票，一邊抱怨各種購票 App：“這個智行火車票太惡心了，非要讓你購買加速包，不買的話，把你排40多位，明明票都是充足的……攜程可以幫買下鋪，但我猜是人工幫你買的，因為它說要5點左右才告知購票結果?！毕落伿遣缓觅I，但不是今天的重點，重點是——我問為什么不用12306買呢？曉峰說，“我忘了用戶名密碼了……”

另外一邊，曉娜在部門一個有娃的員工組成的群里問：“醫保報銷的 App，用戶名是啥？”

你可能會說，記住用戶名密碼，本來就是份內的事??！大不了找回密碼，甚至還有1Password 等神器……但折騰用戶不該是產品經理的目標，我們還是要找出這里的設計挑戰。

這兩個場景，背后有一個共同的因素，就是面對的是低頻應用：火車票可能一年也就一兩次，醫保報銷更是只有生病的時候才用。對于這類應用，我們不能把記憶的負擔推給用戶。那么該怎么設計呢？

一、不要讓用戶猜

首先，不要給用戶多種登錄可能，他反而困惑，不知道該用哪一個。

比如12306和海航 App的登錄界面：

12306 & 海航

看到這類界面，我的第一反應就是：“到底當時用什么注冊的……” 然后就開始了類似如下的折騰路徑：

先試用戶名或郵箱，因為我有一個習慣，就是盡量不綁定手機；當輸入常用的用戶名和密碼時，如果報錯，那么麻煩來了：出于安全考慮，眾多 App 不會告訴你是用戶名錯還是密碼錯，你就面臨兩種選擇：

• 是不是該用郵箱或其它方式登錄？
• 還是說這個網站/App密碼規則復雜，不是我常用的密碼？

然而最多再試一次，如果還是沒法登錄，我一般就直接走“忘記密碼”通道了，懶得折騰；而身邊不乏直接走“忘記密碼”通道的同學。

這樣的體驗很挫敗。對于低頻應用，如果可能，盡量明確告訴用戶，該用什么賬號登錄。至少要像微信那樣，默認僅給一種最推薦最常用的登錄方式；如需其它登錄方式，可以點擊專門的“切換登錄模式”按鈕。

如果這么做的話，新問題來了，目前這么多賬號系統，用戶名、郵箱、手機、身份證、社交賬號、企業郵箱，哪一種應該是首選呢？

每一種賬號系統，都有自己的優缺點和適用場景；每一類 App，也都有自己最合適的首選登錄模式。我們分別來看一下。

二、服務本身如何標識用戶，App 就應該以何種標識登錄

前提是在不考慮安全的情況下。

先整體綜述一下。在不考慮額外的安全性要求的情況下，可以應用如下原則來設計用戶友好的登錄系統：

如果服務需要實名，建議用身份證/護照/軍官證等作為首選登錄方式，因為身份信息，用戶總是需要提供的。如：

• 政務類服務：社保，稅務，機動車搖號，違章罰款 （絕對低頻）
• 網銀類 （在支付寶和微信的沖擊下，越來越低頻）
• 酒店航空類 （對大部分人是低頻應用）
• 醫院掛號類

如果服務不需要實名，但需要線下真實的觸達本人，建議用手機號作為首選登錄方式，如：

• 打車類（其實越來越高頻）
• 電商/外賣類（越來越高頻）
• 各種中介類

如果是為企業員工提供服務，建議用員工的企業郵箱作為首選登錄方式，如：

• 補充醫療保險
• 體檢 （一年一次的低頻應用）
• 加班餐 （這個是高頻應用）

娛樂/閱讀/游戲類，建議用社交賬號作為首選登錄方式，如：

• 各類視頻與短視頻 App
• 各類新聞 App
• 各類閱讀 App

這樣就可以在登錄界面直接告訴用戶，用什么信息作為賬號登錄，極大降低記憶負擔；其它的登錄選項都可以隱藏在“切換登錄模式”背后。

再來看一下每一種賬號系統的適用場景。

1.用戶名最不推薦

出乎意料的是，用戶名是最不建議使用的登錄方式，除非你的產品是互聯網的基礎服務，如電子郵件，FTP 等；用戶名幾乎已經完成了它的歷史使命，該退出舞臺了。

用戶名起源于互聯網的蠻荒時代，需要區分不同的用戶，但又僅需匿名即可，正所謂在網絡上，沒有人知道你是一條狗；彼時手機還是高收入人群的象征，并不普及，而網絡服務也是純線上服務，并沒有成為傳統行業的線上入口，因此真實社會中的身份識別系統如身份證等也沒有用武之地，于是與操作系統的賬號概念一脈相承的用戶名便成了最自然的選擇。

然而當越來越多的線下服務線上化，網站和 App 成為連接真實服務的入口后，匿名便不再是選項，交易必須建立在信任之上，用戶必須保證服務提供者能觸達真實的自己；也就是說，此時在網絡上，所有人都必須知道你是一條狗。

所以對于需要線下觸達的服務，可以用該服務所需的身份識別方式作為登錄系統，如打車用手機號，機票用身份證號等。

即使你的應用依然僅要求用戶匿名即可，此時使用社交賬號如微信、QQ、微博等登錄，通常也是一個更好的選擇，注冊門檻更低，且無需記憶，除非你也在做一個競爭性的社交應用。

郵箱也比用戶名要好，因為為了提供找回密碼的功能，總是要綁定郵箱之類的系統。

用戶名的一個優點是提供了一層間接性，比如當你更換手機號的時候，依然可以用原來的用戶名登錄，不會出現連賬號也更換的情況；但同樣，這一層間接的好處，依然可以使用郵箱、微信、QQ、微博等賬號系統部分獲得。

用戶名的另一個好處是私密性，只有你一個人知道，類似 PKI 里的私鑰；身份證手機號等其實都是公開信息，除你本人之外很多人都知道，不夠安全。

2.郵箱好不到哪兒去

如前所述，郵箱是比用戶名更好的選擇，順帶還能提供密碼找回的功能；它的問題在于移動互聯網時代，email 顯得較重，不如手機短信來的方便；其實這也還好，它最大的問題是遠遠不如手機號普及。父輩們可能都有手機，但多少人有郵箱，又有多少人會去用郵箱？如果你的目標是國民應用，相信你不會用郵箱做賬號系統。

3.手機號需要解決用戶換號問題

手機號大多數情況下是比用戶名和郵箱都好的選擇。記憶負擔更小，用戶可能有多個常用用戶名，常用郵箱，但一般最多有兩個常用手機；忘記密碼也可以很容易通過發送驗證短信的方式找回。不考慮安全性的話，每次都通過接收驗證短信來登錄，對用戶的記憶負擔可以降為0，代價是開發商要付出短信成本。

但對于低頻應用，手機號最大的問題是，用戶在更換手機號的同時可能根本記不起有哪些應用是用原來的手機號注冊的；當用戶真正用到那些應用的時候，會發現無法登錄原來賬號了，更糟的是，原來的賬號已經成了別人的，從而引發投訴。

4.社交賬號最輕量

對用戶來說，社交賬號大多數情況下是比手機號還要好的選擇，不用額外的密碼和驗證碼；但對于開發商來說，手機號才是最強的觸達手段，后續多種運營抓手都需要依賴手機號。

5.身份證配實名服務 App

身份證的記憶負擔中等，介于用戶名和手機號之間，通常適用于政務類服務。如下圖北京社保和深圳社保的登錄界面，北京明示用身份證登錄，記憶負擔小很多；深圳用用戶名，一年登錄一次，恐怕要回憶半天。

6.企業郵箱配企業員工服務

強烈建議所有針對企業員工的服務都采用企業郵箱作為首選登錄賬戶：

• 記憶負擔為 0；
• 比手機號穩定，基本不會換，無論你在公司工作多長時間，除非被收購；
• 甚至比工號都穩定，有的公司每過幾年工號就刷新一下；
• 隨時可找回密碼；

如前所述，公司補充醫保，體檢等典型的低頻服務，屬于適用企業郵箱賬號系統的服務。

三、結論

綜合以上信息，對于低頻應用，有如下的賬號設計建議：

• 默認使用服務本身所需的標識作為登錄方式，并明示用戶；
• 至少綁定兩種身份信息，另外一種用于安全驗證，密碼找回和綁定解綁其它身份信息等；
• 其它的登錄選項折疊到“切換登錄模式”背后。

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

題圖來自 Unsplash ，基于 CC0 協議