不知道大家有沒有這樣的情況發(fā)生，自己設(shè)計(jì)的作品，“乍一看不怎么樣，仔細(xì)一看，還不如乍一看”！

其實(shí)不耐看，或者不敢放大看的原因都是細(xì)節(jié)做的不到位。

最近在做手機(jī)OS的主題圖標(biāo)，對細(xì)節(jié)的感觸很大，今天結(jié)合主題圖標(biāo)來和大家聊聊，我們可以從哪些方面注意自己的設(shè)計(jì)細(xì)節(jié)，大綱如下：

• 給造型加點(diǎn)細(xì)節(jié)
• 多加點(diǎn)質(zhì)感的細(xì)節(jié)
• 不要讓圖標(biāo)看著灰灰的
• 風(fēng)格特點(diǎn)的運(yùn)用

1. 給造型加點(diǎn)細(xì)節(jié)

造型是所有設(shè)計(jì)執(zhí)行的第一步，造型做不好，說別的都沒用。

那如何能給造型加點(diǎn)細(xì)節(jié)呢？

打個比方，我們要畫一個圓角矩形：

如果您想訂閱本博客內(nèi)容，每天自動發(fā)到您的郵箱中， 請點(diǎn)這里

很多設(shè)計(jì)中，我們付出20%的精力就可以應(yīng)付80%的 Normal Case，而剩下20%的 Special Case 卻會花費(fèi)我們80%的精力。換言之，普通情況誰都會處理，而為了應(yīng)對一些少數(shù)派，我們將要付出更多。

Loading 失敗時的錯誤提醒、搜索無少結(jié)果時的空白頁面、打了車卻沒車接單……除了這正常流程下的失敗反饋以外，最耗時間的是那些特殊流程或所有情況同時在一個頁面堆砌出現(xiàn)的情況。

在設(shè)計(jì)前期，我們就應(yīng)該盡可能地羅列特殊情況，即便它們出現(xiàn)的概率很低，也應(yīng)留足設(shè)計(jì)時間。而應(yīng)對非常規(guī) Case 時，有一條原則幫了我很多次：

確保多數(shù)人體驗(yàn)的前提下，才去解決少數(shù)人的問題。

這不是說要為了多數(shù)人放棄少數(shù)人，還是造例子來說吧。

案例一：重復(fù)利用的物流單號

如果你在天貓有過退貨經(jīng)驗(yàn)就會知道，申請退貨并得到商家確認(rèn)后，需要填寫退貨的物流單號，當(dāng)商家收貨后才會把錢退給你。這里有個奇妙的問題，設(shè)計(jì)上是否允許多個用戶填寫同一個退貨單號？

先來看看如果允許，會出現(xiàn)什么非常規(guī)情況：消費(fèi)者AB兩人各自在同一個商家C處購買了兩臺 iPhone，并且商量好分別發(fā)起七天無理由退貨流程，商家C均同意。然后，消費(fèi)者A先將手機(jī)按要求寄出，獲取物流單號一個后填寫到退貨系統(tǒng)；同時，消費(fèi)者B直接使用消費(fèi)者A的退貨單號填入系統(tǒng)，但不寄送自己的手機(jī)。

極端情況體現(xiàn)在，許多商家的店鋪與倉儲是分開的，當(dāng)倉庫收到A寄來的手機(jī)并確認(rèn)收貨后，店鋪工作人員收到系統(tǒng)通知兩個退貨流程都已收貨（其實(shí)是同一個單號），若不進(jìn)行額外確認(rèn)，就會把錢都退回去了。

再來看不允許重復(fù)填寫同一個物流單號的情況：很簡單，AB兩個消費(fèi)者是好人，但希望節(jié)省快遞費(fèi)，就商量好把兩個手機(jī)放在一個包裹里寄回。此時若規(guī)則只允許一個單號只能填寫一次，這種做法就無法實(shí)現(xiàn)。

錯誤的設(shè)計(jì)方法是這樣的：用戶填寫退貨單號時，新增一個流程詢問用戶該單號是否只關(guān)聯(lián)了一個訂單，訂單號是多少；或者在原有基礎(chǔ)上新增一個聯(lián)合退貨的功能，讓多個用戶合伙拼單退貨。

正確的設(shè)計(jì)方法是這樣的：消費(fèi)者端流程全部不變，允許重復(fù)填寫物流單號，但必須在后臺記錄一條單號被使用的次數(shù)。對于被多次填寫的單號，在商家端告知商家須額外注意，一定與倉庫確認(rèn)好包裹內(nèi)物品再進(jìn)行退款操作。

錯誤方法的錯誤原因很簡單，我們不能為了一些極端情況就去修改主流程，也不能為了少數(shù)人的需求就影響所有正常用戶。

案例二：互相沖突的 Toast 提醒

