UX 和 HTML5：讓我們幫助用戶填寫您的移動表單（第 1 部分）

表單是用戶與您的網站（和移動應用程序）進行的最基本的主要交互之一。 他們將人們聯繫在一起並讓他們交流。 他們讓他們評論文章並向作者解釋他們如何強烈反對他們所寫的內容。 他們讓人們直接在約會應用程序上聊天以結識“那個”。 無論是論壇、產品訂單、在線社區、賬戶創建還是在線支付，表單都是用戶在線生活的重要組成部分。

現在是 2018 年，在全球範圍內，我們的移動用戶數量超過了桌面用戶。 然而，我們仍然將這些用戶視為網絡的二等公民。 每個人都在寫和談論用戶體驗。 那麼，為什麼，為什麼，為什麼這麼多網站和產品仍然做錯了。 為什麼他們的移動用戶體驗會損害半個世界？ 為什麼現在仍然很痛苦，為什麼現在預訂航班和以移動形式註冊帳戶仍然超級困難？ 用戶期待更好！

推薦閱讀：萬維網，不是富裕的西方網絡

這是兩篇系列文章的第一部分。 在這篇文章中，我將總結一些基本的最佳實踐來改進您的移動表單，包括可掃描性和可讀性。 我將指導您完成標籤和輸入放置、大小和優化。 我們將看到如何選擇正確的表單元素來降低交互成本。 最後，您將學習如何預防和處理移動表單上的錯誤。

在第二部分，我將仔細研究特定的移動功能和 HTML5 表單元素，我們將超越經典的表單元素，製作獨特而有趣的 Web 應用程序和網站。

注意：雖然本文中的大部分代碼增強都與 Web 相關（因為我不了解 Swift 或 Java），但可用性最佳實踐適用於移動應用程序。

表單設計 101：優先考慮可掃描性和可讀性

“表單是名稱、值、對，在一種結構中，用於在計算機上存儲數據，這些數據作為標籤和人類的輸入字段被吐出。” 這是 Luke Wroblewski 在一次會議上的直接引述。 和他一樣，我相信大多數表單可用性問題都來自這種為用戶提供數據庫結構的傾向。

強大的信息架構

要構建更好的表單，您首先需要遠離數據庫的結構。 嘗試了解用戶希望如何填寫表格。 這就是對錶單進行一些可用性測試和用戶研究變得方便的地方。 用戶心智模型是一個 UX 概念，可以幫助您。 尼爾森諾曼集團將其描述為“用戶對手頭系統的看法”。 請您的測試人員大聲思考並告訴您他們將如何填寫表格。 他們期望哪些步驟？ 什麼先來？ 接下來是什麼？ 這將使您更好地了解如何以更用戶友好的方式構建表單。

視覺上對屬於一起的字段進行分組也將幫助用戶填寫表單。 在代碼中，使用fieldset標記以編程方式對它們進行分組。 它還將幫助屏幕閱讀器理解層次結構。

如果表單很長，默認情況下不要公開所有內容。 對你展示的東西要聰明。 明智地使用分支來僅顯示人們需要的字段。 例如，在結帳表單中，不要顯示所有發貨選項的所有詳細字段。 這將使用戶不知所措。 顯示足夠的信息以幫助他們選擇正確的運輸選項。 然後，僅顯示與該選項相關的詳細信息和字段。

用戶的注意力會隨著時間的推移而變短：在表格末尾詢問可選的內容。 例如，如果您的表格是客戶滿意度調查，請在最後詢問人口統計信息。 更好的是，如果可能的話，自動填充它們。 僅向用戶詢問必要的內容。

最後，提前計劃本地化：當您的表單被翻譯後會發生什麼？ 比如說，對於德國人來說會發生什麼？ 你的設計還能用嗎？

標籤放置和輸入優化

單列佈局效果最好

由於空間不足，您無法在移動屏幕上放置標籤和字段：

• 以單列佈局呈現字段。 移動設備上沒有多列的空間。 無論如何，多列表單在桌面上也不是一個好主意。
• 在縱向模式下，最好將標籤放在字段頂部，以便用戶在鍵入時可以看到字段中的內容。

