關注交互的細節，是將產品極致化、智能化的必經之路。

目錄

• 一、注冊密碼需要輸入 2 次嗎？
  
• 二、切換注冊/登錄就得重新輸入信息嗎？
  
• 三、注冊一定要等待驗證通過嗎？
• 四、一定要注冊嗎？
• 五、注冊階段的 5 個設計細節建議

一、注冊密碼需要輸入 2 次嗎？

你可能還有印象，過去使用 Windows 的若干年里，每次連接 WiFi 時，都會被要求輸入兩次密碼——這曾經是一種慣例。但很明顯，在用戶登錄時要求輸入兩遍密碼很可笑，并且帶來了不必要的輸入成本。所幸，今天大多數系統都已改良為輸入一次了。

早期 Windwos 的無線密碼需要輸入兩次。來源 Google

登錄時不需要輸入兩遍密碼，那么，在產品注冊時，是否需要輸入兩次密碼呢？

長久以來，為了避免用戶注冊時輸入了錯誤密碼而造成的嚴重不可逆問題，要求用戶輸入兩次密碼也是一種慣例。從銀行開戶的密碼設置到計算機賬戶密碼設置，皆是如此，也應如此。

所以我們已習慣了在設置密碼下方有一個「請確認密碼」的輸入框。

早期微博的注冊界面需要輸入兩次密碼。來源 Google

注冊時要求輸入兩次密碼的 app

這個小小問題的背后，隱藏的是產品開發人員對「填寫錯誤」的擔憂。

事實上，用戶設置密碼出錯并非嚴重問題，因為密碼錯誤導致無法登錄時，只需「找回密碼」即可解決?？紤]這個原因，今天已經有越來越多的產品在創建帳戶時只需要設置一次密碼了。

事實上，與「密碼設定出錯」相比，應該擔憂的是「登錄身份填錯」。

通常來說，注冊系統常見的「登錄身份」有幾種：

1. ID 登錄（如 QQ）
2. 用戶名登錄（如早期的各種 BBS）
3. 郵箱登錄（如各種辦公/SaaS 類產品等）
4. 手機登錄（如各種社交/O2O 產品等）

無論哪種「登錄身份」，一旦在注冊時填寫錯誤，將造成無法逆轉的問題。

特別是在「注冊后自動登錄」的前提下，用戶會在相當長的使用期內，都無法察覺出錯，在更換設備或者身份過期時，造成的后果非常嚴重——不少人遇到的帳號無法登錄，進而使用「找回密碼」時被告知「此帳戶不存在」，都是因此而來。

所以真正的問題是：在注冊過程中，如何確?！傅卿浬矸荨共灰铄e？

1. 輸入兩次「登錄身份」

這是有顯而易見的益處的，在注冊時輸入兩次「登錄身份」（比如輸入兩次郵箱，或者輸入兩次賬號……），能有效地確保身份無誤。

注冊時要求輸入兩次「登錄身份」，以確保無誤。

在網頁端使用確認郵箱的方法比較常見，但是面對移動設備的輸入壓力，確認兩次「登錄身份」（信箱或者手機號碼）的做法并不友善。

2. 通過驗證碼確認「登錄身份」

由于越來越多的產品支持郵箱鏈接驗證，或者手機短信驗證，這相當于對「登錄身份」進行了確認，因此，「登錄身份」可以不用再輸入兩次了。

通過驗證碼可以「登錄身份」不出錯，來源：有妖氣 app 截圖

但驗證郵件可能被送進垃圾箱，驗證短信遲遲收不到這些問題，又進一步增加了用戶的焦灼，無形間提高了注冊成本。

3. 通過二次提醒，確認「登錄身份」

在我們的上一個產品「方片收集」的設計過程中，我將注冊做了一個小小的細節優化，其注冊過程如下圖：

一個優化過的注冊流程 來源：方片收集 app 截圖

• 步驟 1：注冊界面信息越簡越好，除了必要的輸入郵箱、設置密碼沒有其它干擾，點擊「注冊」后進入確認界面。
• 步驟 2：在確認界面，「登錄身份」的信息被放大，用戶很難忽視，而且確認的成本很低——只需點擊即可。
• 步驟 3：自動登錄。