天貓客戶端的商品詳情頁中，當(dāng)點(diǎn)擊“收藏”按鈕會有一個 Toast 告訴用戶“收藏成功”，同樣當(dāng)點(diǎn)擊“加入購物車”后，也會有 Toast 告訴用戶“加入成功”。這樣看好像沒什么問題，但若用戶點(diǎn)完“收藏”后馬上點(diǎn)擊“加入購物車”，就會出現(xiàn)兩個 Toast 相互沖突的情況——視覺上互相重疊，或后一個 Toast 無法出現(xiàn)。再極端一點(diǎn)，如果出現(xiàn)了一個腦殘用戶，為了測試反復(fù)快速點(diǎn)擊兩個按鈕，甚至?xí)?dǎo)致代碼錯誤。

為了追求設(shè)計(jì)和代碼邏輯的嚴(yán)密，我和開發(fā)同學(xué)花費(fèi)了不少時間討論對于這種極端情況，要如何設(shè)置 Toast 的出現(xiàn)和沖突機(jī)制。甚至為了應(yīng)對極端情況，還需要調(diào)整 Toast 出現(xiàn)消失的動畫過程與邏輯。但最后，我只設(shè)置了2個 Toast 在極短時間內(nèi)前后觸發(fā)的交互，也就是新的 Toast 慢慢把舊的推上去，并各自做淡入淡出動畫——畢竟兩次短促的操作是比較可能會發(fā)生的。

什么？你問我那個腦殘用戶怎么辦？不好意思，為了滿足所有正常用戶的訴求，腦殘用戶的體驗(yàn)就只好先放一放了……

案例三：神出鬼沒的 Loading

我們在客戶端上做了一個比較酷的動畫，對一個模塊長按后可以彈出一張卡片，并在卡片中閱讀一些詳情（有點(diǎn)像 3D Touch）。問題在于，彈出卡片中的信息是觸發(fā)卡片后才向服務(wù)器請求數(shù)據(jù)并加載的，正常情況下沒有問題，但是弱網(wǎng)條件下，數(shù)據(jù)加載可能會花費(fèi)不少時間。為此，第一版我們?yōu)檫@個數(shù)據(jù)請求設(shè)計(jì)了一個 Loading 的小動畫（好吧，你就當(dāng)是轉(zhuǎn)菊花）。

這樣做的結(jié)果是，對于網(wǎng)絡(luò)非常流暢的用戶，他們喚起這張卡片時，會看到一個菊花飛快地閃過，然后才看到數(shù)據(jù)加載——再流暢的網(wǎng)絡(luò)下，數(shù)據(jù)也需要加載時間，哪怕是1ms，都會讓菊花快速閃爍。

當(dāng)然，不要 Loading 也明顯不合理。弱網(wǎng)條件下，必須避免用戶盯著空白的卡片發(fā)呆而不知道系統(tǒng)正在干什么。

所以，合理的做法是，為 Loading 動畫的出現(xiàn)時間設(shè)置一個延遲：在卡片彈出的200ms內(nèi)（卡片不可能突然閃爍出現(xiàn)在用戶面前，必須有一個進(jìn)場過程），如果數(shù)據(jù)加載完畢，則不顯示 Loading 動畫，直接顯示數(shù)據(jù)。如果卡片進(jìn)場完畢（200ms后）數(shù)據(jù)還沒回來，則開始顯示 Loading 動畫。

這樣，我們保證了正常用戶的正常體驗(yàn)，避免他們每一次操作都為弱網(wǎng)這一極端情況買單。同時，也保障了弱網(wǎng)用戶的體驗(yàn)。

最后，再總結(jié)一下我們的設(shè)計(jì)原則：確保多數(shù)人體驗(yàn)的前提下，才去解決少數(shù)人的問題。

藍(lán)藍(lán)設(shè)計(jì)( sillybuy.com )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)

Facebook 設(shè)計(jì)副總裁有個問答欄目，今天的問題是：對于設(shè)計(jì)師來說，什么才代表著成功？在這篇譯文里，她分享了自己的觀點(diǎn)。

每個設(shè)計(jì)師多少都有一點(diǎn)強(qiáng)迫癥，有時候會為一個像素的間距而糾結(jié)，有時候又會割舍不下自己做的元素，滿屏的信息都想突出，導(dǎo)致畫面混亂。設(shè)計(jì)師培養(yǎng)自己對畫面的全局觀是很重要的，所以我們的腦子里時刻都需要有一把“尺子”在，這把尺子，就是“點(diǎn)線面”。在使用這把“尺子”的時候，拋開那些裝飾和顏色還有材質(zhì)，將畫面抽象成點(diǎn)線面來把控你的設(shè)計(jì)，也許會有不一樣的啟發(fā)和看到畫面不和諧的原因所在。

設(shè)計(jì)師對版面的全局觀，就是“點(diǎn)線面”的處理?！包c(diǎn)線面”是所有視覺畫面的基本結(jié)構(gòu)，點(diǎn)線面可以把不同的部分或者元素組合成一個整體，進(jìn)而打造一個視覺舒適平衡的版面。

搜索幾乎是現(xiàn)在所有網(wǎng)站，APP甚至操作系統(tǒng)的標(biāo)配，不論是電商還是論壇等等。它是一個站內(nèi)給用戶直接到達(dá)目的地的通道，起到了一個引導(dǎo)用戶走向的重要作用。在不同的系統(tǒng)，不同用途的網(wǎng)站上搜索呈現(xiàn)的方式都有所不同。

