在產品設計中，產品介面、使用情景、使用者操作等都會影響使用者對產品的體驗。因此我們在設計的過程中應遵循一定的原則，避免設計者片面的根據自己主觀認識對產品做出抉擇。
原則1：使用者介面應該是基於使用者的心裡模型，而不是基於工程實現模型
就是把後臺本來很複雜的事情通過設計符合使用者日常生活中常用的瀏覽方式或操作方式。其實這一點是設計師把生活中的細節和資料結合的凝聚點，使用者的心理模型抓的越準，介面就會越優秀。
#左邊介面#：大眾點評新版的價格的搜尋就比之前改得更符合使用者心裡模型；
#右邊介面#：食神搖搖的搖動手機找餐廳更加符合大眾使用者的心裡，大家應該都有那種中午不知道去哪家餐廳就餐，那麼就搖一搖來隨機抽出一個附近的餐廳。
原則2：培養使用者使用情景的思維方式做設計
要做到這個原則其實是很難的，需要長期的實戰經驗才能做到這點。
那我們都知道米聊出的比微信早，但後來被微信反超，個人認為不光是QQ幫了微信很大忙，比如使用者登入門檻低，使用者來源，廣告打得響之類的，其實在使用者使用情景方面米聊研究的沒有微信透徹。
對於一個社交即時通訊產品，新增好友的功能是好友匯聚的來源，雖然米聊微信都繫結手機通訊錄，但話又說回來，使用者找手機通訊錄聯絡人語音聊天的還是比較少。新增好友是引導使用者去發現好友，找好友, 碰好友的一扇門。所以對於這麼重要的功能放置在應用程式的哪個位置，在產品前期就會讓使用者明顯的去選擇用哪個應用，因為聊天工具的前提是要有人和你聊天。再回到現實的介面中來，看看下面的對比：
微信1.0的時候（我這裡只截了4.0的圖）把新增好友放置主Tab上，方便使用者很快的新增好友。米聊2.0時還是把新增好友放置在好友列表的第一排，使用者很難發現。
原則3：儘量少的讓使用者輸入，輸入時儘量多給出參考
移動端的虛擬鍵盤一直是科技界無法解決的一個難題，虛擬鍵盤的主要缺點：1.輸入定位無法反饋，所以無法形成高效的盲打；2.虛擬鍵盤的空間限制，手指的點選經常造成誤按。光是上面這兩點就讓虛擬鍵盤在輸入上大打折扣，所以我們在設計應用程式時，只要遇到Input Box的控制元件時，首先就要想到儘量讓使用者少輸入，或者智慧的給出參考。
百度音樂的搜尋先是把近期最熱門的歌曲依次排列在列表中，當有字輸入時，會出現歌手的候選詞，這裡值得稱讚的是百度音樂的搜尋能根據使用者輸入的字來判斷使用者是搜尋歌手還是歌名。
百度地圖也是我用得比較順手的一個地圖導航應用，在減少輸入方面也做的比較出色，百度地圖擁有cookies功能, 另外就是百度搜尋的技術應用在地名的匹配中也很讓人欣喜，在使用者輸入到一半的時候，下面的候選列表就出現了目標地址，使用者直接停止輸入點選列表即可。
原則4：全域性導航需要一直存在，最好還能預覽其他模組的動態
全域性導航在Web互動設計中比較容易做到，在手機移動端全域性導航要看產品設計的需求，什麼功能需要全域性導航，社交應用通常是：訊息，通知，請求；音樂視訊應用通常是：下載，搜尋；工具類產品經常是核心工具條（tool bar) 比如瀏覽器，語音助理，音樂識別應用等等。
全域性導航的價值在於可以讓使用者在使用過程中不會丟失資訊，減少主頁面和次級頁面之間的跳轉次數，當然全域性導航中的info-task要能在當前頁面完成，如果需要跳轉到新介面，就會失去全域性導航的意義，因為當出現多個info-task的時候，就需要使用者不停的進入全域性導航頁面來完成。
Facebook 的朋友請求，訊息，通知都是採用全域性導航的方式，就是皮膚設計的醜了些~
米聊的通知中心，裡面包含的通知型別蠻多的，顯得有點凌亂，希望下面的版本會篩選歸類 。
原則5：提供非模態的反饋，不打斷任務流
模態彈出框的書面名稱在iphone OS中稱作：Alert-box，在Android OS中稱：Pop-up box, 我們都知道彈框會打斷任務流，所以在有限的螢幕上怎樣讓這些彈框弱化，或者說優雅、紳士的提醒使用者，這個需要設計師來定義。
模態是指介面中只有提醒彈框才具有可互動行為，其他一切都不可操作；非模態不會把提醒做成彈框，可能會處理成List Notification, Toast list等方式來提醒使用者。
Gmail是第一個把刪除的模態彈框設計成List Notification這種方式的，提醒使用者撤銷剛才的刪除操作，這種非模態的處理，讓刪除的流程更加順暢和輕鬆自如。
K歌達人第二版的彈框就是模態處理，介面很不友好，使用者在K歌過程中要被打斷三次才能發表一首自己唱的歌曲，所以降低了使用者的參與度。
原則6：不要讓使用者等待任務完成，使用者還要發現更多有意思的地方
移動互聯的核心就是給使用者帶來移動體驗的方便和高效，這是 移動網際網路Apps需要考慮的，使用者在使用你產品在很多情況下都是碎片時間， 所以在設計上儘量讓使用者在短時間內熟悉我們的產品，知道這個產品的誠意，特別是某些等待介面需要設計，不能把一個很枯燥的等待介面呈現在使用者的面前，那使用者很快就會換其他apps。
在Instagram 拍完照片後，點選上傳後，它的處理方式是回到首頁的位置，告訴你的照片正在提交，並不是顯示一個上傳進度的介面，讓使用者看那上傳百分比。因此，我們在設計米吧上傳歌曲檔案時也只是告知使用者後臺正在幫你上傳，叫使用者放心，使用者自然就會去玩其他的功能，沒有讓使用者焦慮的等待，等上傳完畢時，我們再用Toast list通知使用者已經上傳成功，這樣把檢視上傳結果的主動權交給使用者。
原則7：自動儲存使用者的輸入成果
在移動端，由於輸入皮膚的複雜性，而且觸控輸入沒有物理按鍵的反饋自然，特別是手機上去輸入一段文字或者資訊，對使用者而言本身就是一件很痛苦的事情；對產品而言，使用者的在你的產品中輸入是一個很值得慶幸的事情，所以設計人員需要讓你的apps自動儲存使用者的輸入成果。
微博官方的手機客戶端在使用者輸入資訊後，點選左上角的叉時會彈出Action sheet來詢問，確認是否要放棄，或者儲存為草稿；path的處理則更為人性化，在處於斷網的情景下，使用者依然可以釋出照片和文字，當然後面聯網成功後，系統會自動上傳，只是發表時間是連網後釋出的時間點；Instagram的評論也很友好，在斷網或者網路情況不穩定的情景，使用者輸入的評論依然可以釋出，後面會有一個歎號提醒使用者稍後釋出或者重試，提升了使用者參與的積極行，同時活躍了社群。
原則8：為了程式響應的速度，設計有時候需要擔任掩護的作用
科技並不是萬能的， 技術依然是移動網際網路應用程式最需要優化和完善的，作為技術的盟友我們設計人員也需要輔佐他們，讓使用者覺得程式原本就應該是這麼執行的。特別是程式響應的速度很多時候不光是技術的問題，與網路環境也有很大的關係，這時候設計人員需要考慮這些客觀存在的情況，幫助程式來掩護這些瑕疵，讓使用者感覺到在使用時是流暢的。
#隨後實現# Instagram帖子“贊” 不管對參與者還是帖子作者都是激發其積極性活躍社群氛圍的重要功能，所以在程式的響應方面一定要具有可用，易用的特性，我們看左圖中，“贊”的按鈕已經現實“已贊”，同時我們看紅色框內的“菊花瓣”就知道後臺在loading讚的資料，所以這就是設計的巧妙之處，先讓使用者感知到程式是非常快速的，而不是等loading完之後再顯示“已贊”；
#提前傳輸# Instagram中釋出帖子的時候，使用者處理完照片點選“上傳”按鈕就看到中間的介面，這時候介面是讓使用者去為自己的帖子輸入一個主題，或者去設定分享等功能，同時我們可以看到紅色框中的“菊花瓣”，很明顯後臺已經開始傳輸剛才上傳的照片了，所以當使用者在點選“完成”時，資料只需要上傳剩下的一部分，讓使用者感知上傳很迅速；
#邊唱邊完成# 把伴奏和使用者的歌聲合成為一首音樂時需要後臺處理大量的資料，如果分步做就要讓使用者等待比較長的合成時間，為了讓使用者不用枯燥的等待合成，我們需要後臺在使用者唱歌的同時，後臺就已經開始把唱過的伴奏和歌聲合成。
以上八項原則是我在工作中體會比較深刻的互動設計原則，希望能對觀看到這篇博文的朋友有所幫助。當然設計原則是隨著時間的變化而不斷變化的，所以也請各位朋友完善和補充，謝謝！