高級交互設計師：產品設計的八個原則

原則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中發佈帖子的時候，用戶處理完照片點擊「上傳」按鈕就看到中間的界面，這時候界面是讓用戶去爲本身的帖子輸入一個主題，或者去設置分享等功能，同時咱們能夠看到紅色框中的「菊花瓣」，很明顯後臺已經開始傳輸剛纔上傳的照片了，因此當用戶在點擊「完成」時，數據只須要上傳剩下的一部分，讓用戶感知上傳很迅速;

#邊唱邊完成#把伴奏和用戶的歌聲合成爲一首音樂時須要後臺處理大量的數據，若是分步作就要讓用戶等待比較長的合成時間，爲了讓用戶不用枯燥的等待合成，咱們須要後臺在用戶唱歌的同時，後臺就已經開始把唱過的伴奏和歌聲合成。