文章介紹了產品設計中在注冊流程和登錄流程兩個方面需要注意的相關規則，了解了這些基本規則，能幫助你的設計做得更好。

自從交易性電子商務開始，就一直有登錄/注冊流程。但是，20年后，我們仍然會犯錯。大多數時候，這些都是由選擇的平臺或用戶體驗偏好造成的。在互聯網上，關于一個組織的決定是否正確、是否對用戶友好、是否符合安全慣例的爭論非常激烈。

登錄/注冊步驟是用戶享受您提供的服務所必須跨越的一大障礙。糟糕的登陸/注冊流程會導致大量的用戶放棄和糟糕的體驗。

今天，我們將嘗試讓所有這些都得到解決，并創建一組簡單的規則，這些規則應在您所有產品的注冊/登錄過程中使用。我們將從簡單的注冊開始，然后到復雜情況下：當我們在另一個操作中到達登錄頁。

設計注冊流程的規則

規則1——只要求填寫創建帳戶所需的基本信息

你只需要一個名字，電子郵件和密碼來創建一個帳戶。如果你有一個強大的短信營銷職能存在，電話號碼對你會很有幫助——但不要強制用戶填寫。你可以晚點再獲取。

如果你的注冊表單超過兩頁，你會引起大量的用戶跳出。

規則2——標記所需內容并將其分組

每個必填字段均應清除標記。 使用*表示必填項并沒有真正的幫助，但是將其標記為（可選）比保留未標記要好。 該訂單應首先是必填項，然后是可選項。

從HTML的角度來看，明確指出輸入中的字段，以幫助瀏覽器自動填充信息。

規則3——指示密碼策略，但僅禁止常用的密碼策略

規則應該是指明密碼的強度，但是如果密碼不屬于常見類別，請不要阻止用戶注冊。 基本原理很簡單-如果他們必須輸入新密碼，他們很可能會忘記該密碼，而下次他們要登錄時，他們會放棄。

規則4-在鼠標離開候發生驗證錯誤時實施內聯字段

最令人討厭的表單輸入是等你填寫完所有詳細信息，然后在表單頂部的列表中顯示錯誤的提示，在此期間，您輸入的密碼消失了（“安全性”）。

使用對人友好的錯誤提示是確保用戶不會中途流失的好方法。

大多數內聯表單驗證都會在我輸入時檢查錯誤。以下是你應該使用的邏輯:

• 在現場等待事件在元素即將失去焦點時觸發
• 驗證字段
• 如果有錯誤，請指出錯誤，但不要將注意力集中在該字段上。（填寫表格時，請不要中斷用戶流程）
• 當用戶將焦點放在錯誤字段上（并且該字段不為空）時，請檢查每個鍵盤輸入事件。如果該字段正確，則將字段變為綠色（但不要在輸入框中四處移動，同時會顯示一條提示該輸入框會移動的消息）。

這樣可以避免驗證過程中的任何麻煩

規則5——禁止訪問未經驗證的電子郵件帳戶

除非是業務需求，否則不要因為用戶沒有點擊你發送的鏈接就阻止他們訪問自己的賬戶。這對于電子商務來說尤其如此——電子商務網站不需要驗證電子郵件地址。對于在線產品，在驗證電子郵件之前，始終可以限制面向用戶的操作。

我發現提供3到5天的時間來驗證電子郵件的服務往往會獲得更多收益。最好在用戶進入門戶網站并要采取某些措施后要求進行驗證。

規則6——不要只表明電子郵件注冊的帳戶已經存在，還要提供措施選項

如果用戶輸入的電子郵件已經存在于您的數據庫中，不要只告訴用戶電子郵件存在。這是一個死胡同。提供原因和行動，用戶可以采取以下措施：

注冊完直接將用戶帶到登錄頁面的網站太可怕了！用戶期望見到像感謝注冊這樣的東西，但他們卻面臨著另一個表單。糟糕的經歷！

如果可能，請嘗試對電子郵件進行內聯驗證。它為用戶省去了輸入其余字段的麻煩。

