隱藏在背后的交互設計
外行人對交互設計的第一印象是什么？畫線框圖的？做草稿的？
的確，大家所看到交互設計師的日常工作成果都是一些線框圖，從表面上理解的確是這樣。
其實，交互設計師做的遠遠不止這些。往深一步想，信息架構、界面、流程，都是設計師需要考慮的問題。下面，想談一下我理解的交互設計。
交互設計最重要的兩個因素：信息&互動
1.信息
人們每天面對那么多信息，在雜亂的信息中篩選出對用戶有價值的，呈現給用戶，幫助用戶做選擇，指引用戶完成任務。信息的篩選直接影響著用戶使用，在用戶需要的時候無法提供有用的信息，將導致任務無法進行下去。所以信息是交互設計師需要關注的第一要素。
2.互動
有了信息后，就需要設計用戶如何與這些信息進行互動了。信息的分類、布局將影響用戶與信息的交互。用戶獲取信息后，做出了反應，采取了行動，應用也需要有來有往地給予足夠的反饋，來協助用戶完成任務。
以上2要素，都是從用戶直觀感受上去體現的，也就是說往往是表現在用戶界面上。我們可以把它稱之為“看得見的交互設計”。
具體的形式包括：
信息架構：把篩選好的信息進行分類，通過頁面來承載這些信息，并且把信息（頁面）的層次規劃好
界面設計：把信息在一個頁面上進行布局
流程設計：把一個任務中涉及的頁面信息串聯起來，使任務形成一個線性流的關系
以上三個關鍵點，是對交互設計師的基本要求，很多情況下，非專業人員也能做得7788，但還有一部分的交互設計，并不是直觀能看到的，也許用戶會輕微感受到，但他總在不經意間使用戶使用得更加流暢。我們可以把它稱之為“看不見的交互設計”。而這些看不見的交互設計，也是初級交互設計師容易忽略的。
如今移動互聯網發展迅速，移動產品對這些看不見的交互設計更為注重。因為移動應用的使用場景、網絡環境、使用心態都與用戶在使用web產品時有著大大的不同。所以在了解這些看不見的交互設計時前，需要對移動應用的情景有一定的了解。
1.使用場景
用戶在使用移動產品，有可能會在戶外人多的公眾場合使用，這時候需要特別注意移動應用設計的隱私安全。
用戶有可能在家里、在床上、在廁所，用著各種姿態使用產品，所以對交互的便利性和容錯性要特別注意
2.網絡環境
網絡環境是“看不見的交互設計中”非常關鍵的一點。用戶會在2G、3G、wifi甚至無聯網的情況下使用產品，所以對于各種網絡環境進行合理的交互設計是移動產品交互設計師需要考慮的重中之重
3.使用心態
產品的存在是為了解決用戶的問題，而移動產品是用戶的貼身工具，當用戶需要時，能立刻開始運作，需要快速、直接、有效，用戶不喜歡等待。有研究結果表示：
在移動產品這種特殊的環境下，“看不見的交互設計”會相較于web產品更為重要，特別是針對網絡環境和用戶等待的體驗需要特別注意
下面將展開討論一下“看不見的交互設計”
總的來講，可以歸結為三大點：
1.加載機制
2.刷新機制
3.緩存機制
加載機制
通常情況下，我們使用的絕大部分是網絡App，他的工作原理是這樣的
用戶在客戶端的界面上進行操作，客戶端發送請求到服務器，服務器處理請求，返回數據給客戶端，并顯示給用戶
其中，客戶端和服務器的交互過程，用戶是感知不到的，而他確實會耗費時間，在不同的網絡環境下耗費的時間也會有所差異，如何讓用戶在這段時間里有友好的體驗呢？這時候“加載過程”起了作用。
加載過程的關鍵可以總結為：
1.讓用戶感知產品正在努力為他運作
2.讓用戶有基本的心理預期需要等待的時間長短
3.讓用戶在無聊的等待中獲得更多樂趣
進度條是一個針對加載過程很好的設計
動態的加載進度表示產品正在工作，總進度和當前進度能讓用戶及時了解情況，讓用戶能根據這些信息預判時間，有了心理預期
有趣的進度條設計or在加載過程中展示一些功能介紹提示（常用于游戲）能有效減少用戶等待時的焦躁心理，也能有效地提高用戶的容忍度
進度條是web產品時代的產物，還有另外一種加載設計，就是加載圖標
由于移動產品請求的數據量并不大，所以進度條往往會在一瞬間就完成了，在這種情境下，簡化了加載的設計，很多移動產品轉而使用加載圖標來表示加載過程
以上為兩種比較常用的加載方式，下面將具體介紹他們與移動產品結合的用法
頁面加載機制
移動產品的信息都是通過頁面來承載的，頁面的加載方案設計是交互設計師面臨的一個重要難題
方案一：單頁面整體加載
這種加載比較簡單，一般運用在頁面內容比較單一的情況下，所以直接一次性加載完所有數據后再顯示內容
單頁面加載失敗的狀態也比較好處理
方案二：單頁面分塊加載
這種方案的特點是，能讓用戶逐步看到內容，在這個漸進的過程中降低用戶的焦慮心理
其中又可以分為，模塊間有關聯性的，先加載父內容，再加載子內容
如優酷，先把欄目加載出來，再加載各欄目的內容
模塊間沒有絕對關聯性的，可獨自加載各自模塊內容，根據請求的速度不同分別顯示。這樣處理有一定幾率讓用戶在沒完全刷出數據的情況下就能找到自己需要的功能，如大眾點評、淘寶客戶端
框架固定，內容更新的，可先把框架顯示出來，再把各模塊的數據各自加載顯示，如各種iOS自帶應用，云音樂
這種分模塊加載的需要特別注意加載失敗的狀態，畢竟每個模塊都提示加載失敗，點擊重試是很挫的一件事，可以根據信息的優先級來決定哪些數據失敗了采用默認狀態，哪些數據采用失敗提示
方案三：跨頁面加載
父頁面&子頁面 or 同一app內，頁面間字段可以復用的，在加載子頁面時不需要重新加載新數據
方案四：預加載
這種加載方式的特點是，在加載一個頁面內容的同時，預測用戶的下一步行為，并為他下一步需要使用的頁面加載內容，使得他在下一步的操作中能立刻獲取信息而不需要加載等待。
預加載提供給用戶無縫的產品使用體驗，使得用戶在使用產品的過程中更直接流暢，沒有被打斷的感覺。
具體的例子有：
在瀏覽圖集的時候，當看到第一張的圖片時，就自動后臺加載第二第三第四張圖片，用戶瀏覽完第一張圖片切換到第二張時就不會有加載等待的過程
在瀏覽新聞列表時，就把每篇新聞的內容在后臺進行預加載，用戶選擇看某篇新聞時，能立刻閱讀到內容
但是這種方案需要面臨很多的問題，最直接的是流量問題，因為會自動跑掉很多用戶可能根本用不上的數據流量，所以一般情況下可以設定在wifi環境才采用這種加載模式。又或者設定加載規則，只把主要內容預加載，而部分次要內容可以在用戶真的用到的時候才加載，例如預加載新聞正文的情況，可以只加載文本信息，圖片信息等到用戶進入內頁才加載。這種預加載與分塊加載結合的方式也普遍運用在各個場景。
另外，預加載也需要時間的，他只是不在客戶端顯示給用戶，默默在后臺運作而已，需要特殊考慮未加載完用戶就使用到那些信息的情況，所以在做預加載設計時需要同時考慮另一種適合該情況的普通加載方式。
預加載需要根據具體的場景來進行設計，設定好信息優先級，綜合考慮各種類型信息的具體大小流量，整體考慮預加載的方式，這些都是需要經過精心分析思考的。
隨著網絡環境的發展，預加載將成為以后產品普遍的加載方式，他提供給用戶的無縫使用體驗大大地提升了產品的可用性。
操作加載機制
除了頁面的信息需要加載，頁面內的操作也是需要通過給服務器發送請求記錄的
方案一：加載層
進行一個操作后，彈出模態的提示層，告知用戶正在加載。
采用模態的提示主要是防止用戶在該過程中進行其他操作，導致當前加載出錯。由于采用模態的提示，并且有可能因為網絡原因導致長時間處于加載狀態，建議提供一個“關閉”的操作，中止本次加載，恢復App可用狀態。加載失敗時可在當前浮層變換為失敗提示。
模態提示層是最穩妥的方式，但他會使用戶在使用過程中有打斷的感覺。
方案二：控件自身加載狀態
這種方式是把操作加載的狀態與控件的樣式結合起來了，對某個控件進行操作后，控件變換為加載狀態，此時控件不能重復操作
由于這種加載方式是控件的自身狀態，不影響其他操作，所以用戶也可以對頁面進行其他操作，可能會導致同時有多個請求的情況，增加了加載失敗的風險，這也算是這種方式的弊端，不過這種極端情況很少出現。請求失敗后，可配合Toast提示告知用戶失敗的原因。
方案三：后臺加載
用戶在操作后，客戶端立刻反饋操作成功，然后把請求放到后臺與服務器交互，這一過程用戶不需要了解，不需要等待，在正常情況下體驗是非常棒的。
但是在極端情況下會出現一些莫名其妙的狀況，由于是后臺記錄請求并與服務器交互，所以實際請求是否成功客戶端是不說明的，全部以操作成功來顯示，這就會導致用戶誤以為操作成功了，但實際上下次來看發現沒有成功。所以這種加載方式是需要根據具體使用場景來權衡使用的，對于一些重要的操作，建議還是使用模態的方式加載，對于一些小操作，如點贊、訂閱、關注，可采用后臺加載的方式。
#p#
刷新機制
刷新機制也是設計師很容易忽略的問題，合理的刷新機制能讓產品使用起來更流暢
普遍情況下，刷新機制有以下三種：
方案一：手勢刷新
通過手指在屏幕上的左劃右劃上劃下劃達到刷新的目的，也包括一些瀏覽器產品的自定義手勢，如橫折折勾，進行刷新
最常見的下拉刷新也屬于手勢刷新的一種
方案二：點擊刷新
通過點擊一個按鈕達到刷新數據的目的，但是如今刷新按鈕的存在已經成為一種過時的表現，況且在手機那么小的界面上還需要為刷新按鈕騰出空間，會挺費勁的。不過避免形式主義，用得恰到好處才是設計的精髓，這種刷新方案還是按需使用吧。
方案三：自動刷新
根據設定好的規則，如時間、事件規則自動向服務器獲取新數據并替換舊數據。使用自動刷新需要根據場景來考慮是否合適
場景一——對于頻繁更新的內容、有時效性的內容，用戶在一個設定的時間沒有使用，則可考慮在下次使用時，自動刷新，把新的內容推送給用戶
類似微博、新聞這種具有時效性的產品，用戶在24小時內未打開產品，則在下次打開時幫用戶自動更新Timeline
場景二——對于一個相對穩定，數據不會經常變化的頁面，可以考慮設定時間規則，在后臺為用戶默默更新數據并替換舊數據
緩存機制
“緩存”這個詞在web時代也經常聽到，但在移動產品上，他的重要性得到了很好的重視
一張圖解釋什么是緩存和緩存的作用
“緩存”就是把已經加載過的數據保存起來，并在下次需要重復使用的時候，不需要向服務器加載，直接獲取本地數據
我理解的“緩存”可如下分類
臨時緩存常用于一個功能頁面內，保存各欄目的緩存。同一個功能里會把子功能分為多個欄目進行劃分，每個標簽欄目下的內容在本次使用中都可保存為臨時緩存，在該功能里切換欄目，不需要重新加載數據，使用緩存顯示。對于用戶來說，使用時達到了無縫切換瀏覽，對于服務器來說，在短時間內數據很少會有更新，所以在一般情況下能滿足用戶的正常需求，并達到體驗優秀
臨時緩存的清理機制是：退出該功能模塊就清除之前的緩存。也就是說下次進入該功能模塊，需要重新獲取一次數據
很多時候我們都會用到臨時緩存，因為那些信息真的不是那么重要，而且不需要經常反復查看，那對于那些我們經常使用而且經常需要反復查看的信息，我們就會采取固定緩存保存在本地，方便下次翻閱時不需要再一次向服務器請求數據了
其中又會細分為可手動清理的緩存，和不可手動清理的緩存
第一種是我們最常見的緩存，幾乎所有產品都采用這種緩存方式。平時用戶瀏覽文章、圖集加載的數據就以這種形式緩存在本地，下次看回這篇文章、圖集時就不需要加載了。用戶也可以手動把這些緩存清理了，釋放空間。
而對于某些特殊場景，例如一些相對固定的數據，我們不愿意一開始就打包進App里，這樣會占太大容量，造成產品包很大，也不愿意每次進入頁面都向服務器加載這些信息，那怎么辦？解決方法就是我們可以只加載一次就永遠存在本地了，這樣安裝包也不會大，以后也不用加載了。
例如一些頁面的背景圖，相對固定不常更換，所以在用戶首次進入該頁面時就加載背景圖并保存在本地，這種緩存是不可清理的，下次再進入該頁面就讀取本地緩存顯示即可。
這種緩存方案使用得很少，因為場景太少，具體使用場景還有待開發。
/
對于這些保存在本地的緩存，都是會占空間的，手機的容量是有限的，那產品是通過怎樣的方式清理緩存的呢？
大家熟知的有手動清理，一般App都會在“設置”里提供一個清理緩存的功能，一鍵把空間釋放。除此之外，App最好要設計自動清理機制。
可以通過兩個維度來設計這個機制。
時間
通過設定一個固定的時間，或者根據用戶使用周期靈活設定時間來清理緩存。每個產品的場景不一，用戶使用頻率不一，設定這個機制的時候就需要結合實際情況考慮了
容量
一般是設定一個容量上限，采用堆棧的設計原理進行緩存清理，溢出堆棧的舊數據將自動清除
小結
這些“看不見的交互設計”就是糾結在那些細節，但作為交互設計師千萬不要以為這些是很細小的點，其實他是有大文章可作的。
刷新、加載、緩存機制的設計，我不清楚是否應該歸納進交互設計師的職業范疇，但是作為一名用戶體驗設計師，這些點或多或少地影響著用戶的使用體驗，我們都應該給予足夠多的重視。
這些機制，獨立來看都有現有模式可參考，但是交互設計師不應該把他們割裂地設計，他們往往是合并在一起時才會有意義。不同機制的結合，往往有妙用，這就需要設計師根據每個產品的不同場景來特殊制定了。