• 在橫向模式下，屏幕的高度會降低。 您可能希望將標籤放在左側，將輸入放在右側。 但是測試它以確保它有效。

有關標籤放置的更多信息，請參閱 Baymard Institute 的“移動表單可用性：在字段上方放置標籤”。

標籤應該清晰可見，並且可以在沒有上下文的情況下使用

請記住，一旦某個字段獲得焦點，鍵盤就會打開，並且至少會佔據屏幕區域的三分之一。 在小型移動屏幕上，用戶還必須滾動才能填寫表格。 這意味著他們在填寫表格時會丟失部分上下文。 相應地計劃：

• 您的標籤應該是清晰可見的文本，可以在沒有上下文的情況下閱讀和理解。 用戶應該能夠將每個標籤和字段對作為單獨的任務完成，即使他們失去了上下文。

• 盡可能避免使用行話、縮寫和行業特定語言。
• 始終如一。 如果您在標籤中使用過一次“客戶”，請堅持使用該詞。 以後避免使用“客戶端”，因為它可能會使用戶感到困惑。
• 字體大小應該足夠大。 盡快在真實設備上測試您的表單，並相應調整大小。
• 對於某些用戶來說，全大寫文本可能難以閱讀。 您可能希望避免在標籤上使用全大寫文本。
• 標籤副本應簡短且可掃描。 如果某個領域需要澄清，請不要將其放在標籤中。 請改用字段描述。

輸入大小最佳實踐

如果可能，輸入元素的大小應該與預期內容的大小相匹配。 這將幫助用戶快速填寫表格並了解預期內容。

使用掩碼避免在移動設備上拆分輸入

不要僅僅為了格式化而拆分輸入。 在移動設備上尤其煩人，用戶無法使用鍵盤在字段之間導航。 它需要額外的點擊才能轉到下一個字段來填寫表格。 您可能會想，“但是當我在該字段中獲得所需數量的字符時，我會自動將焦點放在下一個字段上”。 那可以工作。 但是您將控制 UI，這對於用戶來說變得不可預測。 此外，如果您自動將它們發送到下一個字段並且他們需要更正最後一個字段中的某些內容，那將是一件痛苦的事情。 最後，猜測拆分輸入的強制要求更加複雜。 所以，讓我們停止玩“但是如果”遊戲，不要拆分輸入。

我明白了：您仍然希望能夠將用戶數據格式化成小塊，以幫助他們填寫您的字段。 你是完全正確的。 為此，您可以使用 mask 。 無需拆分輸入，只需在其頂部放置一個遮罩，以直觀地幫助用戶填充它。 這是一個幫助用戶填寫信用卡字段的面具的視頻示例：

掩碼通過引導用戶使用正確的格式來幫助防止錯誤。 避免逐漸暴露它們——直接顯示格式。 另外，避免在 mask 中放置假值。 用戶可能會認為它已經被填滿了。 這就是為什麼我在演示中將數字替換為一個小“X”。 找出最適合您的輸入類型的方法。

最後，請記住，某些數據可能因國家/地區而異，有時格式也會發生變化（例如電話號碼）。 相應地計劃。

高效字段說明

顯示有​​效的字段描述可以在無縫和痛苦的表單體驗之間產生差異。

描述可以用來做什麼？

描述可以通過多種方式幫助用戶。 這裡有一些例子。

• 你到底要什麼？
  

  無論出於何種與數據庫相關的原因，一些貨運公司都會要求提供“地址 1”和“地址 2”字段。 這對用戶來說非常令人困惑，但您可能在這裡別無選擇。 添加描述字段以幫助用戶了解他們需要在每個字段中輸入的內容。

  

  首字母縮寫詞和縮寫詞也是如此。 我知道我說過你應該避免它們，但有時你不能。 例如，如果您為特定行業處理複雜的表格，它們可能有自己的一組縮寫。 任何需要填寫表格的新用戶可能（還）不熟悉這些縮寫。 在某處提供描述將對他們有所幫助。

