用戶體驗已經成為衡量 應用軟件質量的重要標準。在過去我們可能會驚嘆于某個Web應用的華麗界面，現在，隨著HTML5的強勢登場，各類表現層技術及開發框架的發布，Web與 窗體應用的界限正在被逐漸模糊。雖然技術已經煥然一新，但很多開發人員并不是專業的信息架構師，可能還在使用傳統的、平凡的UI設計風格。富應用已成定 局，過去難以實現的效果在今天看來已如此簡單。本文旨在通過借鑒Web界面設計經驗，來探尋系統UI設計的最佳實踐。

一 指導原則概述

• 系統是自描述的 對于好的UI設計系統應該易于使用。無需閱讀額外的文檔，系統UI本身就能引導用戶選擇正確的道路。
• 盡力隱藏系統復雜度 簡約風格的UI更易于用戶使用。
• 提示處理過的信息 不要反饋那些用戶無法理解的專業術語，這樣做不僅會使用戶反感，而且會暴露某些敏感信息，要反饋用戶自己的語言。
• 標識引導設計 系統必須清晰地告知用戶：他們身在何處？他們尋找的東西在哪里？他們如何到達？
• 盡快提供反饋 UI應該能夠在動作真正發生之前讓用戶知道動作尚未發生，提醒用戶正處在過程中的哪個階段。
• 人性化設計 合適的字體大小，溫和的背景色，合理的按鈕位置。
• 保持一致，考慮標準 一致的界面風格易于使用，遵循標準更是使應用程序給用戶以專業的感覺。
• 提供驗證與糾錯 “預防”、“保護”與“通知”是幫助用戶改正錯誤的好的實踐。
• 減輕用戶負擔?把用戶記不住的移交給應用軟件處理。
• 考慮到不同類型與不同水平的用戶 從用戶使用角度出發，給用戶真正想要的，而不是僅靠我們的主觀臆測。
• 提供上下文幫助和文檔 雖然自描述性的UI很好，但清晰的幫助文檔能讓其錦上添花。

二 UI設計流程

第一步：理解需求并了解我們的用戶

　　一個系統的開發與實施一定有明確的目標。開發系統的第一步就是要理解用戶需 求。需求分析的工作一般由PM領導，主要由需求顧問完成。我們通過與用戶訪談，旁觀用戶的工作，咨詢行業專家或借鑒各類相關數據來得到用戶場景。通過對用 戶場景的分組，過濾，以及挖掘，我們可以得到用戶的角色以及不同角色對系統的需求。

　　了解系統中的角色，以及他們之間的關系。在設計UI前，我們應該知道這些角色 能夠做什么，期望做些什么以及不能做些什么。我們要了解這些角色的主要任務，并深入研究他們的工作習慣、知識層次以及他們理想中的軟件應該是什么樣子。與 這些代表不同角色的關鍵用戶交談，為他們每一個人編寫一個場景來描述他們理想中的最佳體驗是個不錯的方法。作為設計者來說，我們必須清楚用戶的習慣。在某 些行業，可能從業者所希望的界面風格是常人無法理解的，但對于該角色確實是可行的。這些信息，如果不與用戶面對面的溝通，恐怕很難從文檔中獲取。

　　一般步驟如下：

• Step 1：與用戶訪談，并記錄用戶描述，得到“訪談記錄”。
• Step 2：整理訪談記錄，并得到“用戶故事”。
• Step 3：定義用戶角色，得到“角色職責表”。
• Step 4：定義用戶權限，得到“權限列表”。
• Step 5：定義用戶場景，描述用戶做什么，與系統如何交互，對出現的問題的反應，對系統的期望，得到“用戶場景描述”。

　　補充：需求分析很多時候有業務顧問擔任，但根據項目規模，可能這部分責任也會落在你的身上。下面分享“5W1H”，供讀者借鑒。

What 用戶要做什么？用戶的期望是什么？

Why 用戶的目標什么？用戶為什么有這樣的想法？

Where 用戶處在何種場景活應用環境中使用系統？

When 用戶什么時間使用這些功能？

Who 誰在使用這一系統？他們有什么差異？他們的習慣有何不同？

How 用戶的業務流程是什么樣的？系統如何幫助用戶完成任務？

第二步：定義功能，劃分模塊

　　進入這一階段表示需求已經被分析并定義。UI設計者應該確認以下事項是否已經清晰：

• 業務流程是否清晰？
• 數據流向是否清晰？
• 數據字典(數據信息的定義)是否清晰？

　　如果上述問題還存有疑問，那么就應該停下來把前期工作做好。

　　一般步驟如下：

• Step 1：分析用戶場景，定義用例，得到“用例列表”、“用例圖”。
• Step 2：明確功能需求，得到“需求規格說明書”(僅功能需求部分)。
• Step 3：劃分模塊，明確模塊的功能，涉及的實體以及模塊間的相互調用關系，數據流向，得到“功能結構圖”、“模塊設計說明書”或“概要設計”(僅UI部分)。

