中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：表單可以被拆解為標簽、輸入框、按鈕三個基本要素，在進行這些設計時，往往會有無數疑問從細節中冒出來，要怎么解決呢？本文作者對七個常見的問題進行了分析解答，一起來看一下吧。

按鈕的圓角用多大，標簽后面是否用冒號，選填必填怎么區分，線索模式和說明模式應用區分……針對這些小細節問題有時候感覺非常頭疼，一邊不停地催稿，一邊不停地糾結這些細節，最后大家一起合作的往往五花八門，而單獨頁面改版也不是一直存在的事。

提起表單，相信我們往往用最直覺的設計經驗本能驅動我們去解決一些看似在界面設計中的問題，但每到細微之處，又會有無數疑問從細節中冒出來給我們造成困擾。今天的分享有點冷門，希望能拋磚引玉，引起大家的重視。

表單基本形式可以被拆解成三個最基本要素：

1. 標簽（標題）
2. 輸入框
3. 按鈕

標簽是用來提示用戶列表項是什么；輸入框是用戶信息錄入的；按鈕是供用戶完成信息錄入后進入下一個流程的。

問題一：輸入框是否放入清空按鈕？

1. 單行文本

輸入賬號和密碼后面往往有個「清空按鈕」，因為密碼輸入默認******，無法直觀看到哪個字符輸入錯誤，全部清空重新輸入就非常符合用戶場景。寫到這想起來搜索后面也是有「清空按鈕」，那就是常見表單輸入框后面是沒有「清空按鈕」，特殊場景才會有，那么怎么判斷輸入框是否放入關閉按鈕呢？

各種功能場景用戶主要希望要快，無論在登錄注冊還是搜索場景下，除了本身內容外，最注重的就是效率。

在APP進入市場時往往有業務指標是注冊量、留存等，所以設計師會在登錄注冊的操作流程中抓住提高效率的每個細節，這時候輸入框的交互效率至關重要，一個是與業務指標掛鉤，另外一個在電商行業高效率某個程度來說是可以提高成交率的。

2. 搜索場景

搜索也是也是一樣，當用戶使用搜索框時是有明確目的的，關鍵詞就是用戶當前最關心的。如果輸錯或換一個關鍵詞則需一個個刪除，這樣反而沒有清空來得快，特別在電商行業決定用戶買不買就在那一兩秒。

這類場景下的「刪除」功能作用是「清空」，其主要原因是快捷方便，在符合用戶預期目標場景下最節省刪除成本。

3. 多行文本

為什么我們在淘寶上買商品，在商品不符合預期時往往編輯一大段話描述不好的特點，甚至還附圖佐證，這時候后面沒有清空按鈕呢？

這里存在「輸入成本」與「修改成本」，它不像搜索和登錄幾個關鍵詞或一串數字就可以了，它是需要別其它用戶能看明白并了解商品屬性的一段文字。這時候輸入成本高，如果這時候放了「清空按鈕」，用戶原本是希望修改個別文字，如果誤點了「清空」就需要重新輸入一大段文字，這時候輸入框中的「清空」有誘導操作嫌疑。

當然我們有多種操作方式讓用戶重新輸入，比如鍵盤滑塊定位，觸摸連續幾個字等都比清空后重新輸入成本低很多，也不需要清空的便捷性了。

綜上所述：在我們需要清空按鈕時，我們的輸入成本和修改成本是低的，以便提高輸入的便捷性；當輸入成本較高時，清空按鈕是不合適的。

問題二：單行文本框長度多長合適？

很多設計師在拿到需求的時候，都會潛意識追求視覺上的對齊，強行將表單寬度定位統一寬度，這種處理方式沒有深入思考用戶實際需求場景，在web端錯落有致會比左側整齊劃一更舒適，更有節奏感。

表單的寬度應該向用戶暗示所需輸入內容的長度來減輕判斷負擔。如下圖案例，一個房屋面積可預估的情況下，用右側輸入框等寬處理容易誤導用戶對所輸面積的判斷，需求多次確認信息無誤。

錯落有致也得有個規則，沒有規矩不成方圓，也沒法系統的沉淀出設計規范去延展，我們的目標就是讓表單設計有規律的錯落有致，這時候就想到了「柵格系統」，大家可以翻前期文章有寫web端柵格系統。

每一類的表單輸入區域都因其錄入存在合理的寬度，輸入區域的寬度剛好暗示其填寫內容的長度，合理的輸入寬度不僅給用戶帶來心理預期，也提升了整個表單的操控感。

注意：匹配合適的鍵盤

