網(wǎng)頁產(chǎn)品設計的八個原則

本文格式為Word版，下載可任意編輯——網(wǎng)頁產(chǎn)品設計的八個原則網(wǎng)頁產(chǎn)品設計的八個原那么

在產(chǎn)品設計中，產(chǎn)品界面、使用情景、用戶操作等都會影響用戶對產(chǎn)品的體驗。因此我們在設計的過程中應遵循確定的原那么，制止設計者片面的根據(jù)自己主觀熟悉對產(chǎn)品做出決定。今天我為大家整理的產(chǎn)品設計的八個原那么，僅供學習參考，接待大家閱讀欣賞!

原那么1：用戶界面理應是基于用戶的心里模型，而不是基于工程實現(xiàn)模型

就是把后臺本來很繁雜的事情通過設計符合用戶日常生活中常用的欣賞方式或操作方式。其實這一點是設計師把生活中的細節(jié)和數(shù)據(jù)結合的凝結點，用戶的心理模型抓的越準，界面就會越優(yōu)秀。

#左邊界面#：群眾點評新版的價格的探尋就比之前改得更符合用戶心里模型;

#右邊界面#：食神搖搖的搖動手機找餐廳更加符合群眾用戶的心里，大家理應都有那種中午不知道去哪家餐廳就餐，那么就搖一搖來隨機抽出一個鄰近的餐廳。

原那么2：培養(yǎng)用戶使用情景的思維方式做設計

要做到這個原那么其實是很難的，需要長期的實戰(zhàn)閱歷才能做到這點。

那我們都知道米聊出的比微信早，但后來被微信反超，個人認為不光是幫了微信很大忙，譬如用戶登錄門檻低，用戶來源，廣告打得響之類的，其實在用戶使用情景方面米聊研究的沒有微信透徹。

對于一個社交即時通訊產(chǎn)品，添加好友的功能是好友集聚的來源，雖然米聊微信都綁定手機通訊錄，但話又說回來，用戶找手機通訊錄聯(lián)系人語音閑聊的還是對比少。添加好友是引導用戶去察覺好友，找好友,碰好友的一扇門。所以對于這么重要的功能放置在應用程序的哪個位置，在產(chǎn)品前期就會讓用戶明顯的去選擇用哪個應用，由于閑聊工具的前提是要有人和你閑聊。再回到現(xiàn)實的界面中來，看看下面的比較：

微信1.0的時候我這里只截了4.0的圖把添加好友放置主Tab上，便當用戶很快的添加好友。

米聊2.0時還是把添加好友放置在好友列表的第一排，用戶很難察覺

原那么3：盡量少的讓用戶輸入，輸入時盡量多給出參考

移動端的虛擬鍵盤一向是科技界無法解決的一個難題，虛擬鍵盤的主要缺點：1.輸入定位無法反應，所以無法形成高效的盲打;2.虛擬鍵盤的空間限制，手指的點擊經(jīng)常造成誤按。光是上面這兩點就讓虛擬鍵盤在輸入上大打折扣，所以我們在設計應用程序時，只要遇到InputBox的控件時，首先就要想到盡量讓用戶少輸入，或者智能的給出參考。

百度音樂的探尋先是把近期最熱門的歌曲依次排列在列表中，當有字輸入時，會展現(xiàn)歌手的候選詞，這里值得稱贊的是百度音樂的探尋能根據(jù)用戶輸入的字來判斷用戶是探尋歌手還是歌名。

百度地圖也是我用得對比順手的一個地圖導航應用，在裁減輸入方面也做的對比卓越，百度地圖擁有cookies功能,另外就是百度探尋的技術應用在地名的匹配中也很讓人欣喜，在用戶輸入到一半的時候，下面的候選列表就展現(xiàn)了目標地址，用戶直接中斷輸入點擊列表即可。

原那么4：全局導航需要一向存在，最好還能預覽其他模塊的動態(tài)

全局導航在Web交互設計中對比輕易做到，在手機移動端全局導航要看產(chǎn)品設計的需求，什么功能需要全局導航，社交應用通常是：消息，通知，苦求;音樂視頻應用通常是：下載，探尋;工具類產(chǎn)品經(jīng)常是核心工具條toolbar譬如欣賞器，語音助理，音樂識別應用等等。

全局導航的價值在于可以讓用戶在使用過程中不會損失信息，裁減主頁面和次級頁面之間的跳轉(zhuǎn)次數(shù)，當然全局導航中的info-task要能在當前頁面完成，假設需要跳轉(zhuǎn)到新界面，就會失去全局導航的意義，由于當展現(xiàn)多個info-task的時候，就需要用戶不停的進入全局導航頁面來完成。

Facebook的摯友苦求，消息，通知都是采用全局導航的方式，就是面板設計的丑了些~

米聊的通知中心，里面包含的通知類型蠻多的，顯得有點凌亂，夢想下面的版本會篩選歸類

