2020-12-4 ui設計分享達人
結合理論落地項目功能，從邏輯層面思考問題。
節前有一位讀者問了一個關于單選與復選框樣式選擇的問題，大概是：
看到很多單選與多選的設計形式，多種多樣，以前看到「圓點+圓圈」就知道是單選，但是為什么現在單選與多選的設計樣式五花八門，都沒有遵守前面這種規范呢？這些組件的樣式到底該如何確定呢？為什么會有一種模糊不清，不知道如何使用的情況？
我發現許多人都有一個習慣，就是喜歡把某個具象的內容抽象化，把某個具體的問題概念化。
比如認為單選就應該是「圓圈+圓點」的形式，但似乎從來也沒有任何明文規定單選就必須是這樣的形式，只不過大家看得多了，就習慣認為是這樣，覺得就是這樣規定的，但其實并沒有過這樣的規則。
要知道，樣式常常根據功能在變化。比如功能優化了，樣式也需要進行修飾，并不是說這里有一個單選操作，就必須是「圓圈+圓點」的形式給用戶選擇。無論是在電腦還是手機上，都是一樣的道理。
這樣去處理問題，常常會把實際的業務問題給處理沒了，最后變成控件選擇的問題，而不是功能本身的問題。
比如普通的彈框，也是一種單選狀態，為什么不也改成下圖右邊這樣的呢？不就是操作路徑長，點擊起來麻煩，多此一舉，而且也不好看么？
即便真的在某個場景下，非得使用上圖右邊的單選形式，那么把樣式改成下圖這樣，又有何不可呢？
只不過常規的「圓圈+圓點」被使用得多了，大家形成了共識而已，但并不代表它就是一種標準。
如果有一個規則規定說，單選必須是「圓點+圓圈」，那么各位目前所設計的絕大部分組件都將不能使用，包括各類菜單或開關。比如下圖這樣的 action sheet 就不應該存在，而它的出現也是因為功能屬性、設備遷移、操作形式等內容的演化所呈現的結果。
這就是大家在處理設計問題時，習慣做一種概括，希望能復用于絕大多數場景而導致的錯誤情況，沒有落實具體問題具體分析的原則。
包括這位讀者的問題，也是希望能夠明確單選與復選樣式的選擇問題，以便往后能夠更有條理的使用。但可惜并不是這樣，從上述我舉的控件例子可以看出，單選形式早就已經變了模樣，而多數人并沒有注意到，還在認為單選與多選就應該是圓圈與方框的形式。
設計工具/方法論，確實是有部分指導作用，但不能作為絕對性或權威性的內容來吸收，應該辯證地去看。
而之所以在移動端延伸出許多自定義組件（形式并沒有遵循所謂的市場常見規范），正是因為業務與功能的多樣性導致的結果。
樣式的選擇不單單是看到的那部分，它還可以任意變化地處理，無論是單選或者是多選，不該被樣式套牢了。而它的決定因素應該是內容。
比如，iOS 鬧鐘的鈴聲選擇，有許多可選項。
但是因為內容的明確性，大家都知道，鬧鈴只能選擇一種，不會同時有 2 個鈴聲響起來（當然也可以這么做），所以即便鬧鈴的單選形式再如何變化，大家也都知道它是單選的，這就是功能決定了操作形式的例子。
類似于，再如何變化選擇樣式，無論是圓圈、方框，或只有勾，甚至是其他情況，大家也都知道它就是單選。
而之所以用勾或圓點表示被選中狀態，只不過是人的一種正常認知意識，即使改成三角形，只要能說清楚是被選中狀態，那也不是不行，只不過三角形沒有勾來得清晰罷了，而并不是因為有什么特殊含義。
所以只要梳理出符合自己產品的「單多選」樣式，形成規范即可。一些人會感到模糊不清的原因是它本來就沒有所謂的標準，又何來的清晰呢？
寫到這，想到之前有讀者問：什么時候該遵循設計規范，什么時候不該？
要知道，設計規范本身就是基于某個具體產品內容所構建的一個整合標準，為了規范化存在共性的功能形式。而對于共性的判斷也應該是從功能來定義的，比如返回都在左上角類似的，但是一定么？
單拎出來說什么時候該遵循，什么時候不該遵循，是很概念化的一個問題，不可能存在一個具體話術標準，說什么時候應該，什么時候不應該的。
如果我回答，符合規范中已有的形式的，就遵循，不符合的就不遵循。那就是一句典型的廢話了。但除此之外，我也就不知道如何解答了，除非你把規范和具體問題發給我，我可以跟你一起討論討論。
寫這篇文章的時候，看到一位朋友發的信息：
為什么手機刷新都喜歡下拉？因為神經科學研究表明，這個動作，更容易讓人產生對不確定性和驚喜的期待，原理和賭場的老虎機類似。
很多人都會習慣性給一些操作或交互形式做類似這樣的定義。
但這么定義是不對的，因為這相當于前面說的，把業務給解釋沒了，成了形式上的討論。而為什么會使用下拉、以及下拉會有什么情況，包括它所解決的問題，都沒有任何的分析。
比如，下拉之所以讓人上癮，并不是因為「刷新」本身。下拉只是一種交互行為，它的出現也只是為了解決早期刷新按鈕占據屏幕空間的問題，希望通過下拉進行刷新，以隱藏掉屏幕上的刷新按鈕，給屏幕留出更多可用空間。
而采用下拉是因為它更符合人的直覺 —— 往下拉能看到更多新的內容。
但是人之所以會對下拉上癮，并不是因為下拉這個行為，而是因為下拉能看到更多信息。下拉本身只是解決了屏幕空間的問題，而人其實是對內容上癮。
比如我在騰訊新聞里看 NBA 的資訊，通常只會直接上滑，看下面的內容，看完了就關了，不會進行下拉刷新。
因為在騰訊新聞里，下拉刷新的新聞并不是的內容，更多是今天或今天之前的信息，不刷新反而是剛剛更新的資訊，那么下拉刷新雖然也是刷新，但是刷新出來的內容是舊的，也并不吸引我，反而成了我要避免的操作，因為只要一下拉，的資訊就會被舊的資訊擠掉，要刷掉進程重新打開 App 才會重新再顯示的。
所以就不能簡單的定義說「下拉刷新是一個容易讓人上癮的操作」，而是要關注內容，如果刷新的信息都是舊的，或者是用戶沒興趣的，那即便刷新了，也不會引起用戶的注意，也更不可能讓用戶上癮了。
讀者：
呆呆，這個圖的卡片列表里，標題用省略號合適嗎？
（因為原圖涉及讀者項目隱私，所以重畫了個草圖。）
又是一個沒有業務背景的問題。不過這個問題比較簡單，可以展開來說一下。
通常，我們會在各類產品里面見到諸如「標題超出部分用省略號顯示」這樣的設計，譬如上面這圖。
于是，許多人在自家產品的設計過程中，遇到此類情況，被開發問到時，也會搪塞一句：文案要是超出就「…」顯示吧。
大多數遇到這種情況的，都是因為之前沒考慮好，才臨時想了這個解決辦法。
而很多時候，一些產品之所以用「…」顯示，并不是因為單純地文案溢出，可能是專門設計過的。
所以，如果簡單地認為「…」就是解決溢出而使用的方法，那就有問題了。
下面舉幾個例子。
有些產品，我們幾乎看不到列表視圖里的標題是有省略號的。
因為這類產品的目的就是讓用戶讀到完整的標題信息，對眼前的內容好做判斷，從而考慮是否點進去看詳情。
所以在設定的時候，界面中標題字數的規定，與界面樣式就已經提前規劃好了，可能在后臺設置就限定死字數，要求運營人員上新時要統一界面的展示形式。
這種情況下，一般就不會再有省略號的問題，譬如一些知識付費類產品。
比較典型的還有 TED 演講視頻的標題，在《設計體系》這本書里專門提到了這個案例。
對于 TED 來說，演講標題的信息優先級是最高的，所以他們寧可保留所有標題文案，也不對文案做截斷用「…」顯示。
因為對標題做截斷是很容易的，而難的是把一個演講主題提煉成一句簡短句子，所以他們為了展示更清晰的標題，寧可在界面上保留長標題，甚至為長標題的顯示而專門設計相符合的展示形式。
反過來，他們也因為這一點而確定了界面上標題字數的上限，確保文案不會超過界面顯示的最大臨界值。
包括一些資訊類產品，在標題上也會做限制，以滿足最大化呈現且不使用省略號。意思是：假設界面上文案范圍定了 30 個字符，那么配置的時候就必須 30 個字符以內把內容表達清楚，且必須完全顯示在界面上。
所以經?？吹揭恍?UGC 產品之所以會限制標題字數，原因除了常見的標題不能過長之外，還有一點是為了在列表頁就能顯示完整。
各位在設計這類產品功能時，也要注意到這一點，而不是隨意說一個「字符不能超過 50 吧」。
而有些產品的內容列表，之所以頻繁使用省略號，它的目的是為了引導用戶點擊用的。
這類形式一般出現在營銷號發的文章里，多是營銷人員自己為了文章點擊率而做的。很少會有一款產品的所有內容都是這樣的，除非是一些內容產品，運營方是企業自己，為了讓產品上的內容有更多人點擊而這樣去設計，當中可能涵蓋了廣告，以此賺取廣告費。
不過這類內容的設計已經讓用戶開始反感，所以如果不是特殊情況，最好少這樣去做。
當然，還有同類型的，一般出現在頁面面積小且需要展示更多信息的集合類視圖，比如：
這種形式的設計，就是因為頁面上想展示的信息太多，以至于通過這類合集來展示某個模塊里的內容，營造出一種很豐富的感覺。
也就是利用「…」引導用戶點擊，表示信息沒有展示全，如果要看，就點開詳情，進二級頁面。
還有一些產品的省略號，純粹就是大家理解的，溢出就省略號顯示。
比如同樣是資訊或內容類，以文字為主的產品，雖然標題超出范圍用了省略號，但用戶基本也已經知道是什么內容（上面那個集合類視圖也是一種），且還有摘要引讀。
比如下圖：
這種標題字符限制在了兩行以內，多余字符用「…」展示，基本上已經是一句完整的話，能讓人大致了解這條信息的意思。并且還有部分摘要，已經足夠用戶判斷是否對它有興趣，如果沒興趣，直接刷走也無所謂。
包括一些電商類產品，用戶多以商品圖片為主要決策因素，商品標題作為輔助信息，優先級不高，所以標題溢出是否省略號顯示也無所謂。
這其中有一個特殊情況，就是有些產品的標題即不展示全，同時又沒有省略號，比如淘寶的商品搜索結果頁面。
因為這類列表實質是一個產品賣點集合的濃縮詞，不是完整的一句話，多余字符展示或者不展示，都不會有太大影響，所以也不重要。
當中我比較反感的還要數農藥了。
好友邀請的列表視圖里，常?？床蝗欠Q，因為好友會有游戲昵稱，微信備注會展示在游戲昵稱后面，以至于要點到游戲關系里先看全昵稱，再到匹配界面邀請好友。
既然已經區分了微信好友與游戲好友，為什么昵稱上面不也加以區分呢？
當然，經常玩的好友可能沒這個必要，畢竟頭像或昵稱都可以很快識別出來，但是偶爾一起玩的好友通過這樣的識別方式就比較難了。
這里就是簡單提一句。
通過上面提到的一些例子，以及不同場景下標題省略號的處理方式，相信大家對這塊的理解會比之前更深。
同樣，對于開篇讀者提到的問題，更符合的情況可能類似于知乎這種，有完整句子，所以標題是否省略號處理也就沒太大影響。
但具體的還是要結合業務詳情仔細考量。
而標題內容的展示是否要用省略號處理，優先要看這條信息的業務權重，以及是否會影響用戶決策。
所以各位在設計這類內容標題是否要用「…」顯示時，也要注意判斷自己的產品特性符合哪種類型，而不是隨意一句話，說「超出就省略號顯示好了」。
最近收到兩個問題，正好都與輸入框有關：一個是怎么判斷輸入框要不要放置清空按鈕；另一個是輸入框超過限制后，是禁止用戶繼續輸入，還是允許超出但會警告提示。
在一定程度上，這兩個問題的分析邏輯是類似的，所以放到一起聊正合適。
先看第一個問題：怎么判斷輸入框里要不要放置清空按鈕？
原問題是這樣的：
呆呆，我最近在優化公司的產品，遇到一個問題，就是 PM 想在聊天輸入框里加一個「清除按鈕」，可我覺得不太合適，但是說不出原因，只能說沒見過在聊天框里加清空按鈕的。這個問題要怎么判斷呢？
我們一般會在搜索、手機號輸入框里看到類似的清空按鈕，比如輸錯了就點一下，清空后再重新輸入。但是很少會在聊天框里看到清空按鈕，為什么呢？
主要是「時效性」…算了，這種概念詞用多了，發現現在人都不會講話了。說白話就是「要快」。
無論在登錄注冊還是搜索的場景下，除了內容本身之外，最注重的就是效率。
譬如有個數據大概是說，用戶登錄注冊花的時間超過某個范圍，轉化率就會對應逐步降低。而率，就是讓用戶能快速登錄注冊賬號，使用產品功能。所以設計師們會在登錄注冊的操作流程里抓住可提率的每個細節，輸入框使用效率就是其中之一。
搜索也是一樣，當用戶有明確目的使用搜索框時，關鍵詞就是用戶當下最關注的信息，如果輸錯，再一個個刪除，顯得麻煩，所以清空按鈕能在這里提高用戶的操作效率，甚至 iOS 的搜索組件也會自帶一個清空按鈕。如果是電商產品，率是能間接提高成交率的。
這里的輸錯，也有兩層意思，一個是用戶在輸入過程中發現錯字，比如登錄注冊時，發現手機號輸錯了，一個個刪除反而沒清空重新輸入來得快，因為刪了之后，號碼要重新背一遍，具體到某個數字，然后接著輸，特麻煩。
或者搜索內容時，發現有錯別字，刪除某個字再重新輸入，反而沒有清空重新輸入來得快，畢竟輸入法有串聯關鍵詞組的功能。
另一個是反饋的結果不符合用戶的心理預期。比如輸入手機號已被注冊，或者搜索結果不滿意要重新輸入關鍵詞，使用一鍵清空都是比較的。
而且輸入之后，系統需要給用戶呈現結果，如果結果不滿足用戶預期，還會存在短時間內多次輸入與清空的情況。那么，無論是錯字還是對結果不滿意，清空按鈕都可以非常便捷地幫助用戶一鍵清除上次輸入的字段，讓用戶更快速地重新輸入新字段，從而提高用戶的操作效率。
于是，我們會把這類場景下的「清空」說成是「一鍵清空」，主要是因為方便。而它的作用就是，在出錯的場景下，更快捷地給用戶重置的操作。
反過來，各位可能要說：那聊天框不滿足這個條件么？
我們接著看聊天輸入框。
我們知道，聊天輸入框的內容不是固定的，它是根據對話內容而變化的，用戶甚至需要花時間持續輸入并糾正自己的用詞，以及話術的準確度。過程中，如果輸入的內容多，而且又是即興的，耗費的時間與精力也是很大的，清空后也難以再恢復。
它不像登錄或搜索，固定的輸個數字串或關鍵詞，它是一段完整內容。雖然也會有某一句話或者某個詞輸錯的情況，但是一鍵清空的操作成本太低，對應著聊天框的高輸入成本，一鍵清空的存在與之并不相符。
于是，這里就引出了一個概念，叫做「輸入成本」與「修改成本」。
清空按鈕對應的，就是低修改成本，因為簡單點擊一下，就清空了。它所適用的場景就是低輸入成本的情況，也就是前面提到的登錄注冊或搜索 —— 輸入的內容相對固定，且可能反復。
對于登錄、搜索等指向性比較明確的輸入框來說，用戶在乎的是輸入和反饋的效率高不高。一鍵清空操作能帶來效率上的提升，而且操作后帶來的損失成本是很低的。因此，一鍵清空操作在這個場景下，對用戶來說是安全且的。
但是在聊天場景下，一鍵清空作為低修改成本的作用是不適合的，因為這時候輸入成本比較高。
用戶在聊天輸入框內表達清楚自己的想法是為了讓對方理解，達到交流的目的，這樣的內容是不確定的。而且在聊天輸入出錯情況下，我們有多種操作方式讓用戶重輸，比如鍵盤快滑定位，觸摸定位錯字等，都比一鍵清空重新輸入的成本低很多，而它所謂的「便捷性」在這里意義也就不大了。
于是乎，在衡量輸入框是否需要清空按鈕時，我們首先要知道，清空按鈕是低修改成本，那么如果輸入框的輸入成本比較低時，我們就會使用清空按鈕，來提高操作效率。而當輸入成本比較高時，一鍵清空的操作就顯得配不上這個輸入框了。所以，它在聊天框里就沒有存在的必要了。
包括其他非固定內容的輸入框，也是一樣的道理。
接著，延伸出第二個同學的問題：輸入框超過限制是禁止用戶繼續輸入，還是允許超出但會警告提示？
相信各位讀完上面的，再看這個問題，應該也能分析出原因了吧？邏輯跟上面的也差不多。
也看輸入成本，比如是固定內容的手機號，我們正常會禁止多余輸入，因為這樣用戶更容易判斷手機號是否正確。
如果是短長文，說明用戶可能是手打字超出限制，這時候如果禁止輸入，用戶不好在輸入框里做內容刪減或修改，也會打斷用戶的輸入流，畢竟還沒寫完就限制了，那得先刪掉前面的，再來思考后面怎么寫，會亂。而且如果是復制的，禁止輸入的話，超出部分就被截斷了，也要先刪減，再繼續復制剩余部分，非常麻煩。除非先在別處刪減到限制字數內，再復制過來，但這樣又增加了用戶的操作成本。
如果允許輸入但警告提醒，那么用戶就可以根據自己已經輸入完的內容做刪減修改。
所以對于這個問題，我們從這個視角出發，也能了解一二，就是通過適用場景與輸入成本來分析。
當然，以上所有內容更偏向于通用性說明，針對具體業務還需要具體分析。
1、從單復選組件反思功能設計問題
2、標題文案溢出使用「…」合理嗎？
3、怎么判斷輸入框里放不放清空按鈕？
文章來源：站酷 作者：呆總、
藍藍設計( m.ssll180.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務