原則1：用戶界面應該是基于用戶的心裏模型，而不是基于工(gōng)程實現模型
就是把後台本來很複雜(zá)的事情通過設計符合用戶日常生(shēng)活中(zhōng)常用的浏覽方式或操作方式。其實這一(yī)點是設計師把生(shēng)活中(zhōng)的細節和數據結合的凝聚點，用戶的心理模型抓的越準，界面就會越優秀。
#左邊界面#：大(dà)衆點評新版的價格的搜索就比之前改得更符合用戶心裏模型；#右邊界面#：食神搖搖的搖動手機找餐廳更加符合大(dà)衆用戶的心裏，大(dà)家應該都有那種中(zhōng)午不知(zhī)道去(qù)哪家餐廳就餐，那麽就搖一(yī)搖來随機抽出一(yī)個附近的餐廳。#左邊界面#：大(dà)衆點評新版的價格的搜索就比之前改得更符合用戶心裏模型；#右邊界面#：食神搖搖的搖動手機找餐廳更加符合大(dà)衆用戶的心裏，大(dà)家應該都有那種中(zhōng)午不知(zhī)道去(qù)哪家餐廳就餐，那麽就搖一(yī)搖來随機抽出一(yī)個附近的餐廳。

原則2：培養用戶使用情景的思維方式做設計
要做到這個原則其實是很難的，需要長期的實戰經驗才能做到這點。
那我(wǒ)們都知(zhī)道米聊出的比微信早，但後來被微信反超，個人認爲不光是QQ幫了微信很大(dà)忙，比如用戶登錄門檻低，用戶來源，廣告打得響之類的，其實在用戶使用情景方面米聊研究的沒有微信透徹。

對于一(yī)個社交即時通訊産品，添加好友的功能是好友彙聚的來源，雖然米聊微信都綁定手機通訊錄，但話(huà)又(yòu)說回來，用戶找手機通訊錄聯系人語音聊天的還是比較少。添加好友是引導用戶去(qù)發現好友，找好友, 碰好友的一(yī)扇門。所以對于這麽重要的功能放(fàng)置在應用程序的哪個位置，在産品前期就會讓用戶明顯的去(qù)選擇用哪個應用，因爲聊天工(gōng)具的前提是要有人和你聊天。

原則3：盡量少的讓用戶輸入，輸入時盡量多給出參考
移動端的虛拟鍵盤一(yī)直是科技界無法解決的一(yī)個難題，虛拟鍵盤的主要缺點：1.輸入定位無法反饋，所以無法形成高效的盲打；2.虛拟鍵盤的空間限制，手指的點擊經常造成誤按。光是上面這兩點就讓虛拟鍵盤在輸入上大(dà)打折扣，所以我(wǒ)們在設計應用程序時，隻要遇到Input Box的控件時，首先就要想到盡量讓用戶少輸入，或者智能的給出參考。
百度音樂的搜索先是把近期最熱門的歌曲依次排列在列表中(zhōng)，當有字輸入時，會出現歌手的候選詞，這裏值得稱贊的是百度音樂的搜索能根據用戶輸入的字來判斷用戶是搜索歌手還是歌名。 百度音樂的搜索先是把近期最熱門的歌曲依次排列在列表中(zhōng)，當有字輸入時，會出現歌手的候選詞，這裏值得稱贊的是百度音樂的搜索能根據用戶輸入的字來判斷用戶是搜索歌手還是歌名。
百度地圖也是我(wǒ)用得比較順手的一(yī)個地圖導航應用，在減少輸入方面也做的比較出色，百度地圖擁有cookies功能, 另外(wài)就是百度搜索的技術應用在地名的匹配中(zhōng)也很讓人欣喜，在用戶輸入到一(yī)半的時候，下(xià)面的候選列表就出現了目标地址，用戶直接停止輸入點擊列表即可。百度地圖也是我(wǒ)用得比較順手的一(yī)個地圖導航應用，在減少輸入方面也做的比較出色，百度地圖擁有cookies功能, 另外(wài)就是百度搜索的技術應用在地名的匹配中(zhōng)也很讓人欣喜，在用戶輸入到一(yī)半的時候，下(xià)面的候選列表就出現了目标地址，用戶直接停止輸入點擊列表即可。