安全說明：我知道為blackhatter提供API以檢查數據庫中存在哪些電子郵件是愚蠢的，但是如果您很聰明，利用限制或添加設備指紋層來限制調取的次數，可以省去很多用戶迷失在流程中的麻煩。

規則7——社交產品的登錄應該成為常態！

我不知道為什么沒有更多的站點提供單一身份登錄？ 對于像電子商務或產品試用這樣的簡單注冊，facebook / twitter / google注冊是最容易做到的。 但是，在這些規則中，應遵循一些子規則：

1. 覆蓋范圍

不要在交易站點上提供Linkedin賬號注冊。如果您所在的地區擁有流行的SSO權威（例如微信），則可以選擇提供它。

2. 確定優先級

如果可能，請確定最流行的注冊方法?；虬茨钕矚g的方法。

3. 合并

如果用戶使用電子郵件或其他SSO進行注冊，并嘗試與其他用戶進行SSO，請接受它并允許用戶登錄（只要電子郵件匹配）。

4. 提醒

如果用戶使用SSO 進行注冊，并嘗試通過電子郵件再次進行注冊，請指明所使用的SSO。在規則6中，我們看到了重置密碼或登錄的選項-另外，一條消息“您使用Facebook登錄”是提醒用戶的好方法。

5.?隱私

最好指示您將使用SSO僅授權帳戶并僅使用必填字段。而且什么都不發表。

規則8——按tab鍵應轉到下一個字段

雖然聽起來很簡單，但選項卡有時不會引導用戶進入下一個字段。這是預期的行為。測試您的表單，看看是否有鏈接或輸入幫助<a>的標記突出顯示出來。使用tab-index屬性幫助您解決這個問題。

建議1——用戶電子郵箱可以用于用戶登錄識別身份

我在瀏覽你，有用戶名的網站。當然，我今天喜歡用戶名“ThorButOaks69”，但是當它有無數的大小寫和數字的組合的時候，我能記住它嗎？我只記得我的電子郵箱，但不記得用戶名。允許我在登錄后選擇用戶名！

這只是一個建議——您的系統和要求可能有所不同。

建議2——成功注冊后，發送一封歡迎郵件

以下是你的歡迎郵件應該包含的內容——關于他們注冊的網站的信息，他們可以用這個帳戶做什么，以及他們將來會做什么。如果可能的話，可以添加一個電子郵件驗證鏈接，來讓你的CRM團隊開心。

設計登錄流程的規則

規則9——對電子郵箱字段提供內聯驗證

許多站點不采用電子郵箱字段驗證（標準正則表達式）。您的系統發現有電子郵箱格式不正確的信息——請指出！

對于數據庫查找來說，這是一場安全賭博——對于注冊規則6中相同的安全說明也適用。

規則10 -重置密碼應該將電子郵箱帶入新表單

如果你的用戶已經輸入了電子郵件，而你告訴他密碼不正確，那么她不應該在重置密碼階段中再次輸入電子郵件。如果可能的話，快速而簡單地轉換——隱藏密碼字段，并在用戶單擊該選項后將按鈕更改為“重置密碼”。

規則11 -在第三次嘗試時提供密碼重置

如果用戶多次嘗試輸入密碼，只需單擊一次，就可以重新設置密碼。不要讓他們點擊另一個按鈕。

規則12-發送一個密碼重置鏈接，而不是系統生成的密碼

系統生成的密碼在重置密碼過程中添加一個單獨的步驟。重置密碼的過程應該很簡單:

1. 用戶選擇重置密碼
2. 用戶收到一封帶有密碼重置鏈接的郵件
3. 用戶點擊鏈接
4. 用戶輸入密碼兩次
5. 用戶可以訪問該帳戶

看到我們如何跳過登錄再次與密碼選項?我們試圖用再次登錄步驟做什么?鍛煉肌肉記憶?讓自動完成有機會更新記錄?你已經驗證了帳戶的所有權。你不需要重新輸入整個組合!

這就引出了第13條規則:

規則13—允許密碼管理器捕獲用戶的登錄憑證（如果用戶需要）。

現在，大多數用戶都使用這個或那個密碼管理器。只有少數人仍然記得他們使用的上百個網站的電子郵件/密碼組合。密碼管理器已經發展到甚至可以感知重置密碼來更新其文件庫。