• 為什麼需要這些信息？
  如果用戶不了解您為什麼需要它以及您將如何使用它，他們可能不願意向您提供個人信息。 但有時您仍需要出於法律原因要求提供此類信息（例如銷售酒類的網站的出生日期）。 在此處使用字段描述將幫助用戶理解為什麼需要此類信息。
  
  

  在電子商務網站上，您可能需要詢問用戶的電話號碼，以防送貨員需要聯繫他們。 這是一個正當的理由。 因此，再次使用描述向電子商務用戶解釋為什麼您需要他們的電話號碼。

  

“我在哪裡可以找到信息？”
如果您的用戶需要在其他地方找到某些信息才能填寫表格，請告訴他們在哪裡可以找到它。 我開發了一個移動應用程序，讓用戶可以跟踪他們的房子。 用戶需要使用序列號將應用程序與監控設備配對。 在設備上找到這個序列號並不容易； 它需要一些指導。 我們加了一點？ 序列號字段旁邊的按鈕。 該按鈕打開一個顯示圖片和一些指示的模式，以幫助用戶了解在哪裡可以找到監控設備上的序列號。 電子商務網站對促銷代碼也是如此：它們提供指示符，告訴用戶在哪裡可以找到代碼。



• “我應該如何格式化信息？”
  有些字段需要特定的格式。 在這種情況下，使用描述讓用戶預先知道格式規則。 這裡有一些例子：
  • 電話號碼：我需要在字段前面輸入國際撥號代碼（+xx）嗎？
  • 有最大長度嗎？ 移動端的 Twitter 在這方面做得很好。
  • 處理貨幣金額時，格式是逗號（如 10,000）還是空格（如 10,000）？
  • 您期望日期的格式是什麼？ 我會讓你在維基百科上查一下那是什麼噩夢。 DD MM YY 和 MM DD YY 之間的差異可能會給用戶在在線預訂時帶來*很多*的麻煩。
  請注意，許多格式問題可以通過輸入掩碼解決。 我們將在本文後面討論（或者如果您不耐煩，可以直接進入）。

  

如何顯示說明

在上面的示例中，我們看到了幾種顯示字段描述的方法。 以下是要執行的操作的摘要：

• 內聯描述應直接可見並顯示在字段旁邊。
• 如果您需要更深入的內容描述，您可以使用tooltips 或 modals 。 工具提示通常在桌面懸停和在移動設備上點擊時觸發。 模式也是如此：例如，當用戶點擊幫助圖標或“查看更多”鏈接時打開它。

小心佔位符

我明白了：刪除移動設備上的字段以獲得空間並改用佔位符是很誘人的。 我們都走上了這條路。 但請不要。 HML5 規範對此很清楚：“佔位符屬性表示旨在幫助用戶輸入數據的簡短提示（單詞或短語）”。 這就是為什麼：

• 當用戶開始輸入時，佔位符消失。 然後，用戶必須依靠短期記憶來記住他們應該在字段中輸入的內容。 如果他們不能，他們將需要清空該字段才能看到指示。
• 用戶在提交之前很難仔細檢查字段，因為字段不再有任何標籤指示。
• 一旦提交了字段，就很難從錯誤中恢復，因為同樣沒有標籤可以幫助用戶。

即使您使用帶有標籤的佔位符，您仍然可能會遇到一些問題。 很難區分填充字段和帶佔位符的字段。 我是一名 UX 設計師，撰寫有關移動表單設計的文章，甚至上週我也被其中一個人欺騙了。 如果它發生在我身上，它也會發生在你的用戶身上——相信我。 最後，大多數佔位符都有淺灰色文本，因此您可能也會遇到一些對比度問題。

如果您想更深入地了解這個主題，有一篇很棒的文章，名為“Placeholder Attribute Is Not A Label，還有 Joshua Winn 和 FeedbackGuru 詳細介紹了為什麼這是一個壞主意。 Nielsen Norman Group 還寫了一篇關於該主題的文章，名為“表單字段中的佔位符是有害的”。

佔位符在 HTML5 中不是強制性的。 從可用性的角度來看，您當然不需要在表單的每個字段中都使用佔位符。 但是隨著 Bootstrap 和其他框架的大量採用，看起來很多人只是複制和粘貼組件。 這些組件有佔位符，所以我想人們覺得有義務在代碼中的佔位符中添加一些東西？ 如果表單的佔位符看起來像“請在此處填寫您的標籤”，那麼您做錯了。

