輸入框設計，有哪些容易忽略的“潛規則”？

關注並將「人人都是產品經理」設為星標

每天早 07 : 45 按時送達

輸入框在互聯網產品中可能是最常用和常見的互動組件之一，對於輸入框的定義相信大家都了解是用戶輸入文本內容的載體組件。但是對於一些細節互動的“潛規則”，一些新人設計師常常容易忽略。

以下內容是我們對輸入框互動細節的一些思考及需要注意問題，與大家分享：

作者：設計牛奶盒

微信公眾號：設計牛奶盒

題圖來自正版圖庫 圖蟲創意，基於VRF協議

全文共 2717 字，閱讀需要 6 分鐘

—————— BEGIN ——————

根據不同的場景需求，我們大致可將輸入框分為短文本輸入框、長文本輸入框、浮動型文本輸入框、特定場景輸入框（如應用在搜索、二維碼校驗等特定場景下）。

我們今天不介紹每種類型的輸入框具體的定義，就說說各個輸入框容易被新手忽略的“潛規則”吧～

 “潛”規則一 

輸入極限值如何處理？

不同的輸入框類型對於極限場景的規則不同，通常以短文本與長文本兩種輸入框為典型。

我們來具體看一下：

1. 短文本輸入的極限場景

短文本輸入框意味著輸入的內容都比較簡短，如姓名等。

一般的處理方式是會在邏輯層限制最大的字元數，但是不需要一開始就告知用戶。

在字元限制內允許用戶無限向後輸入，此時文本框顯示最近輸入的內容從右向左推進。

只有當用戶不小心誤觸或“調戲輸入框”，輸入超長文本時，才會出現對應的提示。

Trip.com 短文本輸入極限

對應的提示方式我們認為可以根據具體的場景及設計規範去選擇，屬於兜底處理。

可以是像Trip.com這樣輕量精準的提示，也可以像美團外賣帶有“趣味性”的提示：

2. 長文本輸入的極限場景

我們通常固定的設計思路是在超出字數限制時輸入即無效，簡而言之就是不讓再輸入了，同時加入提示告知用戶不可再輸入的原因（這裡的提示盡量以輕量清晰的方式出現）。

假設用戶輸入恰好在字數限制的臨界點的場景，用戶原本的想要輸入的文字是在字數範圍內，但由於單個文字輸入時是由拚音字母組成，此時輸入的字數統計為字母數，導致用戶的編輯無法生效——這對於用戶來說是一個不好的體驗點。

輸入狀態時會因為拚音字母個數而超出限制

雖說這是屬於非常極端和細微的場景，考慮到設計的細致性，還是建議在超出字數的時候仍可允許用戶輸入。

可在輸入框下方顯示提示文字，以及置灰用戶的下一步操作來告知用戶，用戶可在已輸入的內容中自由對其進行刪減順利進入到下一步。

超出時僅以統計字數來告知用戶，同時置灰下一步操作

關於字數統計這裡有個小tips：

給開發小哥們是關於字數而不是字元數的統計——特別是在輸入內容涉及多種語言的場景下，對於字數統計的規則會有所不同，如若需要，設計側可以列出一個白名單（可計入字數的字元說明）或是黑名單（不可計入字數的字元說明）給開發小哥們，以此確保設計還原的準確性。

 “潛”規則二 

輸入框是否支持伸展

不知大家是否試用過長文本輸入框的極限場景，在沒有做字數限制的情況下如果持續的輸入文字，會發生什麽？

1. 高度伸展

1）一種通常的設計是固定長文本輸入框的高度。

在此高度內向下輸入，同時會出現滑動條或最上方的文字露出半行來告知用戶這裡有多行內容可以自行滑動查看。

這種設計適用於內容比較多的頁面，限制的高度不會影響頁面的整體結構和美觀度。

2）還有一種設計是當輸入內容超出輸入框高度時，輸入框隨著內容自動向下延伸。

這樣的設計能讓用戶清楚自動自己輸入的所有內容，方便用戶檢查和刪改。