原則4：全局導航需要一(yī)直存在，最好還能預覽其他模塊的動态
全局導航在Web交互設計中(zhōng)比較容易做到，在手機移動端全局導航要看産品設計的需求，什麽功能需要全局導航，社交應用通常是：消息，通知(zhī)，請求；音樂視頻(pín)應用通常是：下(xià)載，搜索；工(gōng)具類産品經常是核心工(gōng)具條（tool bar) 比如浏覽器，語音助理，音樂識别應用等等。
全局導航的價值在于可以讓用戶在使用過程中(zhōng)不會丢失信息，減少主頁面和次級頁面之間的跳轉次數，當然全局導航中(zhōng)的info-task要能在當前頁面完成，如果需要跳轉到新界面，就會失去(qù)全局導航的意義，因爲當出現多個info-task的時候，就需要用戶不停的進入全局導航頁面來完成。
Facebook 的朋友請求，消息，通知(zhī)都是采用全局導航的方式，就是面闆設計的醜了些~ Facebook 的朋友請求，消息，通知(zhī)都是采用全局導航的方式，就是面闆設計的醜了些~
米聊的通知(zhī)中(zhōng)心，裏面包含的通知(zhī)類型蠻多的，顯得有點淩亂，希望下(xià)面的版本會篩選歸類米聊的通知(zhī)中(zhōng)心，裏面包含的通知(zhī)類型蠻多的，顯得有點淩亂，希望下(xià)面的版本會篩選歸類

原則5：提供非模态的反饋，不打斷任務流
模态彈出框的書(shū)面名稱在iphone OS中(zhōng)稱作：Alert-box，在Android OS中(zhōng)稱：Pop-up box, 我(wǒ)們都知(zhī)道彈框會打斷任務流，所以在有限的屏幕上怎樣讓這些彈框弱化，或者說優雅、紳士的提醒用戶，這個需要設計師來定義。

模态是指界面中(zhōng)隻有提醒彈框才具有可交互行爲，其他一(yī)切都不可操作；非模态不會把提醒做成彈框，可能會處理成List Notification, Toast list等方式來提醒用戶。
Gmail是第一(yī)個把删除的模态彈框設計成List Notification這種方式的，提醒用戶撤銷剛才的删除操作，這種非模态的處理，讓删除的流程更加順暢和輕松自如。Gmail是第一(yī)個把删除的模态彈框設計成List Notification這種方式的，提醒用戶撤銷剛才的删除操作，這種非模态的處理，讓删除的流程更加順暢和輕松自如。
K歌達人第二版的彈框就是模态處理，界面很不友好，用戶在K歌過程中(zhōng)要被打斷三次才能發表一(yī)首自己唱(chàng)的歌曲，所以降低了用戶的參與度。K歌達人第二版的彈框就是模态處理，界面很不友好，用戶在K歌過程中(zhōng)要被打斷三次才能發表一(yī)首自己唱(chàng)的歌曲，所以降低了用戶的參與度。

原則6：不要讓用戶等待任務完成，用戶還要發現更多有意思的地方
移動互聯的核心就是給用戶帶來移動體(tǐ)驗的方便和高效，這是 移動互聯網Apps需要考慮的，用戶在使用你産品在很多情況下(xià)都是碎片時間， 所以在設計上盡量讓用戶在短時間内熟悉我(wǒ)們的産品，知(zhī)道這個産品的誠意，特别是某些等待界面需要設計，不能把一(yī)個很枯燥的等待界面呈現在用戶的面前，那用戶很快就會換其他apps。
在Instagram 拍完照片後，點擊上傳後，它的處理方式是回到首頁的位置，告訴你的照片正在提交，并不是顯示一(yī)個上傳進度的界面，讓用戶看那上傳百分(fēn)比。因此，我(wǒ)們在設計米吧上傳歌曲文件時也隻是告知(zhī)用戶後台正在幫你上傳，叫用戶放(fàng)心，用戶自然就會去(qù)玩其他的功能，沒有讓用戶焦慮的等待，等上傳完畢時，我(wǒ)們再用Toast list通知(zhī)用戶已經上傳成功，這樣把查看上傳結果的主動權交給用戶。

