編輯導語：凡需要用戶輸入信息的地方，都要用到輸入框，輸入賬號密碼、篩選條件、輸對話等等；它看似簡單，但使用場景多，交互頻次之高，值得我們花些時間好好研究一下。本文作者詳細解析了文本輸入框的設計。

一、信息輸入前

1. 舒適的大小

輸入框大小是否合適，以便完整顯示那些最有可能出現的輸入內容；表單輸入框的大小往往會影響用戶輸入的心情。

設計考慮到網頁無障礙閱讀，即輸入框文字的前景色跟后景色要有足夠的對比度，提高可識別性。

1）輸入框長度應符合用戶預期

搜索查詢輸入區域的寬度應足夠寬，以包含典型的字符。

如果“輸入”字段太窄，則會降低可用性，輸入框中文本字段可能的輸入長度應該小于輸入框本身的長度，這樣不僅在體驗上一致，而且在視覺體驗上更加愉悅。

2）填充外觀

灰色的填充使容器看起來像處于禁用狀態，它的使用會讓用戶懷疑能否與之進行交互，發送這些混合信號會使他們在開始輸入文本之前就感到困惑。

理想的體驗是當用戶識別你的文本字段就立即開始填寫，空白是空虛的明確提示，它提示用戶使用其輸入來填充空白。

要獲得可填充的外觀，要使容器內部保持空白，并留有封閉的邊框，使邊框變暗，使用戶可以將輪廓比作一個空框；它們吸引了人們的注意力并且易于識別，這正是用戶所需要的。

要增強文本字段的可填充性，可以將其放在米色背景上，使空間更突出，并提供了一個文本字段最清晰的環境。

通過這種方法，用戶在檢查表單時可以更快地注意到填充和未填充的字段。

空白區域的亮度使輸入文本和占位符文本具有更高的對比度，提高了可讀性。

灰白色背景上放置的任何文本均可保持可讀性，并且不會在視覺上與輸入或占位符文本發生沖突。

2. 告知用戶輸入內容

當用戶選中準備輸入的時候，應當提供清晰的視覺提示，這樣讓用戶明確知道自己的位置，這個就可以靠標簽和占位符來實現；而不是迷失在茫茫表格中，這種細微的反饋會讓用戶更有掌控力。

1）填寫標簽要簡潔

文字標簽宜簡短，尤其在移動端，盡量不超過六個漢字；英文標簽不要所有字母大寫，首字母大寫即可。

過長的標簽有兩個問題：使填寫的內容壓縮、影響整頁對齊。

平行排布優點是：符合視線規律、閱讀更快。如果要填寫的標簽實在過長，檢查一下是否說不清楚的可以用占位符分擔描述下，或者采取垂直排布的方式。

平行排布優點是：對標簽字數限制不嚴格。

2）占位符文本提示

• 占位符要簡短，不要換行，若超出框，超出部分截斷；
• 千萬不要把占位符設計得像已經輸入的文本，所以顏色要淺；
• 框多的時候盡量不要占位符，因為很多用戶只是大致瀏覽；
• 針對色弱人士不適合用占位符，因為顏色較淺（這一點基本可以忽悠）。

電商、社區等內容導向型平臺的輸入框會存在內容推薦：

標簽提示+占位符提示內文字補充說明告知效果更為強烈。（推薦使用）

3. 必要的說明

1）必填內容

?到標簽前后打了“ * ”號，?家便知道意思是必填；除了?星號，必填還可?漢字“（必填）”放在標簽后。

我們在設計中，如果遇到??表單的?多數字段是必填，那么需要標出的不是必填，?是選填內容；也就是說，標出少的那?個，如果兩者各占?半，那就隨便選擇了。

注意：有的頁面不像表單頁那樣復雜，不必標出必填或選填，但應在所有必填項填好后，再點亮按鈕跳轉到下一頁，如登錄注冊頁。

2）格式提示

• 輸入框內文字占位符提示；
• 格式拆分編輯。

舉個列子：要求填手機號碼時很多人往往會忽略區號的輸入，因此很多輸入框在設計時，會將區號單獨提出來，避免此類錯誤的發生。

3）字數限制提示

一般以文案形式提醒，比如：在輸入框后顯示不得超過X字。

4）規則補充說明

一般在輸入框下方以文案形式提醒，重要的提示可以標亮提醒。

有兩種輸入項目常常要加入說明：

• 專業性強，大眾可能不清楚；
• 安全隱私或者金錢相關，有心理顧慮。