根據表單內容的不同屬性，應對不同的輸入需求，應該提供不同的鍵盤類型，以便于用戶使用更加快捷。常見鍵盤有以下類型：

• 設備系統內置的輸入法，或者下載符合我們長期使用習慣的輸入法APP
• 涉及資產安全方面，提供打亂字母及數字順序的鍵盤，可以防止窺竊，提高安全性
• 數字輸入，提供純數字鍵盤，能夠提升用戶的完成效率，讓輸入變的更簡單

問題三：標簽后是否帶冒號？

連起來的句子往往是帶有冒號的，比如見賢設計筆記：B端產品設計總結，這里的冒號帶有解釋上文的意思，那么我們標簽和輸入框之間是否需求冒號呢？

國APP上比較少看到冒號，但這并不是沒有如下圖Mac系統設置：

度娘說：冒號通常表示提示語后的停頓或表示提示下文或總括上文，它的后面可以是一個例子，一個引用，或者一個解釋，那從情感角度分析標簽帶冒號的是否對用戶體驗有影響呢？其實無任何影響！

所以如果我們設計有冒號，那請一直保持；如果沒有冒號，可以不需要冒號，保證頁面一致性即可。

1. 冒號對齊

冒號對齊（右對齊）能讓內容鎖定在一定范圍內，讓用戶眼球順著冒號的視覺流，就能找到所有填寫項，從而提高填寫效率。

2. 在上個層級的標簽和冒號同時存在時，我們這時候怎么對齊呢？

我們最好確定統一的起點，如下左圖，當然在使用的過程中需要判斷用戶使用場景，如下右圖是12306修改乘車人信息，用戶注意力在信息上，標題僅起到區分模塊的作用。

問題四：為什么優先進行在線驗證？

我最初入行和研發小哥哥就爭執過登錄頁面，密碼輸入后需要點擊登錄按鈕才能判斷密碼是否正確，如果在輸入密碼后直接判斷密碼錯誤就少一步交互，對老年用戶來說少一步就是進步一大步。為什么密碼輸入后不能直接判斷密碼是否正確呢？

1. 在線驗證

在以往的網頁設計中，信息填寫的正確與否都要等待用戶點擊「提交」按鈕后，產品將用戶填寫的數據提供到服務器，由服務器來判斷是否正確。這種方法太過于依賴網速，并且不符合用戶體驗中的「及時反饋」原則。

所以現在產品設計，在數據還沒有提供給服務器之前，先在前端進行一些基礎的錯誤排查，即在線驗證。

一些基礎的規范，如郵箱是否加上了 @xxx.com ，都是可以通過在線驗證的，而無需上傳到服務器去比對數據庫。

理想情況下，所有用戶填寫的信息都應該先經過在線驗證。用戶填寫完字段后，如果包含錯誤，應該立即給予反饋并將錯誤提示消息放置在用戶填寫字段到附近。這樣，錯誤提示容易引起用戶注意，對于用戶的交互成本也低。用戶不必要重新查找和導航到錯誤位置。

需要比對數據庫的信息可能無法進行在線驗證，那就還是當用戶提交將信息發送給數據庫后再提示錯誤。也就是是說前端只能進行簡單的驗證，比如手機號位數不對、郵箱格式不對等，判斷密碼是否正確需要后端對比數據庫才能判斷，這時候就需要點擊提交按鈕。

左圖一輸入賬號后里面提示不可用，方便用戶及時修正；而圖二需要輸入手機號驗證碼點擊提交后再提示錯誤信息，從信息反饋上來看，全部輸完了提示錯誤，交互過于繁瑣。

• 前端校驗：一般校驗顯示錯誤和格式錯誤：必填項、（郵箱、電話號、地址）格式、密碼強度等?？焖俜答?，直接提醒用戶錯誤內容，讓用戶及時知曉并更改。
• 后端校驗：唯一性驗證、驗證碼、敏感詞等，觸發校驗請求后系統會去數據庫查詢校驗信息，再給予用戶相應的反饋。

2. 復雜字段設置填寫成功指示器

同樣的，在線驗證也可以用于提示用戶填寫的內容符合規定。謹記錯誤預防準則：提供給用戶相關的建議，將用戶的輸入值限制為合規的范圍內，并允許輸入錯誤、縮寫和不同的輸入格式的存在以保證產品的兼容性。

對于復雜的輸入（例如輸入新密碼），即時的在線驗證（在輸入字符的一瞬間提示）將防止用戶多次猜測或檢查輸入的內容是否符合系統的設置。在下面的示例中，密碼強度指示符會隨著用戶的輸入而變化，并幫助用戶確定到目前為止的輸入是否合規，還是要繼續改進。

