【譯】註冊與登陸流程的 22 條設計原則

原文連接： https://uxdesign.cc/22-rules-...
做者： Rameez Kakodker
譯者：Chor

自從電商交易出現以來，就一直有登陸/註冊的流程。可是 20 年過去了，咱們依然容易在這件事上犯錯。大多數時候，這都是由平臺的選擇以及用戶體驗偏好致使的。在網上，關於一家公司所作的決定是否正確、是否對用戶友好以及是否符合安全慣例的爭論很是激烈。

用戶要享受你的網站提供的服務，就必須跨越登陸/註冊這一大障礙。糟糕的登陸/註冊流程會致使大量的用戶流失以及不佳的體驗。

今天，咱們將消除全部這些不合理的設計，並給出一系列可用於你產品的登陸/註冊流程的設計原則。咱們先從簡單的註冊講起，以後在行文中間再來討論較爲複雜的登陸事宜。

---

註冊的設計原則

原則 1 —— 只詢問建立帳戶所需的基本信息

建立一個帳戶只須要用戶名、電子郵箱以及密碼就夠了。若是你的服務依賴於短信進行營銷，那麼就須要手機號碼 —— 但不要強行讓用戶給你手機號碼。你能夠稍後再和他們拿。

若是你的註冊表單超過兩頁 —— 毫無疑問會把用戶嚇跑。

原則 2 —— 標明必填項並將它們放在一塊兒

必須清楚標明每一個必填項。用 * 表示必填項其實做用不大，可是這總比你什麼都不標明好。在順序上，你應該把必填項放在前面，可選項放在後面。

<center>正確的字段分組和標識</center>
從 HTML 的角度來講，你須要清楚標明 input （經過這裏所說的自動填充標準）來幫助瀏覽器自動填充信息進字段。

原則 3 —— 標明密碼必須符合的格式，但只拒絕經常使用密碼

這條原則說的是，要標明密碼的強度，但不要因爲用戶的密碼過於不同凡響而阻止他註冊（你只須要拒絕那些爛大街的、不安全的密碼）。理由很簡單 —— 若是用戶須要爲此再想一個新密碼的話，很大機率他們會忘記這個新密碼，下一次登陸的時候，他們會被「勸退」的。

原則 4 —— 實現 內聯字段驗證 & 焦點離開字段後標明錯誤

最噁心的一種表單就是，在你填完全部信息以後，它纔在表單頂部告訴你哪裏填錯了。而每每這時候，你原先輸好的密碼也沒了（爲了「安全」着想）。

<center>使用對用戶友好的錯誤提示不失爲防止用戶流失的上策。</center>
大多數的內聯表單驗證會在用戶鍵入的時候進行錯誤檢查。如下是你應該使用的流程邏輯：

1. 等待用戶的焦點離開字段
2. 驗證字段
3. 若是有錯，向用戶標明該錯誤，但不要讓焦點從新返回該字段（不要打斷用戶填寫表單的流程）
4. 當用戶把焦點放在錯誤的字段上（而且字段非空）時，經過 onKeyUp 檢查用戶的每一次鍵入。若是字段正確 —— 就將提示信息變爲綠色的（不過，不要由於提示信息的更改而挪動輸入框）。

如此一來，你就能夠避免驗證過程當中的各類麻煩了。

原則 5 —— 不要由於用戶沒有驗證郵件而拒絕讓其訪問帳戶

除非商業須要，不然不要由於用戶沒有點擊你發送的驗證郵件而拒絕讓他們訪問本身的帳戶。尤爲對於電商更是如此 —— 電商網站沒有必要驗證電子郵箱地址。對於線上產品，你能夠在用戶驗證郵件以前限制那些面向用戶的操做。

我發現提供 3 到 5 天郵件驗證時間的服務更容易流失用戶。最好在用戶進入網站門戶並打算採起一些操做以後就要求用戶驗證郵件。

原則 6 —— 僅僅提示用戶郵箱已存在是不夠的 —— 還要給出一些選項

若是用戶輸入的郵箱已經存在於你的數據庫中，僅僅告訴用戶「郵箱已存在「是不夠的，這會陷入死衚衕。你應該給出緣由以及用戶能夠採起的措施：

<center>讓用戶在遇到錯誤時總有第二條路能夠走！</center>
用戶註冊後直接把頁面切換到登陸頁的網站太不友善了！用戶期待的是相似於」感謝註冊「的話，但你卻讓他們再填一次表單，這種體驗太差了！

若是可能的話，爲郵箱進行內聯驗證。這能夠省下用戶填寫其他字段的麻煩。

