文章介紹了產品設計中在註冊流程和登錄流程兩個方面需要注意的相關規則，瞭解了這些基本規則，能幫助你的設計做得更好。
自從交易性電子商務開始，就一直有登錄/註冊流程。但是，20年後，我們仍然會犯錯。大多數時候，這些都是由選擇的平台或用户體驗偏好造成的。在互聯網上，關於一個組織的決定是否正確、是否對用户友好、是否符合安全慣例的爭論非常激烈。
登錄/註冊步驟是用户享受您提供的服務所必須跨越的一大障礙。糟糕的登陸/註冊流程會導致大量的用户放棄和糟糕的體驗。
今天，我們將嘗試讓所有這些都得到解決，並創建一組簡單的規則，這些規則應在您所有產品的註冊/登錄過程中使用。我們將從簡單的註冊開始，然後到複雜情況下：當我們在另一個操作中到達登錄頁。
設計註冊流程的規則規則1——只要求填寫創建帳户所需的基本信息你只需要一個名字，電子郵件和密碼來創建一個帳户。如果你有一個強大的短信營銷職能存在，電話號碼對你會很有幫助——但不要強制用户填寫。你可以晚點再獲取。
如果你的註冊表單超過兩頁，你會引起大量的用户跳出。
規則2——標記所需內容並將其分組每個必填字段均應清除標記。 使用*表示必填項並沒有真正的幫助，但是將其標記為（可選）比保留未標記要好。 該訂單應首先是必填項，然後是可選項。
從HTML的角度來看，明確指出輸入中的字段，以幫助瀏覽器自動填充信息。
規則3——指示密碼策略，但僅禁止常用的密碼策略規則應該是指明密碼的強度，但是如果密碼不屬於常見類別，請不要阻止用户註冊。 基本原理很簡單-如果他們必須輸入新密碼，他們很可能會忘記該密碼，而下次他們要登錄時，他們會放棄。
規則4-在鼠標離開候發生驗證錯誤時實施內聯字段最令人討厭的表單輸入是等你填寫完所有詳細信息，然後在表單頂部的列表中顯示錯誤的提示，在此期間，您輸入的密碼消失了（“安全性”）。
使用對人友好的錯誤提示是確保用户不會中途流失的好方法。
大多數內聯表單驗證都會在我輸入時檢查錯誤。以下是你應該使用的邏輯:
- 在現場等待事件在元素即將失去焦點時觸發
- 驗證字段
- 如果有錯誤，請指出錯誤，但不要將注意力集中在該字段上。（填寫表格時，請不要中斷用户流程）
- 當用户將焦點放在錯誤字段上（並且該字段不為空）時，請檢查每個鍵盤輸入事件。如果該字段正確，則將字段變為綠色（但不要在輸入框中四處移動，同時會顯示一條提示該輸入框會移動的消息）。
這樣可以避免驗證過程中的任何麻煩
規則5——禁止訪問未經驗證的電子郵件帳户除非是業務需求，否則不要因為用户沒有點擊你發送的鏈接就阻止他們訪問自己的賬户。這對於電子商務來説尤其如此——電子商務網站不需要驗證電子郵件地址。對於在線產品，在驗證電子郵件之前，始終可以限制面向用户的操作。
我發現提供3到5天的時間來驗證電子郵件的服務往往會獲得更多收益。最好在用户進入門户網站並要採取某些措施後要求進行驗證。
規則6——不要只表明電子郵件註冊的帳户已經存在，還要提供措施選項如果用户輸入的電子郵件已經存在於您的數據庫中，不要只告訴用户電子郵件存在。這是一個死衚衕。提供原因和行動，用户可以採取以下措施：
註冊完直接將用户帶到登錄頁面的網站太可怕了！用户期望見到像感謝註冊這樣的東西，但他們卻面臨着另一個表單。糟糕的經歷！
如果可能，請嘗試對電子郵件進行內聯驗證。它為用户省去了輸入其餘字段的麻煩。
安全説明：我知道為blackhatter提供API以檢查數據庫中存在哪些電子郵件是愚蠢的，但是如果您很聰明，利用限制或添加設備指紋層來限制調取的次數，可以省去很多用户迷失在流程中的麻煩。
規則7——社交產品的登錄應該成為常態！我不知道為什麼沒有更多的站點提供單一身份登錄？ 對於像電子商務或產品試用這樣的簡單註冊，facebook / twitter / google註冊是最容易做到的。 但是，在這些規則中，應遵循一些子規則：
1. 覆蓋範圍
不要在交易站點上提供Linkedin賬號註冊。如果您所在的地區擁有流行的SSO權威（例如微信），則可以選擇提供它。
2. 確定優先級
如果可能，請確定最流行的註冊方法。或按您最喜歡的方法。
3. 合併
如果用户使用電子郵件或其他SSO進行註冊，並嘗試與其他用户進行SSO，請接受它並允許用户登錄（只要電子郵件匹配）。
4. 提醒
如果用户使用SSO 進行註冊，並嘗試通過電子郵件再次進行註冊，請指明所使用的SSO。在規則6中，我們看到了重置密碼或登錄的選項-另外，一條消息“您使用Facebook登錄”是提醒用户的好方法。
5. 隱私
最好指示您將使用SSO僅授權帳户並僅使用必填字段。而且什麼都不發表。
規則8——按tab鍵應轉到下一個字段雖然聽起來很簡單，但選項卡有時不會引導用户進入下一個字段。這是預期的行為。測試您的表單，看看是否有鏈接或輸入幫助的標記突出顯示出來。使用tab-index屬性幫助您解決這個問題。
建議1——用户電子郵箱可以用於用户登錄識別身份
我在瀏覽你，有用户名的網站。當然，我今天喜歡用户名“ThorButOaks69”，但是當它有無數的大小寫和數字的組合的時候，我能記住它嗎？我只記得我的電子郵箱，但不記得用户名。允許我在登錄後選擇用户名！
這只是一個建議——您的系統和要求可能有所不同。
建議2——成功註冊後，發送一封歡迎郵件
以下是你的歡迎郵件應該包含的內容——關於他們註冊的網站的信息，他們可以用這個帳户做什麼，以及他們將來會做什麼。如果可能的話，可以添加一個電子郵件驗證鏈接，來讓你的CRM團隊開心。
設計登錄流程的規則規則9——對電子郵箱字段提供內聯驗證許多站點不採用電子郵箱字段驗證（標準正則表達式）。您的系統發現有電子郵箱格式不正確的信息——請指出！
對於數據庫查找來説，這是一場安全賭博——對於註冊規則6中相同的安全説明也適用。
規則10 -重置密碼應該將電子郵箱帶入新表單如果你的用户已經輸入了電子郵件，而你告訴他密碼不正確，那麼她不應該在重置密碼階段中再次輸入電子郵件。如果可能的話，快速而簡單地轉換——隱藏密碼字段，並在用户單擊該選項後將按鈕更改為“重置密碼”。
如果用户多次嘗試輸入密碼，只需單擊一次，就可以重新設置密碼。不要讓他們點擊另一個按鈕。
系統生成的密碼在重置密碼過程中添加一個單獨的步驟。重置密碼的過程應該很簡單:
- 用户選擇重置密碼
- 用户收到一封帶有密碼重置鏈接的郵件
- 用户點擊鏈接
- 用户輸入密碼兩次
- 用户可以訪問該帳户
看到我們如何跳過登錄再次與密碼選項?我們試圖用再次登錄步驟做什麼?鍛鍊肌肉記憶?讓自動完成有機會更新記錄?你已經驗證了帳户的所有權。你不需要重新輸入整個組合!
這就引出了第13條規則:
規則13—允許密碼管理器捕獲用户的登錄憑證（如果用户需要）。現在，大多數用户都使用這個或那個密碼管理器。只有少數人仍然記得他們使用的上百個網站的電子郵件/密碼組合。密碼管理器已經發展到甚至可以感知重置密碼來更新其文件庫。
規則14—在移動應用程序上，允許用户使用其設備上的身份驗證來登錄。如果有一個移動應用程序，強迫你使用複雜的電子郵件/密碼或SSO登錄，這將很荒謬。大多數設備都公開了自己的身份驗證選項（例如指紋ID或面部ID），以使應用程序將其用作身份驗證邏輯。流程如下：
- 登錄成功之後，提示用户使用其設備上的身份驗證進行後續登錄。還為用户提供不再顯示消息的選項。
- 如果用户選擇使用身份驗證，則繼續並完成獲取身份驗證的流程。
- 在下一個登錄表單中，提供將設備身份驗證作為SSO的選項，或者在身份驗證請求中彈出一個模態。
再説一次，這應該是一種規範。應適用第7條的標準規則，並可作以下擴展：
- 如果用户試圖使用系統中不存在的電子郵件進行SSO驗證，請輸入相同的密碼並詢問用户是否要使用該電子郵件創建賬户。
- 如果用户試圖使用存在的電子郵件進行SSO驗證，請進行身份驗證並將其添加到賬户中。登錄成功後，通知用户相同的信息。
- 儘量不要超過3個SSO選項——更多選項將會使用户感到困惑。我不記得我是否用過Facebook、Google、Twitter還是其他什麼。
- 移動應用SSO——請勿使用帶有登錄選項的Facebook / Google頁面打開應用內瀏覽器進行身份驗證。大多數用户都有該應用程序——使用Facebook / Google應用程序進行身份驗證。我不想輸入用户名/密碼組合，只是為了將我從另一個電子郵件/密碼組合條目中拯救出來。
這不適用於存儲信用卡令牌的網站，但是如果啓用它會很好。這是針對那些通過信用卡/錢包餘額存儲資金的網站。同樣，並非你的所有用户都擁有信用卡/錢包餘額。對那些有可以損失的東西的人實施兩步驗證。例如，如果我剛剛註冊並且沒有綁定信用卡/錢包餘額，則無需立即執行兩步操作。將你的流程規則具體化。
在兩步驗證中，最佳組合是：
- 電子郵件 電話
- 電子郵件 電子郵件
- 電子郵件 推送通知
根據我的經驗，最快的是電子郵件 推送。它始終有效。並保持簡單。 Microsoft身份驗證器添加了一個非常愚蠢的步驟，即在數字列表中選擇特定數字。如果我可以訪問兩個設備（登錄設備和驗證設備），則只需輸入驗證消息。不要讓我去解數獨難題！
規則17——理解用户進入更深流程的認知負擔，為錯誤設計“提示”隨着身份認證流程變得複雜，很少有用户會遵循既定路徑。在用户想結束循環路徑時，提供一個跳出的方式。給與用户迴歸到老式的郵箱/密碼方式的選項。
規則18——長期登錄應該作為非敏感性網站的基本除非你的網站具有敏感信息，否則就要長期登錄。這一點特別針對電商網站。長期登錄能讓用户體驗他們被授權的站點和操作。如果你在特定時間後自動退出用户，那你簡直就是UX罪犯。會話可能會過期，但要保留用户操作（比如添加到購物車的商品）。在會話過期後，通過密碼提示來限制個人信息的訪問。Amazon這方面就做得很好，保持用户的部分登錄狀態，只在你需要訪問個人信息時要求認證身份。
如果一個移動APP在一天之後就自動讓我退出登錄，那簡直是荒唐。移動APP需要長期登錄（標準異常應用）。我敢確保沒有公共設備會登錄這種APP。
登錄流程內的規則有時候，你需要使用户登錄來簡化後續流程的步驟。下面我們着重電商的支付流程，查看訂單狀態和未付款的購物車。但在此之前，假如你下了一個移動APP，確保來自郵箱/短信的鏈接均為“深層連接”（deep-link）。因為我並不想在已經登錄了APP的移動設備上體驗糟糕的瀏覽器流程。
規則19 ——不要強迫用户登錄，需要保證用户不登錄也可以完成任務在訂單結算的流程中，第一步通常需要用户登錄或是提供其電子郵箱。視覺上應該優先展示用户需要結算的選項。流程可以這樣來設計（針對未登錄的用户）
- 向用户詢問他們的電子郵件
- 檢查該郵箱是不是已經在注户系統中存在，然後指導用户填寫下一步信息。如果用户已經有了一個賬户，那就需要激勵他們登錄，並且告訴他們如果登錄的話流程會變得更簡單（這時需要檢查賬户是否已經填寫地址與信用卡信息）注意：我們不能在同一步向用户展示所有信息，用户希望一步步慢慢填寫。
- 如果用户選擇了登錄，那就彈出一個表單模態並附加單點登錄的選項。因為你已經知道了用户上一次的登錄方式，那就將上一次的登錄方式展示出來。（注意：這個案例中沒有忘記密碼的選項，因為用户的行為基本上只是瀏覽一下或者繼續向下進行。）順序可以如下：
- 如果沒有登錄成功，需要禮貌的告知用户不用擔心，系統已經將交易與該賬號綁定（並且程序實現）。他們需要平滑的過渡回原頁面 – 需要保證用户是自己關閉的模態彈窗。如果系統替用户關閉了模態彈窗，則會造成用户的不悦。
想象一下，如果你在雜貨店的結帳台並提供會員卡時，出納員又向賬單中添加了另外4項商品，是你上次去那裏時放到到購物車中的？你會感到厭煩嗎？
當用户登錄並且未進入結帳旅程之前，合併會話當然很好。再説一次，你不應該只做合併，而是應在購物車中分別標識出它們，並詢問用户是否要將其添加到他們現有的購物車中，並提供“稍後保存”選項。你的目標是減少客户在進入結帳旅程之前必須做出的決策數量。
如果您在結帳流程中發現用户先前的購物車中有物品，請在“謝謝”頁面上顯示這些消息，並顯示一條簡單的消息：“你在先前的購物車中有這些物品，你現在要購買嗎？”。屆時，請將這些物品添加到新購物車中，然後直接將用户帶到查看頁面。在該頁面上，用户先前的選擇（如已選擇的送貨地址，付款方式）和購物車總計會顯示出來。他們有權選擇要購買的物品或事保存以備後用。簡化流程。
規則21——在完成主要流程後立即創建帳户如果用户沒有帳户，最好讓他們在“訂單確認/謝謝”頁面上為其帳户創建密碼。不要讓他們填寫重複的信息。你已經擁有創建帳户所需的所有信息，只差密碼。
規則22——訂單狀態鏈接不應要求登錄用户可以通過兩種方式檢查其訂單狀態：
- 郵件中的鏈接——訂單狀態鏈接應與每個訂單確認電子郵件和訂單更新郵件一起發送
- 允許電子郵件 訂單號組合的表格
有關訂單的其他信息可以保留在登錄提示後。確保登錄後，用户進入他們打算去的頁面…
規則23——被遺棄的購物車鏈接不應提示登錄被遺棄的購物車流程很複雜——用户從已經登錄的瀏覽器訪問鏈接，或者使用URL中的SSID進行會話重新創建——從技術角度來看，這件事顯得非常複雜。
通過專注於一個產品並讓用户處理該產品來簡化被遺棄的購物車旅程。如果他們的購物車裏有商品，把它們顯示為他們可以添加的額外產品。
……
大多數用户都希望以上內容是給定的。作為產品經理，我們在實施這些技術方面存在一定的侷限性，但我可以向您保證，實施這些將給您的網站/應用一個良好的用户體驗，並提高轉換率。在大多數這些規則上對其嘗試A/B測試，並查看用户的反應。
原文地址：https://uxdesign.cc/22-rules-for-user-sign-up-sign-in-journeys-e0e863cba40a
本文由 @兔子翻譯組 翻譯發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議