另外不要過于關注這個「進度指示器」。優秀的進度指示器不應該分散用戶填寫表單的注意力，僅僅當添加這個「進度指示器」有助于用戶填寫時，才應該使用。

3. 將錯誤信息一直保留在輸入框旁邊

通過在線驗證，錯誤消息會自然的顯示在輸入框旁邊。有一些基礎的規則，或者用戶大概率會出現的問題，即使用戶還未填寫任何信息，也應該以備注的方式在輸入框下方標注，這是一種非常有性價比的行為，將錯誤信息一直保留在輸入框旁邊可最大程度的減少用戶思考。

4. 錯誤提示該放輸入框哪個方位？

登錄注冊這塊錯誤消息的兩個最常見的位置是表單頂部置和輸入框行間那么到底那個位置對用戶來說更直觀呢？

根據上下左右四個位置，根據瀏覽習慣列舉出考慮每種情況的設計圖一邊分析。

1）右邊

• 遵循讀取文本的自然流程
• 用戶最喜歡和期待的方式

網頁端微博注冊如圖錯誤提示放輸入框右邊，符合人們從左到右從上到下的閱讀習慣；用戶視覺路徑自然流暢，很大程度上減少了用戶的視覺工作。

Web端輸入框較長時，輸入字段后面往往大段空白，接著是錯誤提示，這時候視覺上也存在來回跳躍感；

而移動端屏寬右邊顯示不了錯誤提示，所以錯誤提示常出現在輸入框下側，若網頁和移動端設計保持一致時，錯誤提示就出現在輸入框下側了。

2）左邊

• 違背讀取文本的自然流程
• 用戶最不喜歡的方式

錯誤提示在左側與用戶期望相違背，因為錯誤提示左側放置更高輸入框的優先級。但事實上用戶需要專注于糾正他們的輸入，因此輸入框應該是更重要的元素。

3）上邊

• 與輸入框的提示標簽距離太近造成混淆
• 視覺壓力更大

當標簽在頂部時，一共存在標簽、錯誤提示、輸入框中的文本3個提示，當用戶輸入錯誤時，視覺來回在標簽、錯誤提示、輸入框之間交換，用戶注意力被分散，認知負荷增加。

4）下邊

• 遵循讀取文本的自然流程
• 對手機端用戶友好

放置下邊的錯誤信息提示，雖然不符合從左到右的閱讀習慣，但它確符合從上倒下的閱讀流程。

手機屏幕缺少水平空間，把錯誤信息提示放置在下方是個不錯的選擇。

輸入框顯示錯誤信息是更加減少用戶認知負擔，可以當場識別錯誤而不需要視覺來回切換，減少記憶負擔，在表單底部和頂部。

5. 錯誤提示與其它內容視覺上區分

出錯之后，用戶需要迅速注意到報錯信息。大多數使用警示色紅色，紅色面積過多往往給人壓迫感，產生畏難心理，所以在其它地方盡量減少紅色使用。

另外考慮到色盲的用戶需求，我們在錯誤提示時不僅僅使用顏色標注，比如可以加入表示錯誤的icon，當前內容抖動等，比如QQ登錄抖動提示，蘋果電腦的鎖屏密碼錯誤抖動，或現在適老化的語音播報……

上圖是新版花瓣和國外printerest登錄界面對比，由于主色調都是紅色，而錯誤提示也是紅色。當用戶光標聚焦輸入框正在輸入時，花瓣已提示錯誤，整體視覺提示是過重，設計相比之下稍遜色與printerest。

典型反面案例：下圖是追波注冊流程，由于3個問題沒做好，在表單過長的情況下，用戶極大可能性流失。

• 輸入前用戶名沒有引導說明
• 輸入后未激活用戶名和郵件沒有實時反饋（前端格式未校驗）
• 完全輸入后由后端校驗，錯誤太多，用戶易產生畏難心理（為了方便看，輸入后已激活圖三翻譯成中文）

問題五：用「線索模式」還是「說明模式」好？

1. 線索模式

是指用示例輸入或說明文本以占位符的形式顯示在輸入框中，以幫助用戶理解需要輸入的內容，或給出相關線索的一種設計方式。信息表達輕盈、簡單、與業務邏輯關系弱。

時間控件中有“請選擇日期”，輸入框中會有“請選擇日期和日歷icon”等線索文字，這就是線索設計模式。

假如下圖Facebook輸入框什么文字也沒有，用戶預期可能是輸入或其他，因為設計者沒有給用戶框定搜索邊界，因此線索設計模式可以讓界面不言自明。