用搜索的原因

使用搜索時，用戶可以自己掌握瀏覽該網(wǎng)站的路徑，從哪一頁進(jìn)入到哪一頁，自己控制如何使用這個網(wǎng)站。沒有必要根據(jù)網(wǎng)站的頁面設(shè)計(jì)來決定瀏覽頁面的先后順序。這也是為什么很多網(wǎng)站用戶一進(jìn)入就直接使用搜索功能的原因。

另一個原因是，當(dāng)用戶瀏覽網(wǎng)頁到一半不知道接下去該干什么的時候，往往會使用搜索直接去找到自己想找的內(nèi)容。

城市大屏

在技術(shù)上，所有的媒體大屏都是基于web端技術(shù)實(shí)現(xiàn)的，這樣的選擇是因?yàn)閿?shù)據(jù)大屏幕只是數(shù)據(jù)可視化在我們?nèi)粘９ぷ髦械囊粋€運(yùn)用場景，我們需要能讓數(shù)據(jù)可視化的技術(shù)能在日常工作中得到最廣泛的落地運(yùn)用，web端當(dāng)然就是我們的主戰(zhàn)場。當(dāng)然。拋開這一點(diǎn)，我們認(rèn)為web端的相關(guān)技術(shù)也是大家落地相關(guān)數(shù)據(jù)可視化開發(fā)的良好平臺，為什么這么說呢？這基于以下幾點(diǎn)：功能全，前端技術(shù)svg，canvas，webgl三者的相互補(bǔ)充，已經(jīng)讓我們在交互，2D&3D以及大規(guī)模數(shù)據(jù)量繪制有了充足的發(fā)揮空間，其次我們團(tuán)隊(duì)在以前開發(fā)數(shù)據(jù)產(chǎn)品的過程中已經(jīng)用Nodejs建立了良好的中間件來連接各種數(shù)據(jù)源，這讓目前接入各種數(shù)據(jù)庫變得非常便捷。最后就是便于分享，在任何硬件設(shè)備上只要打開瀏覽器就能看到最終的數(shù)據(jù)可視化作品，在當(dāng)今這個注重信息分享的時代，這一點(diǎn)非常關(guān)鍵。

一個完整的后臺，由菜單/導(dǎo)航、數(shù)據(jù)/圖形展示、表格、表單、控件/組件以及彈窗等構(gòu)成，下面跟大家分享后臺中的表格和表單的設(shè)計(jì)細(xì)節(jié)。

當(dāng)接到一個全新的網(wǎng)頁后臺項(xiàng)目時，首先確定設(shè)計(jì)風(fēng)格，然后考慮這個后臺尺寸是做居中固定式，還是全屏響應(yīng)式。全屏響應(yīng)式的網(wǎng)頁設(shè)計(jì)，除非有規(guī)定，否則你可以選擇任意主流尺寸作為基尺寸來設(shè)計(jì)網(wǎng)頁。當(dāng)然，不管選擇什么尺寸，都得基于做好一個后臺而開展工作。

在今天的文章中，你會看到許多關(guān)于表單設(shè)計(jì)的切實(shí)可行的建議，它們涉及到可用性測試、現(xiàn)場測試、眼動追蹤以及用戶反饋等多個不同的環(huán)節(jié)。

1、梳理邏輯，保留必需

表單是同用戶進(jìn)行溝通的語言。和任何對話一樣，它應(yīng)當(dāng)以符合邏輯的方式幫助雙方完成交流。所以，你需要這么做：

• 讓問題保持直觀的順序。你應(yīng)當(dāng)站在用戶的角度按照邏輯提問題，而非按照程序或者數(shù)據(jù)庫的邏輯。如果問題之間沒有邏輯存在，那么可以按照字母順序來排布。
• 以直覺的順序組織選項(xiàng)。比如選項(xiàng)為日期的時候，按照周一周二周三這樣的順序來排布，而非亂序。
• 時刻反思從用戶那里獲得的信息是否必要，如何使用。這樣做是為了消除不必要的選項(xiàng)，提升完成率。

轉(zhuǎn)場動效在UI界面中所起到的作用無疑是顯著的。相比于靜態(tài)的界面，動態(tài)的轉(zhuǎn)場動效更符合人類的自然認(rèn)知體系，有效地降低了用戶的認(rèn)知負(fù)載，屏幕上元素的變化過程，前后界面的變化邏輯，以及層次結(jié)構(gòu)之間的變化關(guān)系，都在動效的加持之下，變得更加清晰自然。從這個角度上來說，動效不僅是界面的重要支持元素，也是用戶交互的基礎(chǔ)。

動效設(shè)計(jì)，尤其是協(xié)助交互的轉(zhuǎn)場動效，如今日趨成熟。通過大量的案例分析和過來人的經(jīng)驗(yàn)，我們逐步總結(jié)出優(yōu)秀轉(zhuǎn)場動效的5個核心的規(guī)則，今天的文章，我們就來分享這5個知識點(diǎn)。