注意： 我知道將 API 提供給黑帽子以檢查數據庫中有哪些郵箱是一件很愚蠢的事，不過若是你足夠聰明的話 —— 可使用節流或者是添加一個設備指紋層來限制 API 調用的次數，這樣能夠給用戶省下很多麻煩。

原則 7 —— 單點登陸應該更加普及！

我有些疑惑，爲何提供單點登陸的網站沒有那麼多？對於電商或者產品試用等網站，經過臉書/推特/谷歌進行登陸是最方便的途徑了。不過，你還要遵循一些小規則：

1. 覆蓋面

   不要把」經過領英登陸「放在一個電商網站上。若是單點登陸在你的地區很常見，比方說微信，那麼你能夠提供微信做爲一個登陸選項。

2. 優先級

   若是可能的話，按照受歡迎程度或者你的偏好程度對登陸方法進行排序。

3. 合併

   若是用戶經過郵箱或者某種單點登陸方法登陸，以後又嘗試使用其它單點登陸方法，你應該接受並容許用戶登陸（只要郵箱匹配就能夠了）。

4. 提醒

   若是用戶已經經過單點登陸進來了，以後又嘗試經過郵箱進行登陸，你應該告訴用戶他已經使用單點登陸了。在第六條原則裏，咱們能夠看到有重置密碼或者登陸的選項 —— 此外，還能夠經過發信息告訴用戶：」你已經經過 Facebook 登陸帳戶了「。

5. 隱私

   最好是向用戶代表，你只會將單點登陸用於帳戶受權、只會獲取必需的字段，而不會上傳其它東西。

原則 8 —— 按下 tab 鍵以後能夠跳到下一字段

聽起來很簡單，可是有時候按下 tab 鍵以後並不會跳到下一字段，這與咱們的預期行爲不符合。測試一下你的表單，按下 tab 以後，看看連接或者輸入框是否能夠高亮。可使用 tab-index 屬性進行測試。

建議 1 —— 讓用戶自主選擇用戶名

沒錯，說的就是大家，那些默認提供用戶名的網站。有一說一，我今天是蠻喜歡「ThorButOaks69」這個名字的，可是過幾天我還會記得這個夾雜各類大小寫英文字母和數字的用戶名嗎？我記得個人郵箱，但我記不住用戶名。在我登陸後請務必容許我選擇本身的用戶名！

這只是個人建議 —— 你的想法和需求可能和我不同。

建議 2 —— 用戶成功註冊後，發送一封歡迎郵件

如下是歡迎郵件應該包含的內容 —— 關於註冊網站的信息，用戶能夠在網站裏作什麼，以及他們未來會得到什麼。若是可能的話，添加一個郵件驗證連接，這會讓你的 CRM 團隊樂開花的。

---

登陸的設計原則

原則 9 —— 爲郵箱字段進行內聯驗證

不少網站沒有爲郵箱字段進行內聯驗證（經過正則表達式）。你須要經過內聯驗證給用戶指出郵箱格式哪裏不正確。

對於數據庫查找來講，這就像是一個安全賭博 —— 在原則 6 中說起過相似的安全問題。

原則 10 —— 選擇重置密碼後在新表單保留原始郵箱

若是用戶輸入的郵箱和密碼不匹配，他可能想要重置密碼。在他選擇重置密碼後，你不該該讓他在表單中從新輸入一遍郵箱。若是可能的話，儘量把這個過程處理得快速簡潔 —— 在用戶點擊重置選項後，隱藏原有密碼輸入框，並將「登陸」按鈕修改成「重置密碼」按鈕。

<center>保留原有郵箱的狀況下實現平滑的轉換</center>

原則 11 —— 在用戶第三次嘗試登陸時提供重置密碼選項

若是用戶不止一次從新輸入密碼，那麼你應該提供單擊重置密碼的選項。不要讓他們點擊其它按鈕。

原則 12 —— 發送密碼重置連接而不是系統生成的密碼

系統生成的密碼會給重置密碼的流程平添無謂的步驟 —— 重置密碼的流程實際上是很簡單的：

1. 用戶選擇重置密碼
2. 用戶收到密碼重置連接
3. 用戶點擊連接
4. 用戶輸入兩次密碼
5. 用戶成功訪問帳戶

你有沒有注意到咱們是如何經過密碼跳過登陸流程的？有什麼必要再走一次登陸流程呢？鍛鍊記憶？仍是讓自動填充功能能夠更新密碼記錄？你已經驗證了帳戶的全部權，不必再輸入帳號和密碼進行登陸了！

說到這，就不得不提原則 13：

原則 13 —— 在用戶容許的狀況下讓密碼管理器捕獲用戶登陸憑證