儘管如此，字段內的標籤對於字段可預測的短格式仍然可以很好地工作。 登錄表單是一個很好的選擇。 但請不要使用 HTML5 佔位符來編碼。 在代碼中使用真正的標籤並使用 CSS 和 JavaScript 移動它。

自從 Android 的 Material Design 成功之後，一種模式開始出現：浮動標籤。 當字段未填寫時，此標籤位於字段內，因此在移動設備上佔用的垂直空間要少一些。 當用戶開始與字段交互時，標籤會移動到字段上方。

這看起來是一種有趣的方式來獲得一些空間，而不會遇到上面提到的“佔位符代替標籤”問題。 然而，它並沒有解決用戶可能將佔位符誤認為填充內容的問題。

成功表單的交互成本降低

降低用戶完成任務的交互成本（即點擊次數、滑動次數等）將幫助您構建無縫的表單體驗。 有不同的技術可以實現這一目標。 讓我們詳細看看其中的幾個。

互聯網上的一項神奇研究告訴我減少字段的數量

更多字段意味著更少的轉化，對吧？ 您可能已經遇到過“我們將訂閱表單從 11 個字段減少到 4 個字段，並將轉化率提高了 160%”的研究。 這是一個經典。 而且，如果您查看他們的聯繫表格，那是有道理的。 為什麼用戶要填寫 11 個字段只是為了聯繫公司？ 你不能要求那些幾乎不認識你的人做出這麼大的承諾，對吧？

首先只詢問有用的信息。 為什麼需要一個人的性別才能為他們創建帳戶？ 如果您的訂閱表格是針對在線服務的，為什麼地址有兩行？

只詢問您需要的信息。 然後在上下文中詢問信息。 如果您有一個電子商務網站，與註冊時相比，用戶可能更傾向於在結帳過程的運輸部分向您提供他們的地址。 它將使您的電子商務註冊表單在移動設備上更容易填寫！

此外，不要盲目相信你在互聯網上找到的每一個統計數據和研究。 還記得 11-fields-to-4 研究嗎？ 最近的另一項研究表明，通過將字段從 9 個減少到 6 個，轉化率下降了 14%。 令人震驚，不是嗎？ 為什麼？ 好吧，他們刪除了最吸引人的領域。 長話短說，他們又回到了 9 個領域，將最重要的放在首位，瞧，轉化率增加了 19.21%。

底線是，雖然這些研究很有趣，但這些網站不是您的網站。 不要盲目相信您在互聯網上找到的第一項研究。

所以，你可以做什麼？ 測試。 測試。 並測試！

• 進行一些用戶測試以查看完成移動表單的時間。
• 測量輟學。
• 測量某些領域的問題。
• 衡量與某些領域相關的挫敗感。 用戶提供這些信息的意願如何？ 這些信息有多私人？

優化觸控交互

使控件易於觸摸

如果您的字段太小或難以到達，用戶會犯錯誤並且需要額外的交互來實現他們的目標。 還記得菲特定律嗎？ 您也可以將其應用到移動設計中：通過增加觸摸目標大小使您的標籤、字段和表單控件易於點擊。 對於 web 上的標籤，多一點填充可以增加可觸摸區域。 有時您還需要在元素之間添加一些邊距以避免錯過點擊。

此外，不要忘記通過配對for和 ID 值將標籤與其組件鏈接。 這樣，如果用戶錯過了對標籤的點擊，相應的字段仍將獲得焦點。

Steven Hoober 對觸控區域進行了一些用戶研究。 您可以在“為觸控而設計”中找到摘要。 根據他的發現，他製作了一個小小的塑料尺子工具：移動觸控模板。 該工具可以幫助您確保您的觸摸區域足夠大以適應移動表單，更普遍地適用於移動設計。

要了解有關觸控設計的更多信息，您可以閱讀以下內容：

• “手指友好型設計：理想的移動觸摸屏目標尺寸”
• “拇指區：為移動用戶設計”

提供反饋

移動用戶沒有鼠標（不是開玩笑），所以他們不會得到桌面用戶在點擊按鈕時得到的“點擊”反饋。 移動表單用戶在與元素交互時需要清晰的反饋：

• 為用戶正在與之交互的表單字段提供焦點狀態。
• 當用戶與按鈕交互時提供視覺反饋。