線索模式特點：

• 更好的幫助用戶理解輸入框要求輸入的內容
• 文本提示的位置應該和輸入值的位置一致
• 配合下拉菜單或者組合輸入框使用
• 使用祈使句，以動詞短語開頭，以描述輸入內容的名詞結尾，例如“請選擇狀態”，“請輸入您的賬號”或“請輸入患者姓名”等
• 輸入線索的內容位于用戶輸入的位置，因此用戶會注意到這個地方

2. 說明模式

是指在空白文本字段的旁邊或下方，放置一個短語或示例，以解釋此處需要輸入的內容或提供關于此內容的詳細要求及信息。

說明模式特點：

• 使用戶無需猜測，同時可以進行上下文提示;
• 使輸入框前的字段保持簡潔，不要包含太多文本，使用戶能夠快速明確要輸入內容;
• 視覺上將說明模式與線索模式的字段區分開，可以使已經知道要做什么的用戶忽略該說明，并將注意力集中在輸入操作上;
• 帶有引導性的文案處理，會促進用戶優化填寫方案;
• 操作項一側或下方，提示需要輸入的文本的具體要求和注意事項

典型案例：下圖第一個案例每一項后面都有對應的輸入說明和輸入線索，比如社交賬號后簡單的說明了其作用， 讓用戶迅速了解填寫什么內容更合適。

另外，好的引導能激發用戶的填寫欲望，比如QQ個性簽名輸入線索展示我的獨特態度，非常符合年輕人的定位，填寫幾率也大大增加了。同時也吸引其他好友的關注，使用戶之間互動更頻繁，平臺也能因此更活躍。

3. 該用線索模式還是說明模式？

慎單獨用線索提示，當輸入內容過多時，可能會忘記這個提示，適用于簡單的輸入框，如注冊、登陸界面的表單，輸入框的長度如果不用暗示信息長度，需要統一輸入框長度。

如下圖iconfont極易忘記輸入新密碼的要求，當輸入時候會疑惑密碼是要字母/數字/符號三者組合，還是單一組合即可。

另外輸入錯誤時會發現和提示內容和輸入前不一樣，也會造成不解，這些我們在設計過程中盡量避免。

4. 對比：「線索模式」VS「說明模式」

「線索模式」與「說明模式」都是輔助用戶輸入的設計模式，這些模式可以幫助用戶明確輸入信息的內容形式。那么這兩種模式有什么差異性呢？

使用說明模式時，快速瀏覽界面的用戶可能會輕易地忽略說明信息，因為此時用戶的目標是盡可能快地填完表單，進入下一步操作。

因此，過多的文本說明也會給用戶帶來較大的視覺壓迫，所以說明模式下的文字往往簡短易懂。

Google 注冊賬號頁是結合使用「輸入說明」與「輸入線索」的一個典型案例。通過使用「輸入線索」告訴用戶需要填寫的內容，通過「輸入說明」來補充填寫信息的相應意圖，進而使得用戶可以清晰地意識到需要填寫什么，并輸入相應信息。

問題六：非單選又非多選的選擇該怎么設計？

關于單選、多選、開關3種對比設計很多文章都寫過，但是是不是往往忽略了一個場景，單選和多選都是有多個選擇的場景，那如果只有一個選項用開關設計形式又不合適，這時候該怎么設計呢？能簡單把這個場景直接歸類為單選或多選嗎？為什么呢？

是否選擇有的產品用圈，有的產品用方塊，那么到底是處于什么場景下考慮這個圈和方塊呢？我一直相信做的越好的產品中任何符號都有其緣由，現在我們先假設2款產品不同是有其道理

1. 谷歌規范定義

復選框：允許用戶從一組中選擇一個或多個項目。

兩個關鍵點：

1. 從列表中選擇一個或多個選項
2. 顯示包含子選項的列表（非必要）

單選框：單選按鈕允許用戶從一組選項中選擇一個選項。

兩個關鍵點：

1. 從列表中選擇一個選項
2. 公開所有可用選

2. 問題思考

我們看到電商產品比如淘寶京東購物車，無論單選還是多選都沒按照谷歌或iOS規范，我們看到登錄時勾選政策時勾選也是2種設計形式存在，如果你拿著這個結論去和產品交互溝通最后可能就是拍腦袋決定，非常不利于后續設計工作的展開。

不管是國內常用產品還是國內競品截圖，都沒有嚴格按照某一規范來制定單選或多選的設計形式，甚至同一款產品多個不同業務線多選形式也不一樣。

我們繼續深挖以下3點：