第三步：設計全局導航與局部導航

　　導航與標識的設計體現了設計者對復雜事物的組織能力。導航與標識往往密不可 分，很多時候導航就在充當標識。標識如同系統中的地標，幫助用戶了解：他們身在何處，他們的目的地在哪，以及他們如何完成操做等。在大型系統中，標識幫助 用戶不會迷失。導航則幫助用戶迅速達到目的地。

　　有3類導航，分別為：

結構導航 結構導航顯示了系統的層次結構，例如：全局導航。

關聯導航 關聯導航用于將某個頁面與和它有某種聯系的頁面相關聯，例如：顯示某項的詳細信息。

可用性導航 內容以外的所有功能導航都屬于可用性導航，是系統功能非常重要的標識，其主要與某些功能頁面相關聯，例如：修改密碼。

　　導航有2類模式，分別為：

彈跳 用戶前往弄個子頁面，需要先跳轉到該子頁面的父級或祖父級頁面，然后逐級跳轉到該頁面。使用這個模式有兩個原因——第一，有太多的層次或頁面，用戶可能需要一點點地沿著標識的路徑達到目的地；第二，用戶需要逐級與系統交互，確定路徑走向。

蟹行 用戶像螃蟹行走一樣，在頁面之間橫向跳轉。該模式常常用于兄弟頁面之間的跳轉。

　　一般步驟如下：

• Step 1：分析用戶功能的實現邏輯，繪制“路徑圖”。

　　“用例圖”和“系統 結構圖”都能反映出系統的功能結構。但是，它們都無法反映出用戶如何使用系統。“路徑圖”反映了用戶如何使用系統，包含了業務邏輯，以及各功能模塊之間的 調用關系和數據流向。“路徑圖”顯示了用戶完成任務，需要在系統中行走的路徑，就如同地圖一樣，反映出不同功能的復雜程度。

• Step 2：分解或合并功能模塊。

　　通過分析“路徑圖”，我們可以通過合并模塊來將過程冗長的路徑縮短，或者通過增加模塊，更加詳細地分解活動，實現更細粒度的控制和授權。但這一切的修改，都應該與關鍵用戶共同來完成。

• Step 3：設計導航欄。

　　確定導航欄的位置 放在頂部可以增加內容區域的面積，但是導航條目過多時，一行就放不下了。放在左側，可以增加導航欄的面積，可以放入比橫行更多的按鈕，但是會減少內容區域的面積。兩者給有所長。需要根據需要選取。

　　設計導航樹 設計導航樹要考慮兩個問題。第一，導航樹要適合進行權限控制。第二，導航樹的層次要便于用戶使用，一般常用功能的排列靠前，還有考慮樹的深度，太深了會增加用戶的記憶負擔。

• Step 4：確定局部導航的形式和規模。

　　首先，要確定局部導航的形式，可能的形式包括：包括在Logo中添加鏈接，在數據查詢結果集中添加鏈接，“面包屑”等。

　　然后，確定局部導航的規模，局部導航過多會使系統路徑相對復雜，增大開發工作量。因此，應該壓低局部導航的數量，力爭做到簡單實用。

• Step 5：動畫設計。

　　具有動畫的導航具有 更高的用戶體驗，而且對于數據需要延遲加載的導航來說，動畫效果是必須的。然而，使用的場合要區別對待，并不是效果越絢麗越好。動畫只需要流暢并能夠個用 戶以反饋就好，畢竟對于應用系統而言，業務處理才是其核心價值，不能浪費項目組的寶貴資源來打造一個“花瓶”。

第四步：界面設計

?　　界面設計最簡單的方法就是參考同類系統的UI設計，結合實際項目和用戶需要 進行調整。界面設計有極大的自由度，因此也帶來的一定的風險。設計者需要很強的業務知識，如果缺乏對用戶工作的了解，很可能無法理解用戶的真正期望。因 此，調研和溝通非常重要。界面設計長犯以下錯誤：