大多數用戶如今都經過密碼管理器管理密碼。只有少部分人仍然選擇記住本身使用過的百餘個網站的郵箱和密碼。密碼管理器實際上已經發展到可以監聽到密碼重置並更新密碼記錄了。

原則 14 —— 在手機 app 上，容許用戶使用設備身份驗證進行登陸

若是你有手機 app，那麼不該該強制讓用戶經過複雜的郵箱/密碼或者是單點登陸訪問帳戶 —— 這是不合理的。大部分設備都會提供身份驗證選項（好比指紋識別或者臉部識別）來讓 app 做爲身份驗證邏輯進行調用。下面是大體的流程：

1. 用戶成功登陸後，提醒用戶日後能夠經過設備身份驗證進行登陸。同時提供給用戶一個選項用於永久關閉該條提醒。
2. 若是用戶選擇使用設備身份驗證，則經過正常流程獲取身份憑證。
3. 在用戶下一次登陸的表單中，提供設備身份驗證的選擇做爲單點登陸的一個方式，或者是彈出對話框請求身份驗證。

原則 15 —— 將單點登陸做爲登陸選項

一樣的，單點登陸應該獲得普及。原則 7 中所講的內容依然適用，同時還多出了下面的規則：

1. 若是用戶嘗試經過系統中不存在的郵箱進行單點登陸，請明確告知用戶，同時詢問用戶是否想要使用這個郵箱建立一個帳戶。
2. 若是用戶嘗試經過系統中存在的郵箱進行單點登陸，請進行身份驗證並將該單點登陸方式添加到該用戶的帳戶中。用戶成功登陸後，給出和前面所講的同樣的提示。
3. 儘可能不要超過 3 種單點登陸方式 —— 這會讓用戶感到疑惑，他們不記得本身使用的是臉書、谷歌仍是推特。
4. 對於手機 app 的單點登陸 —— 不要在 app 裏打開內置瀏覽器的臉書/谷歌登陸頁來進行身份驗證。大部分用戶都有相應的 app —— 使用臉書/谷歌 app 進行身份驗證便可。我可不想辛辛苦苦避免輸入郵箱/密碼以後，又面臨另外一個郵箱/密碼的輸入。

原則 16 —— 包含敏感信息和支付信息的網站應該推廣兩步驗證

這一原則主要不是針對保存信用卡令牌的網站，而是針對那些經過信用卡/錢包餘額存款的網站。一樣的，並非你的全部用戶都有信用卡/錢包。根據具體狀況決定是否施行兩步驗證。打個比方，若是我剛剛註冊完畢，而且沒有信用卡/錢包餘額，那就沒有必要立刻對我實施兩步驗證了。

兩步驗證的最好組合以下：

1. 郵箱 + 手機
2. 郵箱 + 郵箱
3. 郵箱 + 推送通知

在個人體驗中，我以爲最快的組合是郵箱 + 推送通知。這種方式屢試不爽，並且也很方便。微軟身份驗證器（Microsoft authenticator ）多了一個愚蠢的操做，就是要求用戶在一堆安全代碼中選擇對應平臺的代碼用以輸入設備進行登陸。相反，對於郵箱 + 推送通知這種方式而言，若是我能夠同時訪問兩臺設備（登陸設備和驗證設備），我只須要點擊贊成就能登陸帳戶了。不要讓我玩填字遊戲！

原則 17 —— 瞭解用戶對複雜流程的認知負擔，提供跳出「死衚衕」的出口

隨着身份驗證流程變得愈加複雜，將只有少部分用戶能夠正常完成驗證。若是用戶陷入死衚衕，你應該將他們「解救」出來 —— 讓他們能夠從新選擇本身所熟悉的郵箱/密碼登陸方式。

原則 18 —— 非敏感網站應該推廣永久登陸

除非你的網站保存着敏感信息，不然請容許用戶永久登陸。尤爲對於電商網站更應如此。永久登陸容許用戶在網站上掛機，並保留已採起的操做。若是在必定的時間段以後你自動讓用戶退出登陸，那你會被全部用戶體驗設計師唾棄的。會話可能會過時，但請務必保留用戶的操做（好比添加到購物車中的商品）。會話過時後，你能夠經過密碼對話框限制用戶訪問我的信息。亞馬遜在這點上就作得特別好，它讓用戶保持部分登陸的狀態，僅當用戶須要訪問我的信息的時候才發起身份驗證請求。

若是你的手機 app 僅過了一天就將個人帳戶登出，那你真是太無恥了。除非特殊狀況，手機 app 都應該採用永久登陸。放心，公共設備是不會用於登陸 app 的。

---

流程內登陸的設計原則

[譯註：流程內登陸指的是用戶一開始是以遊客身份瀏覽網站，中途涉及到一些操做流程時才進行登陸]