針對第一種，說明能減少輸入錯誤，例如：銀行轉賬不是及時就到，而是需要兩小時；金額不是任意的，每天有上限，并且和所剩的余額相關。如果這些是在用戶輸入完才告知，或者報錯，那么這個鍋用戶當然不愿意背。

針對第二種，有心理顧慮的，可以承諾不會對用戶造成損失，或者找背書；下圖最后一個解決方案已經通過華為嚴選產品安全認證，消除顧慮之后才能順利進行下一步。

二、信息輸入時

總的來說，優化輸入框設計主要有三個方向：

1. 提高輸入速度
2. 為用戶輸入提供引導幫助
3. 直接有效的指出用戶輸入過程中的問題

重視每一個細節點上的用戶的感受，優先關注讓那些最常被用到的或者是對完成任務最為關鍵的輸入框，這樣產品才會被打磨的越來越精致。

1. 當前位置的提示

用戶在選擇輸入框并輸入內容時應獲得視覺反饋，當他們刪除輸入內容并取消選擇輸入框時，他們還應該獲得視覺反饋；當輸入框正確執行視覺反饋時，用戶將可以毫無困難地輸入內容。

1）選擇輸入框并輸入

當用戶第一次將注意力放在文本框標簽上時，他的邊框應該看起來是深灰色的，以便于輸入時將顯示的黑色不同。

用戶開始輸入時，標簽應該消失，但是用戶只用鼠標點擊文本框時，標簽不會消失；但文本框應突出顯示且標簽應模糊顯示，以使用戶知道輸入時該標簽即將消失。

在用戶輸入之前，標簽不應完全消失，因為某些用戶將選擇一個輸入框，而可能忘記了在該輸入框中輸入哪些信息。

2）刪除信息并取消選擇輸入框

當用戶刪除輸入框輸入信息并取消選擇它時，輸入框應回到其原始狀態，這意味著輸入框標簽應該再次顯示。

當用戶刪除輸入內容時，輸入框內標簽還不會完整顯示。

當用戶刪除信息并取消選擇文本框時，標簽應重新出現，以便他們可以根據需要再次讀取標簽。

3）光標引導

選中輸入框位置時出現光標引導輸入，取消選擇時輸入框又可以收回光標；選中輸入框時外框標亮提示，點擊空白區域又變回原有顏色；這是用戶的控制性和自由度的展現。

通過不同的外觀樣式來呈現當前所處的狀態，是輸入框在用戶操作界面時必須做到的事情。

非激活狀態、光標懸停狀態、禁用狀態、選定輸入狀態、驗證識別狀態、出錯狀態等等。

所有的輸入框設計當中都應該保持一致，盡量不要進行反常規設計，避免和用戶思維模型發生沖突。

2. 限制條件的提示

當你好不容易填寫完長長的信息，點擊提交，這時候界面提示：你有20項填錯……這種處理方法顯然不是最好的。

沒有人會喜歡后知后覺的反饋，特別是錯誤；告知用戶輸入內容是否正確的最佳時機，是在用戶填完當前輸入框或當前字符內容時立刻告知用戶；及時驗證可以馬上告知用戶輸入的正確性；及時驗證，幫助用戶及時改正，無需等到點擊提交按鈕。

1）字數

字數限制輸入：當達到限制字數時，不允許再輸入內容，這樣可以提醒用戶檢查輸入的內容是否不小心多輸了文字。

這里只輸入手機號時，手機號按照344的位數展示，根據米勒定律的分段記憶原則，便于記憶及且用戶不容易輸錯。

手機號輸入位數超過11位則限制輸入，這里也是根據特定輸入框來定義的，例如：手機號、身份證號等這些特定位數的字符來特殊定義。

字數實時提醒：實時提醒用戶當前輸入內容字數；氣泡或彈窗提示“字數超過上限”。

以顏色區分：當沒有達到限制字數之前，當前輸入的字數顏色為灰色；當超過限制字數時，顯示的是超過了多少字，顏色為橙色。

2）輸入框文案填寫類型提示

默認情況下輸入框內會有文案告知用戶填寫的信息類型，輸入框下方有溫馨提醒關于填寫內容更詳細的一些要求或建議。

比如編輯狀態下的密碼輸入框下方有文案提示：

• 不能包括空格；
• 長度為8-16個字符；
• 必須包含字母、數字、符號中至少2種。

3. 減少用戶輸入

說了那么多，最讓用戶舒心的莫過于幫助他們填寫，因此，許多需要填寫、選取的表單最好有預設的初始值或者內容填充在其中，這樣可以讓用戶用起來更加方便，這就是智能預設。

常見的使用場景有搜索聯想輸入、地址定位等。