這樣的做法，未增加輸入成本，同時也保證了「登錄身份」的確認，注冊過程比較流暢。

一句話：在注冊時，「登錄身份」非常重要，確保用戶不會因填錯而造成一系列損失。

回想起來，早年能夠意識到「登錄身份」的重要性，我那幾個五位數 QQ 也不會丟失。據說現在五位數 QQ 公開售價已超過了 6 萬，你看，我已經錯過了人生中的第一桶金……

而比起賬戶丟失，用戶更難接受的是賬戶附屬價值的丟失——比如社交關系、資料沉淀等，此時我想起的是自己第一個五位數 QQ 里的女網友……

在注冊流程優化之路上，永遠還有更好的方案，這就需要從「注冊的意義」這個根源上再重新梳理。我在后文中繼續談及。

二、切換注冊/登錄就得重新輸入信息嗎？

當用戶需要注冊/登錄時，默認給出的界面應該是「注冊」，還是「登錄」？

• 答案 A：給出注冊——錯！
• 答案 B：給出登錄——錯！

因為你永遠不知道用戶是需要注冊，還是需要登錄。所以無論哪個，都不對。

拉勾默認是登錄，印象默認是注冊，而 Behance 則呈現的是內容，將注冊與登錄按紐都并列在下面，不做默認。不同的 app 采用不同界面來看，對于所謂默認，未有定論。

圖源：拉勾、印象筆記、Behance 截圖

從我個人經驗來看，考慮到目前 app 領域普遍采取的「長久性登錄」策略，默認為「注冊」也不失為一個具有概率意義的選擇。畢竟大家都通常只會在換機、重置系統、登錄失效、主動退出這些低頻時刻來登錄。

真正的問題在于「登錄」與「注冊」兩種界面切換時，發生的數據丟失。

你一定有這樣的經歷：當你輸入完注冊相關的信箱，密碼，并準備提交時，突然發現原來這是「登錄界面」，而不是你以為的「注冊界面」，于是你點擊了「注冊」。此時，剛剛輸入的信箱與密碼全部被清空——這真是讓人惱怒！

誤以「注冊」是「登錄」導致的切換清空 圖源：印象筆記 Android 版錄屏

如果你將登錄界面誤看作注冊界面，同樣面臨切換時數據被清空的可能。

這種事件機率不高，但可能性不低，而且這是用戶進入產品的一個重要關卡，要引起重視。

1. 確保界面切換時，數據被保留

優化的方案只需要前端將用戶已輸入的數據保留，在「登錄」與「注冊」切換時，自動將兩種界面匹配的數據轉填。

我在設計「水滴清單」時嘗試了這一方案：

切換「注冊」與「登錄」時保留數據 圖源：水滴清單 app 錄屏

2. 避免「注冊」與「登錄」界面混淆

應該注意 2 個問題：

1. 盡量避免「注冊」與「登錄」按紐以「并列關系出現」；
2. 強化「注冊」與「登錄」這兩種界面視覺區別（或者內容區別）。

反例：印象筆記的「注冊」與「登錄」界面視覺區別度太低。

圖源：印象筆記 iOS 版截圖

3. 通過預判斷，設計容錯界面

如果發生了誤判斷，還需要增強容錯——這意味著，盡可能地允許用戶出錯，而不是告訴用戶「你錯了請重新輸入」——因此你很難判斷是用戶錯了，還是系統錯了，更準確地說：用戶永遠沒有錯，如果用戶犯錯，那也是產品的錯。

從注冊/登錄這個細節來看，用戶如果在「登錄」界面輸入了錯誤的信息（比如不存在的帳戶），那么這意味著什么呢？

在上圖中，我們會看到 A 方案的做法是告知用戶「用戶不存在」，這屬于有一說一。當然，出于安全策略等原因，目前更流行的做法是提示「用戶名或密碼錯誤」。

但如果進一步挖掘，就會發現另一種可能性——之所以輸入了「不存在的帳戶」，有可能是將「登錄」誤解為「注冊」。