有時候，你須要讓用戶登陸以簡化後續的流程。這裏咱們拿電商中的結帳、檢查訂單狀態以及遺棄的購物車等做爲介紹的重點。不過，在那以前，若是你的產品有移動端 app 的話，請確保全部來自郵箱/短信的連接都是深度連接。我可不想像傻子同樣在已經登陸的手機 app 上來回尋找你說的那些商品到底放在哪裏。

原則 19 —— 用戶不登陸也能完成流程時，不要強制讓他們登陸

結帳流程的第一步就是登陸或者提供郵箱。流程大體以下（以有帳號但未登陸的用戶爲例）：

1. 詢問用戶的郵箱
2. 檢查系統中是否存在該郵箱，同時將用戶引導到下一步。若是用戶有帳號，提示他們進行登陸，告訴他們登陸後能夠更方便地進行操做（檢查帳戶是否有相關的送貨地址和支付卡）。

   注意 —— 咱們並不會在該步驟中展現提示信息。用戶指望的是隨着本身的操做，天然地看到提示信息。

3. 若是用戶選擇登陸，則打開一個帶表單和單點登陸的模態框。鑑於你已經知道用戶上次是否使用了單點登陸，表單和單點登陸的排放順序以下：

<center>流程內登陸時，模態框中選項的順序</center>

注意：沒有忘記密碼的選項。

4. 若是用戶嘗試登陸失敗，禮貌地告訴用戶，讓他們不要擔憂，你會把這筆交易與他們的帳戶進行綁定（說作就作！）。返回的流程也應該是平緩的 —— 確保是用戶本身關閉模態框，而不是你替他們作主，不然會激怒用戶的。

原則 20 —— 一旦登陸成功，覆蓋以前用戶會話中的項目！

想象一下，你在一家商店結帳，當你拿出積分卡的時候，收銀員在你的帳單上額外加了 4 件上次你在這裏購買的商品。你難道不會以爲噁心嗎？

當用戶在進入結帳流程以前登陸時，你能夠合併先後的用戶對話。但僅僅合併是不夠的 —— 你須要在購物車中把商品單獨分開，同時詢問用戶是否想要把這些以前的商品添加到新購物車中，並提供一個「暫時保存」的選項。你的目的是減小用戶在進入結帳流程以前須要作的決策。

若是在結帳流程發現有以前舊購物車中的商品，請將它們展現在感謝頁面上，並詢問用戶 —— 「您在以前的購物車中添加過這些商品，您是否想要如今進行購買？」接着，將這些商品添加到新購物車，並將用戶直接引導到總覽頁面 —— 該頁面展現了用戶以前的選擇（包括送貨地址和付款方式）以及商品總價。這時候，用戶就可以選擇想要購買的商品和暫時保存的商品了。由此，流程獲得簡化。

原則 21 —— 主流程結束後鼓勵用戶建立帳戶

若是用戶沒有帳戶，那麼在訂單確認頁/感謝頁推薦他們爲本身的帳戶建立密碼再好不過了。不要反覆詢問相同的信息。你已經有了用戶建立帳戶所需的所有信息，萬事俱備，只欠「密碼」。

原則 22 —— 不須要登陸也能查看訂單狀態

用戶應該有兩種方式檢查訂單狀態：

1. 郵箱中的連接 —— 訂單狀態連接應該和每一條訂單確認郵件以及訂單更新郵件一塊兒發送
2. 網站上容許郵箱 + 訂單號組合的表單

其它的訂單信息則能夠在用戶登陸後才容許他們查看。確保用戶登陸後，他們能夠來到本身指望的頁面......

原則 23 —— 「遺棄的購物車「連接不該該提醒用戶登陸

[譯註：「遺棄的購物車」指的是消費者將商品加入購物車，但在沒有進行結帳付款的狀況下就退出的行爲]

遺棄的購物車是很複雜的一個問題 —— 用戶經過已登陸的瀏覽器或者是基於 URL 中的 SSID 重建的會話來訪問連接 —— 從技術的角度來講，這是個很複雜的問題。

要簡化這個流程，能夠將重心放在某個產品並讓用戶處理它。若是用戶的購物車中有商品，能夠將遺棄的購物車中的商品做爲額外的可添加商品。記住，要在具體情境中分析用戶行爲。

---

大多數用戶已經開始期待上述這些交互體驗了。做爲產品經理，咱們受限於實現這些功能的技術餘地，但我能夠向你保證，依照這些原則進行更改以後，你的網站或者 app 將在用戶體驗上得到飛通常的提高，同時也能夠增長你產品的轉化率。基於大部分規則進行 A/B 測試，看看用戶有什麼反應。

---

感謝閱讀！