1. 是否和系統有問題，查看安卓和iOS系統
2. 競品的應用方式，以及他們是否具有參考性
3. 線上相關文檔資料支持

針對這3點呢我們就會有個途徑去論證我們的設計形式是否正確。

Android使用與 Material規范保持一致，IOS使用上單選和多選沒有明確區分，可以直接使用勾選

即：iOS和安卓不同系統上單選和多選還是存在一部分差距。

由此說明，行業內并沒有明確規定單選和多選的設計樣式，各個產品都是根據各個產品的規范所得出，只是我們常?？吹絿鴥犬a品政策勾選是「圈+勾」，看得多了就習慣認為是這樣，但其實并沒有過這樣的規則。生活我們往往習慣把某個具象的內容抽象化，把某個具體的問題概念化，這也是我們常常說的歸納法。

因為我司產品是臺灣地產項目，所以這時候的競品需要符合臺灣用戶使用習慣。臺灣和大陸用戶不同，更多是受國外互聯網影響，我們查找了臺灣用戶用的比較多的網站，勾選這塊更多是方塊。

所以說設計工具/方法論，常常具有指導作用，但不能作為絕對性或權威性的內容來吸收，應該辯證地去看。而之所以在移動端延伸出許多自定義組件（形式并沒有遵循所謂的市場常見規范），是因為業務與功能的多樣性導致的結果。所以樣式的選擇不單單是看到的那部分，不該被樣式表面套住，內容是它的決定性因素。

比如用戶知道鬧鈴只能選擇一種，不會同時有 2 個鈴聲響起來，所以即便鬧鈴的單選形式再如何變化，也都知道它是單選的，這就是功能決定了操作形式的例子。再比如用戶知道設置鬧鐘的時間，可以同時選擇周一到周天，就算用單選的設計樣式，用戶也知道他是可以多選的。

類似于，無論如何變化選擇樣式，無論是圓圈、方框，或只有勾，甚至是其他情況，大家也都知道它就是單選。

所以只要梳理出符合自己產品的「單多選」樣式，形成規范即可。后面遇到符合規范中已有的形式的，就遵循，不符合的就不遵循。

單純說什么時候該遵循，什么時候不該遵循，是很概念化的一個問題，不可能存在一個具體話術標準，說什么時候應該，什么時候不應該的。

問題七：必填項用「*」還是「必填、選填」？

用紅色「*」標注必填項常出現在標簽前面，是一個比較清晰標志必填項的方式，并且還很節省空間，也能在一定程度上起到視覺降噪的作用 ，提升可讀性和填表率。

而必填選填跟在標簽后面，往往與標簽文字同色，移動端標簽在左輸入框在右時，不僅增加了標簽的長度，而且增加了閱讀的難度，回頭核查時也更不易察覺。若選填必填在輸入框內與提示信息一起，當文字輸入時用戶常常會忘記是必填還是選填。

用「*」時我們需要注意：

• 「*」對用戶來說是否理解
• 必填項總是比選填項要多，紅色的星號會讓用戶更加畏懼，這會增加錯誤風險并降低表單完成率。 比如我們當必填項較多時， 我們會看到滿屏的「*」，這個時候我們內心往往是崩潰的

1. 用「必填、選填」場景

有一些產品選擇了「必填、選填」，原因在于：假如總共有10個表單項，有9個表單項必填，1個選填，那么為了界面整潔，就可以給選填的表單項備注「選填」。假設剛好相反，1個必填9個選填，那么給必填的表單項備注「必填」，當然這個時候也需要要考慮這些選填項的必要性了，設計的目的及作用。

當然表單較少時，可以利用用戶與界面的交互，告知用戶選填必填。如上圖必填項未操作時，提交按鈕未激活不可操作；當必填項操作后，按鈕激活可以提交表單。

綜上：

• 所有必填可不用區分
• 使用帶 * 標記加入標簽提示，來告知用戶必填字段，選填字段不做標記（使用時考慮用戶接受度）
• 必填字段過多時，不用做任何標記，選填字段標簽處備注「選填」
• 避免必填和選填字段同時標記或者都沒有任何標記

總結

本篇文章更多是從表單設計中的一些平時工作中遇到的小細節，極易忽略和遺忘的一些設計點在展開說明。利用問題加案例把每一個細節剝離拆解，沒有系統地、成本成套的來分析表單的構成和交互細節等等，因為這類內容講的人太多了。

同時，我也希望能夠通過這篇文章給到大家更多的啟發，一起探討進步。

本文由 @見賢設計筆記 原創發布于人人都是產品經理，未經許可，禁止轉載。

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