在這種情況下，以 B 方案的設計確保用戶即使犯錯了，我們可以根據錯誤，輔助其跳往其可能的目標，這將會大大減輕用戶的犯錯成本。當然，也可以提升產品很「聰明」的印象。

4. 單項驗證，分步判斷

還有一種有趣的做法，可以保證少犯錯：如果我們不知道用戶是要注冊還是登錄，可以只給出一個「登錄身份」的輸入框，附帶一個「下一步」的按紐。

然后根據用戶輸入的「登錄身份」的情況來判定登錄或是注冊——甚至直接放棄密碼而使用驗證碼來做為密碼。

總之，確保用戶準確無誤、成本最低地完成「注冊」和「登錄」并非可以忽視的小事，畢竟這是許多產品使用的關鍵入口。

目前有一種新的趨勢就是將「注冊」與「登錄」二合一，或者說無需注冊，直接通過驗證碼來登錄，也是一種不錯的選擇，比如滴滴出行等產品。

接下來，談一談注冊過程中驗證碼的問題。

三、注冊一定要等待驗證通過嗎？

許多產品現在都直接用「手機號碼」或者「郵箱」等「可聯系的形式」作為登錄身份，而不再使用無法聯系到使用者「用戶名」形式。

因此，用戶在注冊時必須證明「所填號碼是自己的」，這就是我們平?？吹降亩绦膨炞C碼（或郵件驗證碼/驗證鏈接）。

通常，我們輸入短信驗證碼，或者點擊了郵箱驗證鏈接后，才能完成注冊。

需要通過驗的注冊 圖源：app 截屏

不過，受到驗證碼供應商以及網絡等條件的影響，驗證碼有時候似乎沒有那么及時。如果讓用戶在這種「不確定性」中等待，是否是明智的選擇呢？

因此，就需要明白驗證的本質是確認「登錄身份」是正確的，可聯絡的。

作為一個產品設計者，我們對驗證碼的理解可能是：

1. 有助于更快獲得用戶的第三方聯絡方式；
2. 從安全性來看有助于密碼找回等身份驗證（接收驗證碼，或接收密碼修改鏈接）；
3. 防止垃圾注冊；
4. 導入社交關系；
5. 為產品傳播，邀請好友等營銷行為埋下伏筆；
6. ……

但這些需求，都是「有利于開發者，有利于未來」，卻并「不利于用戶，也不利于此刻」。

而用戶對驗證碼的理解可能是：

1. 讓我注冊更慢了（因為要等）
2. 讓我注冊更麻煩了（因為要多輸入一行）

因此，我對驗證的理解是：有意義，有價值，但不必此時此刻——完全可以將驗證放置在注冊完成之后的某個時刻，利用虛擬獎勵、功能限制、安全恐嚇等方式激發用戶去完成驗證，以滿足開發者的要求。

下圖是我給出的優化建議。

驗證時機后置的優化

四、一定要注冊嗎？

就個人體驗來說，我最討厭的是啟動后彈出注冊登錄界面的產品——這些產品在安裝之后要求用戶必須登錄方可使用，更糟糕的是它還不提供第三方登錄。

三個必須「登錄」才能使用的例子

除非我已經從別處對這個產品有足夠的了解，否則，出于怕麻煩或者討厭被脅迫的原因，就可能會放棄注冊。

注冊的意義究竟是什么呢？一定是對產品和用戶都有幫助，而不是為了注冊而注冊。

1. 根據產品特性采用最友好的注冊方案

用戶遇到產品，就像談戀愛，最起碼，得先給用戶一個了解和探索的階段——正如你不能要求一個姑娘和你首次見面就去民政局注冊吧？

從功能上看，許多產品也許不需要注冊——或者，最起碼不應該在第一次打開時就要求用戶注冊。

我按產品注冊需求的緊迫程度分了 3 類：

1）無需注冊型

工具型的產品（特指無數據/關系沉淀型），比如匯率計算、指南針、圖片瀏覽、鬧鐘…… 無需注冊就展開使用。除非開發者有進一步的計劃，否則可以先不用急于讓用戶注冊；