我不是材料設計對按鈕的連鎖反應的忠實粉絲。 但我必須承認，當用戶與按鈕交互時，Android 上的動畫會提供清晰的反饋。

兌現下一個和上一個按鈕順序

最後，尊重移動鍵盤上的下一個和上一個按鈕。 用戶可以使用它們快速導航字段。 tabindex順序應該與字段和組件的視覺順序相匹配。

盡可能避免在移動設備上使用下拉菜單

Web 上的下拉菜單（HTML 選擇元素）需要大量的選項卡和交互。 因此，正如 Luke Wroblewski 所說，它們應該是最後的 UI。 在許多情況下，許多其他 UI 組件比下拉菜單效果更好。

如果您有兩到四個選項，則分段控件和單選按鈕是下拉菜單的不錯選擇。 當您可以直接在一個屏幕上顯示所有選項時，為什麼要隱藏下拉菜單下的選項？ 請注意，與單選按鈕一樣，分段控件是互斥的。

國家/地區列表是組件的理想候選者。 一百多個國家的下拉列表是移動設備上的交互噩夢。 如果您正在尋找阿富汗（在列表的開頭）或津巴布韋（在列表的末尾），那也沒關係。 如果您正在尋找 Luxembourg，您最終會陷入一場滾動遊戲以到達列表的中間，到字母 M 太遠，試圖回到 L，等等。

長下拉菜單可以替換為預測文本輸入字段。 當用戶開始輸入 L 時，界面會建議九個國家。 如果他們添加一個 U -瞧！ — 盧森堡。 四個交互而不是兩個，與下拉菜單的多達六個或七個滾動交互。

如果您需要用戶選擇日期，請忘記將其拆分為日、月和年下拉列表，就像人們習慣在紙質表格上所做的那樣。 用日期選擇器替換多個日期下拉列表。 HTML5 輸入type=date在大多數情況下都有效。 但是您可能有一些特殊需求，最終會在 JavaScript 中構建自己的日期選擇器，特別是如果您從事預訂業務（酒店、汽車、航班）。

在他的文章“Mobile DropDowns Revisited”中，Klaus Schaefers 解釋了使用日期選擇器來確定到達和離開日期如何使交互速度提高 60%。

讓我們堅持預訂業務。 假設用戶需要將多個旅行者添加到他們的行程中。 您可以**用*步進器**替換下拉列表*來選擇乘客人數。 步進器是一種控件，允許用戶通過點擊+和-按鈕來增加和減少值。 當必須添加少於六個人時，這往往會更快。 它也更直觀。 下面是在 Android 原生 Airbnb 應用程序中用於選擇客人的步進器示例，以及在 Kayak 的移動優化網站上用於添加乘客的步進器示例。

下拉列表的最後一個替代方案是列表視圖。 例如，這些選項將列在特定的子視圖中，如單選按鈕。 這主要是 Android 設置的工作方式。

通過自動完成變得聰明

如果你想降低表單的交互成本，那就聰明點。 不要詢問您可以根據用戶提供的其他信息自動檢測或猜測的信息。 盡可能多地自動完成和預填充。

地點和地址

如果用戶搜索地點或需要輸入地址，您可以提供自動完成功能來幫助他們。 當他們鍵入時，API 會為他們填寫地址的其餘部分。 這也減少了錯誤。

你可以使用：

• Google 地方信息 API
• 基於 OpenStreetMap 的 Algolia Places

在法國和許多其他國家，您可以根據區號猜測城市。 因此，如果法國用戶輸入區號，您可以自動完成或至少建議城市。 我的國家盧森堡很小（不要取笑我）。 我的區號與我的街道相關聯。 因此，如果我輸入我的區號，表格甚至應該能夠建議我的街道。

信用卡

另一個容易自動檢測的領域是信用卡。 您無需詢問用戶他們擁有哪種類型的信用卡。 您可以根據他們輸入的初始數字自動檢測到這一點。 甚至還有一個圖書館可以為您完成這項工作。

使用 HTML5 自動完成（自動填充）