1）識別設備信息

針對有個人識別信息的設備，如手機號碼登錄、網頁識別瀏覽器賬號等。

使用預填充字段作為默認值，比如基于IP地址幫用戶填寫好國家和地區；這類解決方案很靈活多樣，根據填寫字段屬性、功能，可以靈活處理。

比如某些手機登錄，直接定位該設備手機號碼，“本機號碼一鍵登錄”，并顯示手機號，這少了輸入手機號和驗證碼的過程，效率大幅提高。

如微信在新的小程序注冊賬號時，使用微信授權登錄，小程序自動識別微信號、呢稱、微信綁定的手機號。

2）復制粘貼

對于已經復制了文本內容的對象，輸入文本檢測復制內容，下方自動彈出小氣泡顯示復制的文本內容，只需輕輕一點，文本就復制到輸入框中。

如果復制內容不對，點擊小氣泡以外區域則小氣泡消失。

3）歷史記錄

借助自動填寫功能，幫助用戶填寫輸入框，用戶在填寫過程在自動查詢匹配、提供建議，用戶可以使用回車和方向鍵快速選擇。

在瀏覽器使用場景中的記住密碼，在下次登錄中直接就已填寫文本，如果存在該網址多個賬號被記住的情況下，可以點擊輸入文本，彈出更多的記住的賬號進行選擇。

在搜索框記錄用戶所有的搜索行為數據，在搜索框下面提供搜索記錄，用戶點擊一下即可輸入，大大減少了用戶的操作步驟。并提供清空歷史記錄功能。

提供上下文信息，比如用戶在轉賬的時候，提供余額相關的信息。

4）搜索實時檢索

搜索框會根據輸入框內輸入的字符實時進行檢索，基于關鍵詞查詢相關短語或目標，將結果呈現在用戶面前（通常在用于好友、工具、應用等準確定位的情況下比較常見），幫助用戶在海量內容中快速定位到目標內容。

自動檢索功能可以幫助用戶減少打字量，避免拼寫錯誤并降低獲得結果所需的整體工作量，從而改善用戶的體驗。

通過提供有用的建議，自動完成功能可以幫助引導用戶到達目的地，這也是幫助進一步優化搜索查詢的有用方法。

5）使用合理的鍵盤類型

這個指針對手機端，輸入內容會喚起鍵盤，而鍵盤分為很多種類型，比如中文鍵盤、數字鍵盤、英文鍵盤；如果在輸出設計稿的時候對鍵盤類型沒有標注，開發哥哥就會使用默認鍵盤，這樣就有可能造成一些降低體驗的問題；例如：手機號、銀行卡號默認需要輸入數字的輸入框，彈出的鍵盤默認為數字鍵盤；若輸入的內容包涵文字、字母等內容，默認彈出字母鍵盤。

iOS 和 Android 提供多種不同的鍵盤，這是為了應對不同的輸入需求。

想要簡化數據輸入，當用戶輸入不同類型的字段的時候，調用對應類型的鍵盤，同時需要注意鍵盤出現的位置，不要遮擋住關鍵信息。

別忘了輸入內容時會喚起鍵盤：起初一看沒啥問題啊，可是當真正落地的時候，就會發現，問題大大的。

當你準備輸入內容的時候，鍵盤會被調起，這時候就尷尬了——原來是被鍵盤擋住了，現在即使你想把提交按鈕往上提，空間也不夠，因為上面兩個輸入框已經把空間占滿了。

這就是設計師經驗不足，前期沒有考慮充分導致的結果。

這樣登錄布局本身是沒有問題的，但是你需要多考慮一種鍵盤調起的狀態，因為鍵盤調起來的時候登錄按鈕會被擋住，這就是為什么大部分登錄頁會往上布局。

因為鍵盤有沒有被喚起，頁面的布局是不用變的。

當然這里也不是說哪種形式更好，而是提醒大家要考慮好細節。

6）特殊字符處理

在輸入框中特殊字符一般包括“@ ”和“. ”等，一般用戶輸入@可能是要輸入郵箱，輸入“.”有可能是網站后綴，所以最好提供快速輸入的方法，讓用戶減少輸入的字符。

雖然現在一部分輸入法中已經增加了這些常用的固定的一段字符的按鍵，但是還是建議在輸入框中加入快速輸入的方法——與其依靠這種具有不確定性的情況，還不如一開始就設計好。

而且由于現在的交互體驗系統越發的完整，這些特定字符的輸入框鍵盤會變為數字鍵盤，你把“*”和“#”號輸入，也會在提交獲取驗證碼的時候提示你的手機號不正確。