2）稍后觸發注冊型

有數據沉淀的工具產品，比如：記事、日程、繪圖、拍照……），可以先通過工具使用和本地存儲讓用戶用起來，然后再通過提醒「數據安全備份」的方式，或者「高級功能受限」的方式，驅動用戶注冊；

對于內容社交類產品（如寫作社區、繪畫社區、垂直行業討論等），可以先通過內容呈現，讓用戶可以單向接收信息，等到用戶產生足夠興趣，計劃上傳信息時，才觸發注冊；

3）立即注冊型

此類產品往往「不注冊就無法使用」，比如：出行類產品、即時通訊類產品、招應聘類產品、票務購買類產品、費用查詢類產品等。

——但事實上，很少有產品真的「不注冊就無法使用」，仔細想想吧。

除了上文提到幾種「登錄身份」注冊方式，使用微信、微博、QQ、Google、Facebook 等第三方身份驗證已經非常成熟了。它的好處很明顯：用戶能以最低成本登錄，而開發者能以最低成本獲得昵稱、頭像、性別、簽名……等一系列信息。

而開發者擔心沒有「自有賬戶」相關的問題，比如第三方失信/用戶失聯問題，完成可以通過「補充資料」的形式解決。

因此，對用戶友好的程度，在我看來，排序如下：

不注冊 > 使用第三方注冊 > 郵箱注冊 > 手機注冊 > 用戶名注冊

2. 限制注冊的策略

雖然注冊要友好，但有時也可反其道而行。

限制注冊、強化注冊難度等不友好的方法，在特殊的情況下，也是一種很好的策略。前面講到，用戶與產品的關系約等于談戀愛，那么在愛情行為中「越難得到越珍惜」的至理名言，同樣適用于產品。

申請制/邀請制注冊：

與普通注冊要求「越簡越好」的原則相反，申請制注冊會增加注冊難度，比如要求用戶填寫足夠多的選項，包括了地址、興趣愛好、甚至需要一段「申請理由」，或者能證明自己確實是產品目標用戶。

用戶為了獲得使用權，必須完成以上要求。在這一過程中，開發者獲得了足夠多的用戶資料，通過批準權對用戶人群進行了篩選；而對于用戶來說，完成這么困難的「申請」會產生「付出感」，將有利于其對產品及其使用權利的珍惜，進而觸發「特權」的感受。

因此，申請制/邀請制的主要目的，是通過饑餓式篩選造成產品的稀缺感、提升產品的價值感、同時激發用戶的付出感、特權感。

在產品冷啟動或者內測階段很有意義。例如二次元產品 bilibili、早期的知乎社區、以及最近的微信「小程序」功能，分別采取的就是申請制和邀請制注冊。

bilibili 要求用戶必須回答 100 道題目后，才能使用產品 圖源-截屏

3. 未來的身份驗證趨勢

無論是注冊，還是登錄，都是為了解決「身份驗證」問題。而在未來，身份驗證也許不再需要，我按自己的推測，將其分為以下三個階段。

階段 1：超級寡頭通過收購與聯盟，將第三方驗證制定為標準化登錄方式

目前的微信、Facebook 都早已是這樣的趨勢了，還包括了風行互聯網多年的 OpenID 等第三方驗證聯盟。

直接以第三方賬號登錄

階段 2：產品身份驗證與底層系統身份驗證合一

比如 iOS 、macOS、Android、Chrome OS、Windows 各平臺都有自己的身份系統，開發者在選擇開發平臺時，等同于默認使用該平臺系統身份證驗證，這樣很可能不再需要獨立的注冊系統。（有創業經歷的朋友可以類比一下國家在工商注冊領域的多證合一，一碼共用）

階段 3：與生物特征結合的驗證方式

傳感設備的進化、用戶對效率的要求提高（或說更懶）、驗證復雜度的提升，以及國家機器對安全和審核的需求……等多種客觀原因加快了生物特征識別時代的來臨。指紋識別、虹膜識別、人臉識別、聲紋識別……等技術，不僅更安全，而且更高效。