HTML 自動完成屬性可以根據用戶之前的輸入預填充字段。 此屬性具有開和關狀態。 一些聰明的人已經開始製定一個規範，以使其更強大，並擴展表單字段的自動完成屬性。 WHATWG 也有一個有趣的列表。

Chrome 和其他移動瀏覽器已經支持信用卡和姓名的一些擴展值。 這意味著用戶可以使用他們在其他網站上使用的姓名和信用卡數據預先填寫表格。

簡而言之，當您必須在不同系統之間進行選擇時，請計算每個系統需要的交互次數。

錯誤發生：處理移動表單中的錯誤

我們邁向更好的移動表單的最後一步是處理錯誤和錯誤。 我們可以盡量減少錯誤以減輕用戶的認知負擔。 我們還可以幫助他們從錯誤中恢復，因為無論您的表單設計多麼出色，錯誤都會發生。

填寫表格時避免錯誤

“預防勝於治療，”我母親常說。 表單設計也是如此：防止錯誤將改善您的移動表單的體驗。

顯式格式限制

“做事要保守。 對你從別人那裡接受的東西要自由。” 這種穩健性原則也可以應用於表單字段。 如果可能，讓用戶以任何格式輸入數據。

如果您認為需要限制用戶可以在該字段中輸入的內容，請先問自己“為什麼”。 在用戶體驗領域，我們有一種叫做“三個為什麼”的技術。 如果答案是“因為 blah blah 數據庫”，也許是時候改變了。 例如，你為什麼拒絕在用戶名字段中使用 e、a 和 o 等特殊字符？ 我寫了一篇文章，解釋當我嘗試輸入“Stephanie”作為用戶名時，表單對我來說是多麼粗魯。 我仍在試圖找出一個很好的理由（除了數據庫原因）。

如果您有充分的理由要求用戶提供特定格式，請提前說明。 您可以使用 HTML5佔位符向用戶提示數據應該是什麼樣子，但同樣要小心。 您還可以使用本文開頭介紹的所有字段描述技術。 最後，輸入掩碼可以引導用戶使用正確的格式。

標記必填字段（和可選字段）

不要等待用戶提交完成一半的表單來告訴他們必填字段。 如果一個字段是強制性的，用戶應該知道它。 用星號 ( * ) 和圖例標記必填字段已成為表單的標準模式。 好的部分是它不佔用太多空間。 問題是它沒有語義價值，因此如果編碼不當並且如果您依賴人們的表單交互習慣，它可能會導致可訪問性問題。

您可以改為使用“必填”（或“強制”）和“可選”字樣顯式標記必填和可選字段。 Baymard Institute 和 Luke Wroblewski 都同意這一點。 這避免了移動設備上長表單的歧義，例如在使用滾動條時，繼續進行其他操作，然後返回並且不記得必填字段是否標有星號或其他內容。

最終，如何標記這些字段的決定將取決於字段的設計和長度以及上下文。 再次，了解您是否做出正確決定的最佳方法是測試表格。

合理的默認值

請注意表單中的默認選擇選項。 當我申請上一份工作時，有一張信息表。 婚姻狀況是可選的。 他們將下拉列表中的第一個元素“離婚”作為默認字段。 所以，我要么不回答（因為它是一個可選字段），讓系統相信我離婚了，要么糾正這個並披露我的實際婚姻狀況，即使我不想。

另外，要注意性別。 同樣，對於不想透露的人有一個選擇； 明確你為什麼要詢問他們的性別； 更好的是，要求代詞，或者不要問你是否真的不需要。 如果您對此主題感興趣，我推薦“為性別多樣性和包容性設計表格”。 如果性別是可選的，同樣，不要自動檢查第一個選項，否則人們將無法取消選中該單選按鈕並選擇不回答。

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• 登錄時
  在登錄表單中，屏蔽/取消屏蔽密碼選項將極大地改善用戶體驗。
  亞馬遜在其登錄表單中迭代密碼方面有著有趣的歷史。 它曾經有一個您看不到密碼的版本。 下一次迭代允許用戶展示它。 然後，默認情況下會顯示密碼，您可以將其隱藏。 這是 2015 年的樣子：

  

  亞馬遜測試了最後一個版本，60% 的人對此表示懷疑。 因此，他們將未選中的“隱藏密碼”複選框替換為“顯示密碼”複選框。 這將在用戶鍵入時在字段下方以較小的字符顯示密碼。 這是撰寫本文時的樣子：

  

  如您所見，總有改進的餘地。