原則7：自動保存用戶的輸入成果
在移動端，由于輸入面闆的複雜(zá)性，而且觸摸輸入沒有物(wù)理按鍵的反饋自然，特别是手機上去(qù)輸入一(yī)段文字或者信息，對用戶而言本身就是一(yī)件很痛苦的事情；對産品而言，用戶的在你的産品中(zhōng)輸入是一(yī)個很值得慶幸的事情，所以設計人員(yuán)需要讓你的apps自動保存用戶的輸入成果。
微博官方的手機客戶端在用戶輸入信息後，點擊左上角的叉時會彈出Action sheet來詢問，确認是否要放(fàng)棄，或者保存爲草稿；path的處理則更爲人性化，在處于斷網的情景下(xià)，用戶依然可以發布照片和文字，當然後面聯網成功後，系統會自動上傳，隻是發表時間是連網後發布的時間點；Instagram的評論也很友好，在斷網或者網絡情況不穩定的情景，用戶輸入的評論依然可以發布，後面會有一(yī)個歎号提醒用戶稍後發布或者重試，提升了用戶參與的積極行，同時活躍了社區。

原則8：爲了程序響應的速度，設計有時候需要擔任掩護的作用
科技并不是萬能的， 技術依然是移動互聯網應用程序最需要優化和完善的，作爲技術的盟友我(wǒ)們設計人員(yuán)也需要輔佐他們，讓用戶覺得程序原本就應該是這麽運行的。特别是程序響應的速度很多時候不光是技術的問題，與網絡環境也有很大(dà)的關系，這時候設計人員(yuán)需要考慮這些客觀存在的情況，幫助程序來掩護這些瑕疵，讓用戶感覺到在使用時是流暢的。

#随後實現# Instagram帖子“贊” 不管對參與者還是帖子作者都是激發其積極性活躍社區氛圍的重要功能，所以在程序的響應方面一(yī)定要具有可用，易用的特性，我(wǒ)們看左圖中(zhōng)，“贊”的按鈕已經現實“已贊”，同時我(wǒ)們看紅色框内的“菊花瓣”就知(zhī)道後台在loading贊的數據，所以這就是設計的巧妙之處，先讓用戶感知(zhī)到程序是非常快速的，而不是等loading完之後再顯示“已贊”；

#提前傳輸# Instagram中(zhōng)發布帖子的時候，用戶處理完照片點擊“上傳”按鈕就看到中(zhōng)間的界面，這時候界面是讓用戶去(qù)爲自己的帖子輸入一(yī)個主題，或者去(qù)設置分(fēn)享等功能，同時我(wǒ)們可以看到紅色框中(zhōng)的“菊花瓣”，很明顯後台已經開(kāi)始傳輸剛才上傳的照片了，所以當用戶在點擊“完成”時，數據隻需要上傳剩下(xià)的一(yī)部分(fēn)，讓用戶感知(zhī)上傳很迅速；

#邊唱(chàng)邊完成# 把伴奏和用戶的歌聲合成爲一(yī)首音樂時需要後台處理大(dà)量的數據，如果分(fēn)步做就要讓用戶等待比較長的合成時間，爲了讓用戶不用枯燥的等待合成，我(wǒ)們需要後台在用戶唱(chàng)歌的同時，後台就已經開(kāi)始把唱(chàng)過的伴奏和歌聲合成。

• 上一(yī)篇：網頁設計新趨勢知(zhī)多少 2017/8/14
• 下(xià)一(yī)篇：行業公認的7大(dà)網頁設計秘訣，讓你的網頁脫穎而出 2017/8/14

本文系本網編輯轉載，轉載目的在于傳遞更多信息，并不代表本網贊同其觀點和對其真實性負責。如涉及作品内容、版權和其它問題，請在30日内與本網聯系，我(wǒ)們将在第一(yī)時間删除内容！
[聲明]本站文章版權歸原作者所有 内容爲作者個人觀點 本站隻提供參考并不構成任何投資(zī)及應用建議。