也許，免于驗證，才是解決驗證的終極方法。不過，在那個時代來臨之前，我們在「注冊」這件小事上，還有不少的細節需要注意。

以下是我總結的幾個小建議，也歡迎閱讀者能進一步補充提供建議。

五、注冊階段的 5 個設計細節建議

1. 長串數字一定要自動分離

常見于身份證號碼、銀行卡號，電話號等長串數值。自動分離非常有利于核對。

兩個「不分離」的數字 和 微信自動分離的數字

2. 日期的定義要明確

選購出行票務時，將下個月某日當成本月某日而購買了錯誤機票，或者將明天的高鐵當成今天的高鐵，這種事情發生的機率并不低。

一旦出行日期選錯，將會影響用戶出行的一系列后續任務，因此，日期的定義要明確、清晰。

容易造成混淆的日期選擇器

3. 可推算的重復項盡量要通過系統計算

比如：「生日」、「身份證」、「星座」這三個選項很明顯都可以通過「身份證」來推算，讓用戶填寫三次是一種未經思考的愚蠢設計；

再比如：在「銀行帳號」項之后，有一項「賬號后五位」，簡直是莫名其妙。此處特指長沙銀行。

4. 盡量采用數據聯想

有些信息是相對穩定可預知的，「就讀大學」、「申報部委」……等，完全沒必要讓用戶完整輸入，而應盡可能采用數據聯想。尤其是在手機的表單填寫界面，由于輸入體驗不佳，更應如此。

下圖是兩個例子，并非虛構玩笑。

5. 減少冗余操作

對于那些「幾乎是必然的」操作，可以盡量自動化、減少操作步驟。最典型的案例就是早年的「微信支付」和「支付寶」之間的支付密碼交互對比。

微信支付 與 支付寶 的操作步驟對比 圖源 Google

出于安全原因，早期的支付寶「支付密碼」很復雜，相比之下，后來者微信支付的6位數字支付密碼非常便捷。支付寶于 2015 年向微信學習，改變了自己的「支付密碼」策略。

但是！與微信支付相比，支付寶需要在輸入密碼后再點擊一次「確定」，這個小小的動作導致用戶的困擾和抱怨，不久之后，支付寶修正了這個界面，與微信完全一致。

微信支付用短信兩三年時間，幾乎追平了堅守數字支付市場十幾年的支付寶，成績可謂令人矚目。在這場戰爭中，微信除了原有的社交、情境、用戶量等優勢，其對交互細節的重視亦功不可沒。

最后

關注交互的細節，是將產品極致化、智能化的必經之路。這取決于開發者的對產品的態度和對自我的要求。當然，這些細節聽上去更像是吹毛求疵——當然也可以說是畫龍點睛。

對于身份驗證這件事，我們不能只站在開發者「需要什么」的角度，也應該站在「用戶需要什么」的角度去考慮產品交互與設計。

本文的觀察和思考是就「如何將產品做到極致」時的考慮，并不見得在產品的初級版本就需要，恰恰相反，產品的第一階段更需要關注的產品核心功能及其流程進度。

關于究竟在哪個階段做什么事——也就是產品開發的流程，在不同規模，不同行業的公司各有不同。未來，我將分享我們作為一家設計驅動的互聯網創業公司是如何展開設計、生產、開發的，特別是設計師與工程師之間的配合方法與流程。

此外，互聯網早期的匿名化今天已經逐步發展至相當數量的實名制，人們對實名制身份驗證的接受度也越來越高。

不過，人類社會的發展總是物極必反，出于對個人隱私、身份安全、信息泄露恐懼等原因，以及伴隨著暗網、區塊鏈相關技術的發展，也支撐著許多人要求匿名化身份驗證的聲音——確認我是「某個 ID」但無需知道「我是誰」，同時保持足夠友好的身份驗證方式，也許又是未來的新需求。

作者：田飛，方片收集創始人

來源：http://www.ifanr.com/app/783119

本文來源于人人都是產品經理合作媒體@愛范兒，作者@田飛