內聯驗證

如果您熟悉可用性原則，您可能知道格式塔鄰近法則。 在移動設備上，避免在用戶點擊提交按鈕後頁面頂部沒有上下文信息的錯誤摘要。

相反，錯誤消息應該位於錯誤本身附近。

實時驗證

您也不需要等到用戶點擊提交按鈕。 您可以在用戶填寫字段時驗證字段並顯示反饋。

一些提示：

• 如前所述，密碼字段將受益於每次擊鍵的實時驗證和反饋。
• 您可能還想在創建帳戶時實時驗證用戶名，以確保它們可用。 Twitter 在這方面做得很好。
• 不要驗證每一次擊鍵。 等到用戶完成輸入。 （對 Web 表單使用 JavaScript blur ，或者等待幾秒鐘來檢測不活動。）

注意：*Mihael Konjevic 寫了一篇關於“表單中的內聯驗證：設計體驗”的精彩文章。 他解釋了“早獎勵，晚懲罰”的概念。*

“如果用戶正在輸入處於有效狀態的字段中的數據，請在輸入數據後執行驗證。”

“如果用戶在處於無效狀態的字段中輸入數據，請在數據輸入期間執行驗證。”

顏色很重要

我並不是說顏色很重要，只是因為我現在的薑黃色、粉紅色和紫色的頭髮顏色。 顏色在表單設計中真的很重要。

網絡上有一些您不想打破的約定。 非色盲用戶知道紅色表示錯誤，黃色表示警告，綠色幾乎總是表示確認或成功。 最好堅持這三種顏色。 不過，紅色會讓人們感到焦慮。 用戶可能認為他們犯了一個非常嚴重的錯誤。 使用橙色或黃色作為錯誤消息可以減少恐慌。 黃色和橙色的問題在於很難找到適合色盲的色調。

說到色盲：顏色不應該是傳達錯誤信息的唯一方式。 這是一個可訪問性標準。

在下面左側的示例中，有錯誤的字段為橙色，已更正的字段變為綠色。 我用色盲測試工具截取了中間的截圖：你已經無法區分默認的灰色邊框和綠色邊框了。 在最後一個屏幕截圖中添加一些圖標可確保將錯誤消息傳達給色盲人士。

從錯誤中恢復：編寫用戶友好的錯誤消息

在這一點上，我們已經盡我們所能來幫助用戶填寫我們的表格並避免錯誤。 但有時，儘管我們盡了最大的努力，錯誤還是會發生。 是時候弄清楚如何幫助用戶從這些錯誤中恢復過來了。

首先，記住：不要劫持系統的控制權。 如果問題不嚴重，用戶應該能夠盡可能多地繼續與界面的其餘部分進行交互。 盡可能避免那些阻止用戶的 JavaScript 警報錯誤消息和模式。 此外，如果您的表單需要一些權限，請在使用流程中請求它。 如果未授予權限，請不要將其視為錯誤，因為事實並非如此。 請注意您在此處使用的副本。

你不是機器人，你的用戶也不是

機器人很酷，我知道。 但你不是機器人，你的用戶也不是。 然而，如此多的錯誤消息仍然寫得如此糟糕。 以下是一些關於人性化錯誤消息的提示：

• 永遠不要顯示原始錯誤消息，例如“發生了 2393 類型的錯誤。 服務器無法完成操作。” 相反，用人類語言解釋發生了什麼以及為什麼會發生。
• 永遠不要顯示死胡同的錯誤消息，例如“發生錯誤”。 而是建議從錯誤中恢復的方法。 編寫可操作的副本。
• 切勿使用“重試”按鈕顯示模糊的錯誤消息，例如“找不到具有指定主機名的服務器”。 相反，使錯誤消息信息豐富且一致。 請不要聽起來像機器人。
• 不要假設人們知道消息的上下文。 您的用戶不是精通技術的極客。 相反，用通俗易懂的語言向他們解釋如何從這個錯誤中恢復，不要使用技術術語。

注意您在消息中使用的語言

