在産品設計中,産品界面、使用情景、使用者操作等都會影響使用者對産品的體驗。是以我們在設計的過程中應遵循一定的原則,避免設計者片面的根據自己主觀認識對産品做出抉擇。
原則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中釋出文章的時候,使用者處理完照片點選“上傳”按鈕就看到中間的界面,這時候界面是讓使用者去為自己的文章輸入一個主題,或者去設定分享等功能,同時我們可以看到紅色框中的“菊花瓣”,很明顯背景已經開始傳輸剛才上傳的照片了,是以當使用者在點選“完成”時,資料隻需要上傳剩下的一部分,讓使用者感覺上傳很迅速;
#邊唱邊完成# 把伴奏和使用者的歌聲合成為一首音樂時需要背景處理大量的資料,如果分步做就要讓使用者等待比較長的合成時間,為了讓使用者不用枯燥的等待合成,我們需要背景在使用者唱歌的同時,背景就已經開始把唱過的伴奏和歌聲合成。
以上八項原則是我在工作中體會比較深刻的互動設計原則,希望能對觀看到這篇博文的朋友有所幫助。當然設計原則是随着時間的變化而不斷變化的,是以也請各位朋友完善和補充,謝謝!
作者:向華盛,進階互動設計師,原小米科技産品經理