原那么5：供給非模態(tài)的反應，不打斷任務流

模態(tài)彈出框的書面名稱在iphoneOS中稱作：Alert-box，在AndroidOS中稱：Pop-upbox,我們都知道彈框會打斷任務流，所以在有限的屏幕上怎樣讓這些彈框弱化，或者說優(yōu)雅、紳士的指點用戶，這個需要設計師來定義。

模態(tài)是指界面中只有指點彈框才具有可交互行為，其他一切都不成操作;非模態(tài)不會把指點做成彈框，可能會處理成ListNotification,Toastlist等方式來指點用戶。

Gmail是第一個把刪除的模態(tài)彈框設計成ListNotification這種方式的，指點用戶撤銷方才的刪除操作，這種非模態(tài)的處理，讓刪除的流程更加順暢和輕松自如。

K歌達人其次版的彈框就是模態(tài)處理，界面很不友好，用戶在K歌過程中要被打斷三次才能發(fā)表一首自己唱的歌曲，所以降低了用戶的參與度。

原那么6：不要讓用戶等待任務完成，用戶還要察覺更多有意思的地方

移動互聯(lián)的核心就是給用戶帶來移動體驗的便當和高效，這是移動互聯(lián)網(wǎng)Apps需要考慮的，用戶在使用你產(chǎn)品在好多處境下都是碎片時間，所以在設計上盡量讓用戶在短時間內(nèi)熟諳我們的產(chǎn)品，知道這個產(chǎn)品的誠意，更加是某些等待界面需要設計，不能把一個很枯燥的等待界面呈現(xiàn)在用戶的面前，那用戶很快就會換其他apps。

在Instagram拍完照片后，點擊上傳后，它的處理方式是回到首頁的位置，報告你的照片正在提交，并不是顯示一個上傳進度的界面，讓用戶看那上傳百分比。因此，我們在設計米吧上傳歌曲文件時也只是告知用戶后臺正在幫你上傳，叫用戶放心，用戶自然就會去玩其他的功能，沒有讓用戶焦慮的等待，等上傳完畢時，我們再用Toastlist通知用戶已經(jīng)上傳告成，這樣把查看上傳結果的主動權交給用戶。

原那么7：自動保存用戶的輸入成果

在移動端，由于輸入面板的繁雜性，而且觸摸輸入沒有物理按鍵的反應自然，更加是手機上去輸入一段文字或者信息，對用戶而言本身就是一件很痛楚的'事情;對產(chǎn)品而言，用戶的在你的產(chǎn)品中輸入是一個很值得慶幸的事情，所以設計人員需要讓你的apps自動保存用戶的輸入成果。

微博官方的手機客戶端在用戶輸入信息后，點擊左上角的叉時會彈出Actionsheet來詢問，確認是否要放棄，或者保存為草稿;path的處理那么更為人性化，在處于斷網(wǎng)的情景下，用戶照舊可以發(fā)布照片和文字，當然后面聯(lián)網(wǎng)告成后，系統(tǒng)會自動上傳，只是發(fā)表時間是連網(wǎng)后發(fā)布的時間點;Instagram的評論也很友好，在斷網(wǎng)或者網(wǎng)絡處境不穩(wěn)定的情景，用戶輸入的評論照舊可以發(fā)布，后面會有一個嘆號指點用戶稍后發(fā)布或者重試，提升了用戶參與的積極行，同時活躍了社區(qū)。

原那么8：為了程序響應的速度，設計有時候需要承擔掩護的作用

科技并不是萬能的，技術照舊是移動互聯(lián)網(wǎng)應用程序最需要優(yōu)化和完善的，作為技術的盟友我們設計人員也需要輔佐他們，讓用戶覺得程序原本就理應是這么運行的。更加是程序響應的速度好多時候不光是技術的問題，與網(wǎng)絡環(huán)境也有很大的關系，這時候設計人員需要考慮這些客觀存在的處境，扶助程序來掩護這些瑕疵，讓用戶感覺到在使用時是流暢的。

#隨后實現(xiàn)#Instagram帖子"贊'不管對參與者還是帖子都是激發(fā)其積極性活躍社區(qū)空氣的重要功能，所以在程序的響應方面確定要具有可用，易用的特性，我們看左圖中，"贊'的按鈕已經(jīng)現(xiàn)實"已贊'，同時我們看紅色框內(nèi)的"菊花瓣'就知道后臺在loading贊的數(shù)據(jù)，所以這就是設計的高明之處，先讓用戶感知到程序是分外快速的，而不是等loading完之后再顯示"已贊';

#提前傳輸#Instagram中發(fā)布帖子的時候，用戶處理完照片點擊"上傳'按鈕就看到中間的界面，這時候界面是讓用戶去為自己的帖子輸入一個主題，或者去設置共享等功能，同時我們可以看到紅色框中的"菊花瓣'