無論你寫什麼，都要避免讓人們對錯誤感到愚蠢。 如果可能的話，省略否定詞； 他們往往會嚇到人們，使他們更加焦慮。 改用禮貌、積極、肯定的語氣。

不要責怪用戶的錯誤； 而是責怪系統。 系統不會記仇的，我保證。 將用戶的注意力轉移到系統無法處理該動作的原因上，並向他們解釋如何找到解決方案。

一個小技巧是大聲讀出你自己的信息。 它將幫助您聽到它是否有效或過於苛刻或過於隨意等。

您還可以通過錯誤消息獲得創意，並結合圖像和幽默以減少它們的威脅性。 不過，這實際上取決於您品牌的身份和基調。

為了幫助您編寫更好的錯誤消息，我建議您閱讀以下內容：

• “沒有 UX 作家的產品團隊的 6 點顯微檢查清單”
• “錯誤信息的藝術：在出現問題時寫出清晰、有用的副本”

提交表格的時間

用戶已填寫表格，沒有更多錯誤，一切看起來都很好。 最後，是時候提交表單了！

第一條規則是，不要屏蔽提交按鈕。 嚴重地！ 我想知道這個想法是什麼扭曲的想法，但我已經以某些形式看到了它。 只有在填寫完所有必填字段且沒有任何錯誤時，才會顯示提交按鈕。 用戶想知道是否有問題或表單的按鈕未加載或網站已損壞等令人不安。

如果您不希望用戶在缺少必填字段或存在驗證錯誤時點擊提交按鈕，請在submit輸入上使用disabled HTML 屬性。 一旦表單有效並準備好提交，您將需要使用 JavaScript 重新啟用該按鈕。

如果您有主要和次要號召性用語，請使用顏色、大小和样式來顯示層次結構。

如果想知道確認按鈕應該出現在取消按鈕之前還是之後，我（和很多其他人）也是如此。 如果您正在構建本機應用程序，請遵守操作系統指南。 自從 Android 在其第四版中更改了按鈕位置以來，它變得特別有趣。 在網絡上，它更複雜，因為沒有真正的指導方針。 無論使用哪種操作系統，以下是針對移動設備優化的提交按鈕的一些一般準則：

• 發出號召性用語，描述性的、可操作的動詞。
• 當用戶點擊它時提供視覺反饋。
• 如果您有兩個按鈕，請突出主要操作。
• 除非您正在處理非常特定的後台企業表單（在這種情況下，您將面臨很多針對移動設備進行優化的挑戰），否則請避免使用重置按鈕。 用戶可能會將其與提交按鈕混淆，並且會意外丟失所有數據。

結論

在第一部分中，我討論了許多小技巧，可以將您的表單提升到一個新的水平並幫助用戶填寫它。其中一些通用指南和移動最佳實踐可能無法 100% 奏效——這就是問題所在與最佳實踐。 因此，請始終在真實用戶和真實設備上測試您的表單，並根據用戶的特定需求和體驗調整指南。

此外，做一些回歸和自動化功能測試——同樣，在真實設備上。 Chrome 的移動模擬器不足以測試觸摸優化的表單。 我這樣說是因為我推出了一個電子商務網站，其中包含一個無法在移動設備上運行的搜索表單。 我們只使用模擬器進行了自動化測試。 這就是發生的事情。 搜索表單隱藏在搜索圖標下。 您可以點擊該按鈕，該按鈕會打開一個帶有搜索字段的框。 它通過將鼠標懸停模擬為觸摸事件來工作。 我們測試了點擊按鈕，它打開了盒子。 沒有人試圖發起搜索。 因此，沒有人（甚至客戶）看到搜索字段在用戶嘗試與之交互時就消失了。 發生了什麼？ 當輸入元素獲得焦點時，按鈕失去了懸停狀態，因此它關閉了帶有字段的框。 自動化測試無法捕捉到這一點，因為輸入沒有失去焦點。 因此，我們推出了一個沒有移動搜索功能的電子商務網站。 不是超級體驗。

在本系列的第二部分，我們將看到更高級的移動專用技術。 我們將看到如何使用很酷的 HTML5 功能來格式化字段，以及如何使用移動功能將移動用戶體驗提升到一個新的水平。