對于設計師而言，移動端設備屏幕上的每一寸空間都是寶貴的資源。為了在小屏幕上做更多的事情，設計師在設計導航系統的時候，通常需要花費更多的時間來打磨。漢堡圖標在過去幾年當中，是最常見的一種設計策略，導航和選項被隱藏在這個小小的圖標之后，但是實際上，雖然大眾已經習慣了它的存在，但是它并不是最佳的導航設計方案。

在今天的文章當中，我們會探討為什么漢堡菜單這樣的隱藏式導航影響用戶體驗，以及可用性更強的替代方案。

為何漢堡圖標會破壞用戶體驗

在移動端設備上，我們看到的可見式導航其實比漢堡圖標這樣的隱藏式導航更多，前者大概是后者的2.5倍。

相信很多體驗設計師在與產品需求方進行設計提案的時候會遇到這樣的情景：

• 你闡述自己的設計推導過程，從產品目標分析、問題定位、設計目標分析、設計思路闡述這樣的推導下來，在場的產品經理們都點頭，表達認可。
• 但是！當到了設計方案環節，你把方案放出來，各位就七嘴八舌挑戰了：￥#@%&*&*
• 這時候經常會聽到這樣一句話：“有沒有其他更好的方案啊？”
• 這時候你是不是會想，我前面的推導和演繹過程那么完美那么富含邏輯，推導的肯定是最好的方案啦！

但是哦，這個時候，你還是會感覺沒底氣說出這句話來。

于是你最后說出一句妥協的話“好的好的，我回去改一下。”（各位老板我都聽你們的，你們說啥就是啥）

專業度呢？設計價值呢？你的玻璃心要碎了：死了產品經理們會不會覺得自己很水很不專業。

怎么辦？這就是今天想聊聊的主題：“思維框架”理論，讓我們更好地決策和解決問題。

語音交互是一個全新的體驗設計領域，目前各家機構、公司、設計組織還處于摸索設計范式的階段，Google提供了一份非常成熟、系統的交互規范文檔，其中包含了核心概念的詮釋以及諸多可以指導設計的實踐原則。最近正在做的項目中涉及到語音交互的部分，所以順手將這份文檔翻譯出來，給需要的設計師參考。

我的譯文盡量的貼合文檔中原有的表意，同時基于我個人對語音交互的理解對表達文字進行潤色。其中有個別概念名詞比較抽象，所以我也旁邊附上了英文單詞，以便大家理解。

我們正在進入一個有光明前景的全新計算領域，機器學習和人工智能激發著對話式界面和自然語言的進步，同時使對話式交互成為一種新的交互模式。

交互思維是什么？網上的搜索結果大多是一些交互設計的方法。但是我這里要講的，是真正做交互設計所具備的思維方式。交互設計在國內發展的并不成熟，還有很長一段路要走。很多人，甚至包括交互設計師自身，對這一工作的性質和價值都未必有足夠的了解。

交互設計，聽上去是“設計”，但是其本質和常見的UI和視覺設計相去甚遠。“交互”指的是人類與機器之間的溝通，與美學、界面、按鈕什么的，其實沒有半毛錢關系。領域細分之前，也許我們考慮的東西越多越好，但是在細分之后的今天甚至未來，交互設計就要有它不一樣的價值。

由于目前的大環境對這一細分領域仍舊缺乏了解，所以我希望在這篇文章里，寫幾個做交互設計所需要的思維方式。

1. 先理解什么是業務需求、目標、目的

1.1 什么是業務需求

業務需求是企業為了達到某些目標和某種目的而制定的。它代表著企業希望下一輪產品的迭代能帶來什么收益，所以企業和 PM 在制定需求時必須謹慎且方向清晰。在工作中，交互要分析拿到的業務需求是否合理，所以就要理解在業務需求中的一些基本元素：

• 需求定位：產品或用戶，還有企業戰略
• 需求類型：功能類、數據類、設計類等
• 重要性：重要、暫不重要

拿到需求首先就要分析，定位是否清晰，屬于技術類、數據類、設計類等中的哪一類，篩選所有需求中哪個更重要，然后再去做相應的工作。

1.2 什么是業務目標

導語

隨著各類App的業務功能不斷豐富，小紅點已經成為互聯網從業者們最常使用的運營工具之一，每當有新的運營內容或新功能上線，大家的做法往往是“在那放個紅點就行了”。然而簡單粗暴的形式以及不加節制的投放，讓小紅點變成了人人厭煩的“小妖精”。本文從設計的角度出發淺談小紅點的一些設計細節，期望引起大家對小紅點的關注，在這里拋磚引玉，也期待感興趣的小伙伴一起探討。

煩人的小紅點

人類似乎天生對不對稱，不和諧的事物有厭煩心理，并且想要去糾正這些“錯誤”，簡而言之就是大家平時所說的“強迫癥”。而小紅點則完美利用了這一人性的弱點，它就像白嫩臉頰上長出的一顆小痘痘，讓人忍住不去要去擠破它。因此，小紅點也成為了一把產品運營利器，只要投放在某個業務入口，就幾乎沒有用戶會對它熟視無睹，而當用戶忍不住要去輕觸消除它時，產品側為業務導流的目的也就達到了。

那么問題來了，用戶喜歡小紅點嗎？在Google和必應上搜索關鍵詞“App 小紅點”，幾乎有一半的搜索結果是“教你如何消除小紅點”。

在過去的幾年當中，網絡上所流傳的各種設計和開發資源，在素質上有明顯的提升。其中有一些已經幾乎成為了設計師和開發者必備的工具，但是其中絕大多數由于其應用范疇的局限，或者傳播不夠廣，導致它們大多并廣為人知。將這些素材集中到一起，很大程度上是希望它們的目標用戶能夠明白，需要這些工具的時候，上哪兒找。

這次的前端干貨合集內容也很齊全，仔細看看，總能找到幾款你所需要的。

MuzzleApp

表單設計中，各種設計模式和技巧已經越來越成熟了。在諸多設計技巧當中，懸浮標簽這一設計手法，應該是對于用戶體驗提升最明顯的一種。早在2013年8月的時候，我第一次考慮在自己設計的表單中運用懸浮標簽，這個想法很簡單，在占位符文本中，借助動畫加入一個圖標顯示，確保用戶不會在填寫過程中迷失。

不知道大家有沒有這樣的情況發生，自己設計的作品，“乍一看不怎么樣，仔細一看，還不如乍一看”！

其實不耐看，或者不敢放大看的原因都是細節做的不到位。

最近在做手機OS的主題圖標，對細節的感觸很大，今天結合主題圖標來和大家聊聊，我們可以從哪些方面注意自己的設計細節，大綱如下：

• 給造型加點細節
• 多加點質感的細節
• 不要讓圖標看著灰灰的
• 風格特點的運用

1. 給造型加點細節

造型是所有設計執行的第一步，造型做不好，說別的都沒用。

那如何能給造型加點細節呢？

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

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

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

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

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

確保多數人體驗的前提下，才去解決少數人的問題。

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

案例一：重復利用的物流單號

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

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

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

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

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

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

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

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

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

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

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

案例三：神出鬼沒的 Loading

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

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

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

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

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

最后，再總結一下我們的設計原則：確保多數人體驗的前提下，才去解決少數人的問題。

藍藍設計( www.dzxscac.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務