問題	描述	解決方法
少字段	這類錯誤經常在后期開發階段才能發現，即便是使用原型向用戶演示，常人也很難發現缺少某些數據。	在設計界面時，就嚴格篩選界面包含的實體及其屬性，考慮數據的收集和流向問題。
界面假死	當程序執行某個耗時的操作時，沒有給用戶以反饋，用戶錯誤認為系統down掉了，此時有些用戶不會耐心地等待系統反饋，而是以設計者難以預期的方式操作。	使用動畫來提示用戶系統“忙”。
風格凌亂	當多位設計人員參與到界面設計時，容易發生風格不統一是事情，如樣式差異，多種同義詞，處理方式的不同等。	約定規范，統一風格，由責任人負責統領全局。
有去無回	某些操作完全是單向的，一旦進入無法返回，UI設計沒有為用戶提供相反的操作路徑。	嚴格審核“路徑圖”。
歧義	同一界面中多個標識指向相同的位置，讓用戶感到迷茫。?	減少不必要的局部導航。
無法實現	UI設計人員不了解開發技術，錯估技術難度，設計了超出成本或超過開發團隊能力的界面。	技術人員參與UI設計。
海量信息	UI給用戶呈現了過多的數據，讓用戶感覺到系統難以使用，并且極大地破壞系統的美觀程度。	優先“隱藏”而非“禁用”；展示用戶期望的數據；分層次展示數據。
大量的手工輸入	UI沒有幫助用戶完成信息的采集，沒有進行驗證，也沒有試圖減少用戶使用系統的工作量，造成用戶在錄入數據上過多地承擔責任。	讓系統盡力分擔用戶工作，減少用戶使用系統時的工作量，并對用戶信息進行驗證，對錯誤進行提升。
缺少提示	用戶在進行某些重要操作時，UI沒有盡到提升義務，易造成用戶使用時無意識地破壞數據。	確認對話框。
臆測界面	設計人員從自己使用系統的角度出發來設計界面。由于缺少業務經驗，往往會與用戶期望發生偏差。	溝通，溝通，以及溝通。
無序且沒有重點	UI的標識不明顯，沒有起到引導用戶的作用，導航欄顯得沒有秩序，用戶看不出當前界面有那些重點。	為功能需求排序，常用功能應該得到更好的位置。

第五步：界面分割與整合

• Step 1：從權限或功能復用角度將現有頁面分塊。
• Step 2：按功能將所有塊分組。
• Step 3：分析每個分組中塊間的共性與差異，結合每個塊所包含實體的差異，來考慮該分組模塊的可復用性。
• Step 4：以分組為單位，抽象各個功能塊，并作為整體UI的一塊積木。
• Step 5：使用新的UI分塊來重組各個界面。
• Step 6：在使用可復用組件組成的UI中，從包含的業務實體及數據傳遞角度重新考慮可行性。
• Step 7：完成整體的迭代后，為各個功能塊界面定義編號，并完整描述。

第六步：開發原型->演示->收集反饋->改進

　　以用戶為中心設計系統的很重要的一步就是收集用戶反饋。完成原型開發，并及時向用戶演示，與用戶頻繁地交流，共同測試系統原型，能有效促成UI的高可用性。

三 設計圖標

　　圖形隱喻就是通過圖形暗示用戶的一種技巧。比如Windows里的回收站，歷 代Windows系列產品，只要我們看見那個“垃圾桶”我們就知道那是回收站。可見，好的UI，往往需要對圖標進行定制化設計，使其包含某種隱喻來引導用 戶使用系統。圖形隱喻可以推廣到整個UI設計，不僅僅是圖標設計，尤其是在游戲軟件中。令我深有感觸的就是《星際爭霸II》，其UI設計無疑增加了游戲整 體的用戶體驗。但是，使用圖形隱喻存在一定風險。UI設計者的個人看法，如果與大多數的人有偏差，就會適得其反。畢竟，我們做的仍然是應用軟件而不是游 戲，不會有強大的美工和設計團隊，在我們追求前衛設計的時候，可能會讓用戶感到困惑。因此，筆者從風險和成本角度考慮，并不建議在應用軟件中過多地依賴圖 形隱喻。也許，我們的軟件沒有什么特點，但作為應用軟件UI，簡約、易用、高效才是我們設計的目標。所以，在此我只考慮圖標的設計原則。

　　圖標設計的核心思想——用美觀的圖形抽象現實事務(事物)。以下是一些指導原則：

• 圖標風格應該保持一致，并且與系統UI相輔相成。
• 圖標應該提供清晰的標識，要選擇合適的隱喻，例如回收站就用“垃圾桶”來隱喻。
• 圖標不會因文化而引起歧義。
• 圖標應該簡單明了，應該保證用戶可以看清。
• 不要挑戰用戶的智商，直截了當的圖標更受歡迎。
• 圖標的隱喻應該是約定俗成的，不應該修改那些普遍被大眾所接受的方式，新的設計往往讓用戶迷惑。
• 如果有行業的標準，如“播放”、“暫停”，就該墨守成規。

　　圖標設計，可能已經超出了我們大多數人的技術范疇。這類工作更適合于專業的美工來完成，而不是UI設計人員。如果你不擅長矢量作圖，請一名專業美工可能更好。

　　下面我分享下我自己繪制的LOGO：

?

作者：MeteorSeed

感謝您閱讀本文，如果您覺得有所收獲，麻煩點一下右邊的“推薦”，您的支持是對我最大的鼓勵...

轉載請注明出處。

總結

以上是生活随笔為你收集整理的从Web借鉴UI设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。