規則14—在移動應用程序上，允許用戶使用其設備上的身份驗證來登錄。

如果有一個移動應用程序，強迫你使用復雜的電子郵件/密碼或SSO登錄，這將很荒謬。大多數設備都公開了自己的身份驗證選項（例如指紋ID或面部ID），以使應用程序將其用作身份驗證邏輯。流程如下：

1. 登錄成功之后，提示用戶使用其設備上的身份驗證進行后續登錄。還為用戶提供不再顯示消息的選項。
2. 如果用戶選擇使用身份驗證，則繼續并完成獲取身份驗證的流程。
3. 在下一個登錄表單中，提供將設備身份驗證作為SSO的選項，或者在身份驗證請求中彈出一個模態。

規則15—SSO作為登錄選項

再說一次，這應該是一種規范。應適用第7條的標準規則，并可作以下擴展：

1. 如果用戶試圖使用系統中不存在的電子郵件進行SSO驗證，請輸入相同的密碼并詢問用戶是否要使用該電子郵件創建賬戶。
2. 如果用戶試圖使用存在的電子郵件進行SSO驗證，請進行身份驗證并將其添加到賬戶中。登錄成功后，通知用戶相同的信息。
3. 盡量不要超過3個SSO選項——更多選項將會使用戶感到困惑。我不記得我是否用過Facebook、Google、Twitter還是其他什么。
4. 移動應用SSO——請勿使用帶有登錄選項的Facebook / Google頁面打開應用內瀏覽器進行身份驗證。大多數用戶都有該應用程序——使用Facebook / Google應用程序進行身份驗證。我不想輸入用戶名/密碼組合，只是為了將我從另一個電子郵件/密碼組合條目中拯救出來。

規則16——對于包含敏感信息和付款信息的網站，按常規應該使用兩步認證

這不適用于存儲信用卡令牌的網站，但是如果啟用它會很好。這是針對那些通過信用卡/錢包余額存儲資金的網站。同樣，并非你的所有用戶都擁有信用卡/錢包余額。對那些有可以損失的東西的人實施兩步驗證。例如，如果我剛剛注冊并且沒有綁定信用卡/錢包余額，則無需立即執行兩步操作。將你的流程規則具體化。

在兩步驗證中，最佳組合是：

1. 電子郵件+電話
2. 電子郵件+電子郵件
3. 電子郵件+推送通知

根據我的經驗，最快的是電子郵件+推送。它始終有效。并保持簡單。 Microsoft身份驗證器添加了一個非常愚蠢的步驟，即在數字列表中選擇特定數字。如果我可以訪問兩個設備（登錄設備和驗證設備），則只需輸入驗證消息。不要讓我去解數獨難題！

規則17——理解用戶進入更深流程的認知負擔，為錯誤設計“提示”

隨著身份認證流程變得復雜，很少有用戶會遵循既定路徑。在用戶想結束循環路徑時，提供一個跳出的方式。給與用戶回歸到老式的郵箱/密碼方式的選項。

規則18——長期登錄應該作為非敏感性網站的基本

除非你的網站具有敏感信息，否則就要長期登錄。這一點特別針對電商網站。長期登錄能讓用戶體驗他們被授權的站點和操作。如果你在特定時間后自動退出用戶，那你簡直就是UX罪犯。會話可能會過期，但要保留用戶操作（比如添加到購物車的商品）。在會話過期后，通過密碼提示來限制個人信息的訪問。Amazon這方面就做得很好，保持用戶的部分登錄狀態，只在你需要訪問個人信息時要求認證身份。

如果一個移動APP在一天之后就自動讓我退出登錄，那簡直是荒唐。移動APP需要長期登錄（標準異常應用）。我敢確保沒有公共設備會登錄這種APP。

登錄流程內的規則

有時候，你需要使用戶登錄來簡化后續流程的步驟。下面我們著重電商的支付流程，查看訂單狀態和未付款的購物車。但在此之前，假如你下了一個移動APP，確保來自郵箱/短信的鏈接均為“深層連接”（deep-link）。因為我并不想在已經登錄了APP的移動設備上體驗糟糕的瀏覽器流程。