但高度的延伸會影響頁面整體的結構。如果輸入框下面還有其他的控件，也需要跟隨著高度進行自適應的調整；因此這樣的設計應用比較少，更適合用戶頁面結構比較簡單且長文本輸入框的內容很重要的場景。

輸入框隨著文本輸入而伸展

2. 模式切換

輸入框伸展還有一種方式是：提供用戶自主選擇進入專注輸入的模式，常見於用戶可自由選擇輸入長文本或是超長文本的場景，如評論；若用戶可做一番“長篇大論”，可自主進入專注編輯的模式，便於超長文本的輸入。

點擊箭頭進入評論編輯的頁面

 “潛”規則三 

如何與微動效進行“合體”

輸入框與微動效結合並應用的場景越來越廣泛；這裡的微動效出現在用戶進入輸入狀態前和進行輸入時，這樣的輸入框也就是我們前文所說的浮動型文本輸入框。

1. 怎麽「合體」？

這一類的輸入框不固定出現標題，只有一行佔位符文本；在用戶激活輸入框進行輸入時，佔位符文本上移成為小標題，用戶在輸入時和輸入完成後，輸入框的展示方式是小標題+輸入的內容。

輸入與動效結合

2. 為什麽要「合體」？

浮動型文本輸入框適用於多輸入框的頁面，因為它可以解決以下問題：

1）減少用戶的認知障礙。

在多輸入框的頁面，如果有固定標題的展示，用戶進入頁面後會看到很大篇幅的輸入框，影響用戶對頁面信息的獲取及關注。

採用浮動型文本輸入框可以減少文本信息對用戶的干擾。

2）在第1點的基礎上，可以輔助用戶明確當下輸入的內容是否正確有效，可以解決用戶對當下輸入的內容需要小標題去輔助其認知的場景。

3. 「合體」要注意什麽？

1）注意浮動型輸入框輸入框的高度

在保證輸入初始狀態美觀度的同時要考慮標題出現的空間。

2）注意錯誤反饋的出現方式及位置

如果是用戶未輸入內容，其提示可以高亮佔位符文本及輸入框告知用戶；若是輸入內容不符合規則時可以在輸入框下方延伸錯誤提示的區域，同時高亮輸入框。

3）注意鍵盤的處理

用戶在進入輸入狀態時會拉起鍵盤，這時候可以把鍵盤「確認」的按鈕改為「下一項」，即確認當前輸入框的內容同時進入下一個內容輸入——這個設計適用於多輸入框的表單場景，可以減少用戶操作。

這裡需要特別提醒：到最後一項輸入時，記得把這個按鈕改為「完成」。

多項輸入時鍵盤按鈕的變化

 “潛”規則四 

披上馬甲就是“新”的自己

前面我們有說到特殊場景的輸入框，如輸入驗證碼、輸入密碼、進行搜索等等。

這樣的輸入框看起來像是一個輸入框，又不像是輸入框的範疇，根本原因在於其規則場景比普通的輸入框多了許多限制或功能。

1. 驗證碼輸入

驗證碼輸入是限定了輸入字數和字元類型，對輸入內容的校驗具有時效性，對此不展開多說，相信大家都不陌生。

2. 密碼輸入

密碼輸入通常也會有字數的限制和字元的規則限制，同時還帶著密碼可視的功能。

3. 搜索框

搜索框的場景規則可謂是相當複雜，給用戶提供的搜索建議、搜索歷史記錄、搜索生效規則、再次編輯的規則等等，後續我會再寫一篇文章進行具體分析。

簡而言之，關於規則的定義永遠是服務於當下的用戶場景，我們需要思考在極限情況下可能會出現的偏差以及解決方案，特別是在C端的產品上，差之毫厘的設計可能造成失之千里的後果，結合場景的思考是一件很有意思的事情。

以上是我們的一點思考與總結，與大家共勉。

—————— / END / ——————

▼ 喜歡請分享，滿意點個讚，最後點「在看」 ▼