7）盡量減少填寫字段數量

太多的填寫內容會增加認知負荷，盡量讓表單顯得更加簡單；不要將名字和日期分成多個字段；不要多次詢問相同信息；重復輸入的內容盡量減少。

8）隱藏不相關

不要一次性將所有的信息和步驟都呈現出來，而是要在用戶需要的時候再呈現，合理控制復雜性。

基于用戶的不同選擇，將表單字段中不相關的部分隱藏掉，或者新增；這種方式可以幫用戶規避掉很多不必要的填寫內容，并且讓填寫過程更加個性化。

4. 文本字數的自適應

內容較少時，輸入框能夠透露出用戶所填所有信息；內容長度超過輸入框長度時，無法完整查看所有所填信息。

1）單行文本

當輸入的文本長度超過文本框的長度時,當光標到達文本框右邊緣時,它會自動向左滾動。

2）多行文本

多行文本框通過擴展文本框的底部，把文本換行到新的一行上，并把屏幕中位于文本框下方的元素向下移動，多行文本框允許用戶一次性看到他們輸入的所有內容。

3）文本區域

文本區域比文本框要高，并可將溢出的文本換行到新行上；當光標到達文本區域的底部時，它們會垂直滾動。

存在三種情況：

• 文字框大小不變，文字內容上移，光標自動定位到最新輸入位置處。
• 文本框隨著輸入文字的增多變大，到達接近鍵盤位置時，文字內容上移，光標自動定位到最新輸入位置處。
• 全屏輸入。

QQ團隊為了解決多文本下的輸入痛點，設計了長按輸入框就會出現全屏輸入的提示。

點開后即會全屏顯示已輸入內容并可做簡單的換行操作，收起全屏則回到聊天窗口。

5. 異常提示

對于一些內容，可以實時反饋狀態。

輸入的結果我們常常用顏色來反饋，比如藍色代表鏈接、灰色代表失效、綠色代表正確、黃色代表提示、紅色代表錯誤。

異常信息盡量不用彈框展示，那樣有點小題大做，且彈框一關掉就無法看到，平添了操作步驟；異常信息盡量不換行，如果非要換行，注意和下一個文本框拉開距離。

錯誤消息會帶給用戶很多壓力，讓用戶感覺他們搞砸了或者沒有完成任務。

核心輸入一般是必須要全部成功的，但是有些非核心輸入，輸入錯誤不要緊，或者成功一部分即可。

這個時候要把這些非核心輸入和核心輸入之間進行隔離，加強輸入效率。

1）輸入錯誤

不要等用戶填完了頁面所字段、點擊提交時才出現，盡量在鼠標點擊到文本框外，或按了回車鍵、空格鍵時就及時出現判斷，支持用戶實時修改。

如果發生錯誤，則標注錯誤原因；提示文本內容不符合規范時，最好提示原因，這樣有利于用戶快速修改。

大多數錯誤消息要么告訴用戶他們將輸入框留空，要么輸入了無效信息，這些通用錯誤消息是不夠的。

關于填寫錯誤的描述應該非常清晰，比如注冊時密碼填寫，不要說密碼安全性過低，而要說，密碼必須超過8位，或者密碼必須包含大小寫和數字。

總結為以下兩點：

• 發生了什么錯誤，可能原因是什么。
• 用戶應該做什么來改正錯誤。

密碼默認顯示：當點擊登錄按鈕后，若密碼不正確，密碼可自動顯示內容，可以讓用戶檢查密碼是否正確以及哪里出錯；允許用戶顯示和隱藏所設置的密碼，而不是讓用戶操作2次來進行驗證，這對于生成有效的密碼更重要。

始終顯示對于密碼的要求，并提供相應的指引，并顯示強度指示。嘗試簡化對用戶的要求。

2）不存在（無數據）/環境條件異常等

登錄時賬號不存在時，提示此賬號未注冊，其實還可以在提示文案中增加“注冊賬號”的鏈接，點擊即可跳轉到注冊頁面。

環境條件異常如斷網鏈接不上服務器等，環境條件異常則用氣泡提示。

當錯誤無法挽回，還可以通過視覺對錯誤的場景進行情感層的轉移。

三、信息輸入后

1. 敏感信息

如果是電話號碼或銀行等比較重要的敏感信息，就會使用“*”或圓點進行隱藏。

2. 格式拆分顯示

如果是電話號碼或銀行的輸入，這種相對長一些的數字輸入，盡量按照用戶習慣的規則劃分，如果將所有數字連著一起就會比較容易輸錯。