規則19 ——不要強迫用戶登錄，需要保證用戶不登錄也可以完成任務

在訂單結算的流程中，第一步通常需要用戶登錄或是提供其電子郵箱。視覺上應該優先展示用戶需要結算的選項。流程可以這樣來設計（針對未登錄的用戶）

• 向用戶詢問他們的電子郵件
• 檢查該郵箱是不是已經在注戶系統中存在，然后指導用戶填寫下一步信息。如果用戶已經有了一個賬戶，那就需要激勵他們登錄，并且告訴他們如果登錄的話流程會變得更簡單（這時需要檢查賬戶是否已經填寫地址與信用卡信息）注意：我們不能在同一步向用戶展示所有信息，用戶希望一步步慢慢填寫。
• 如果用戶選擇了登錄，那就彈出一個表單模態并附加單點登錄的選項。因為你已經知道了用戶上一次的登錄方式，那就將上一次的登錄方式展示出來。（注意：這個案例中沒有忘記密碼的選項，因為用戶的行為基本上只是瀏覽一下或者繼續向下進行。）順序可以如下：

• 如果沒有登錄成功，需要禮貌的告知用戶不用擔心，系統已經將交易與該賬號綁定（并且程序實現）。他們需要平滑的過渡回原頁面 – 需要保證用戶是自己關閉的模態彈窗。如果系統替用戶關閉了模態彈窗，則會造成用戶的不悅。

規則20——登錄后，如果用戶有上次會話的內容，則覆蓋它！

想象一下，如果你在雜貨店的結帳臺并提供會員卡時，出納員又向賬單中添加了另外4項商品，是你上次去那里時放到到購物車中的？你會感到厭煩嗎？

當用戶登錄并且未進入結帳旅程之前，合并會話當然很好。再說一次，你不應該只做合并，而是應在購物車中分別標識出它們，并詢問用戶是否要將其添加到他們現有的購物車中，并提供“稍后保存”選項。你的目標是減少客戶在進入結帳旅程之前必須做出的決策數量。

如果您在結帳流程中發現用戶先前的購物車中有物品，請在“謝謝”頁面上顯示這些消息，并顯示一條簡單的消息：“你在先前的購物車中有這些物品，你現在要購買嗎？”。屆時，請將這些物品添加到新購物車中，然后直接將用戶帶到查看頁面。在該頁面上，用戶先前的選擇（如已選擇的送貨地址，付款方式）和購物車總計會顯示出來。他們有權選擇要購買的物品或事保存以備后用。簡化流程。

規則21——在完成主要流程后立即創建帳戶

如果用戶沒有帳戶，最好讓他們在“訂單確認/謝謝”頁面上為其帳戶創建密碼。不要讓他們填寫重復的信息。你已經擁有創建帳戶所需的所有信息，只差密碼。

規則22——訂單狀態鏈接不應要求登錄

用戶可以通過兩種方式檢查其訂單狀態：

1. 郵件中的鏈接——訂單狀態鏈接應與每個訂單確認電子郵件和訂單更新郵件一起發送
2. 允許電子郵件+訂單號組合的表格

有關訂單的其他信息可以保留在登錄提示后。確保登錄后，用戶進入他們打算去的頁面…

規則23——被遺棄的購物車鏈接不應提示登錄

被遺棄的購物車流程很復雜——用戶從已經登錄的瀏覽器訪問鏈接，或者使用URL中的SSID進行會話重新創建——從技術角度來看，這件事顯得非常復雜。

通過專注于一個產品并讓用戶處理該產品來簡化被遺棄的購物車旅程。如果他們的購物車里有商品，把它們顯示為他們可以添加的額外產品。

……

大多數用戶都希望以上內容是給定的。作為產品經理，我們在實施這些技術方面存在一定的局限性，但我可以向您保證，實施這些將給您的網站/應用一個良好的用戶體驗，并提高轉換率。在大多數這些規則上對其嘗試A/B測試，并查看用戶的反應。

原文地址：https://uxdesign.cc/22-rules-for-user-sign-up-sign-in-journeys-e0e863cba40a

本文由 @兔子翻譯組 翻譯發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議