• 電話號碼的劃分規則為344，所以用戶在設計的時候可以在將電話號碼間隔開，方便用戶識別；
• 銀行卡通常的的劃分是4444X，X就是最后一位數為少于4的位數。

但是這里需要注意的一點是：在輸入手機號碼時，在第3和第7位數的時候是有一個空格的；所以在用戶從后往前刪除的時候，也需要在刪除第4位和第8位數字時，多刪除一個空格。

3. 一鍵刪除功能

部分數據后，通常輸入框右側會出現一個快速刪除全部的圖標，方便用戶快速刪除所輸入的數據，而不是僅能依靠鍵盤上的刪除按鍵一個個數據刪除。

有內容輸入后，會出現×控件，可以讓用戶一鍵刪除；內容清除為空時，icon隱藏。

這時候可能有人就會說，如果既要提供快速刪除，也要提示可輸入的字符數，怎么辦？

據我觀察，現有的應用中，這種兩者共存的情況比較少見，但是也不是可不可以用，下方提供了兩種方式供參考。

4. 文本展示

前面寫到了文本字數的自適應，那么輸入好的文本，如果單行展示不完，對溢出的部分可用三種方式處理：

• 截斷：文本數量較大時，只截取頭部的一部分；
• 換行：文本數量較小時可以換行展示；
• 省略：省略號可以放在文本前、中、后位置，這取決于文本哪個部位最不重要。

四、特殊的輸入框形式

1. 單輸入框連續操作

一個非常簡單的輸入框，但一次只能否顯示一個輸入文本，并以細微的動畫過渡下一個輸入。

我們可以在輸入部分數據后進行補充，輸入框右側再會出現一個快速刪除全部的圖標，方便用戶快速刪除所輸入的數據，而不是僅能依靠鍵盤上的刪除按鍵一個個數據刪除。

有內容輸入后，會出現×控件，可以讓用戶一鍵刪除。內容清除為空時，icon隱藏。

我認為這是輸入框的一種比較好用且用戶友好的形式，右下角的數字告訴用戶總共有多少個問題，哪個是當前問題；當他們前進到下一個問題時，我們將顯示一個進度條，指示表單的完成級別。

像這樣的輸入框對于問卷或簡單的表單可能非常有用。

這樣做的好處是：用戶分心的程度較小，并且填寫此表格的工作似乎要少得多。當然，這種方法也有其缺點，無法返回或概述之前的答案。

2. 自然語言形

一種使用自然語言而非常規形式，使用自定義輸入元素進行輸入。

自然語言確實是一種有趣的形式，將經典形式轉換為使用自然語言從用戶那里獲取信息。

為此，將構建一個句子，其中一些單詞和部分是選擇元素和文本輸入；然后，我們將轉換選擇元素，我們也可以自定義它們。

當然，自然語言形式非常適合某些情況，但并不適合所有情況。

但如果在正確的位置以正確的方式使用它們，也更具吸引力。

3. 全屏

全屏輸入框，其思想是在輸入框字段之間移動時允許使用一些精美的動畫進行無干擾的文本輸入。

這個想法是為了擴展輸入框，并且一次只以全屏顯示一個問題或輸入框字段。

用戶可以無干擾地輸入數據，并且可以為字段添加一些精美的動畫；一旦所有字段均已填寫或移入，我們將在最后一步中顯示摘要；在這里，輸入數據仍然可以查看和更正，最后提交表格。

這種形式包含兩個元素：輸入框標簽字段（每個都單獨顯示），右側的點導航（這允許返回已經填寫的問題）。

顯示輸入框當前位置的數字指示器，繼續按鈕，它將移至下一個字段，包括字段內的一些詳細信息，例如：信息圖標和幾個自定義輸入。

填寫完所有信息后，進入最后的審核瀏覽器，可以更正信息并提交表單。

目前見得比較多的全屏輸入框就是搜索框了。

六、結語

對于輸入框，工作中并沒有接觸的這么全面。

最開始是想寫B端輸入框的，但寫著寫著發現使用場景多且通用，交互頻次之高，盡量寫全點吧。

希望自己能堅持，你的關注，就是對我的最大鼓勵。

參考資料：

UI設計組件-文本框/輸入框（上）https://mp.weixin.qq.com/s/u6HWCv7vtll9sJJ3JOZMzg

在UX表單設計中的浮動標簽模式

信息輸入框的交互思考

小小輸入框背后隱藏的潛規則

優化輸入框，讓填寫如絲般順滑

為什么不應該使用實線或帶下劃線的文本字段

本文由 @小龍 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自?Unsplash，基于 CC0 協議