今天準備聊下軟件產品的交互設計和易用性方面的話題。當我們做一個互聯網SaaS類應用產品的時候，實際上整體產品設計不僅僅是簡單的UI和模板配色，更加重要的即是基於業務場景和目標驅動的交互設計。

交互設計更加體現了在整個產品設計中的動態部分內容。

交互設計概述

交互設計是一種如何讓產品易用，有效而讓人愉悅的技術，它致力於了解目標用戶和他們的期望，了解用戶在同產品交互時彼此的行為，了解「人」本身的心理和行為特點，同時，還包括了解各種有效的交互方式，並對它們進行增強和擴充。

交互設計還涉及到多個學科，以及和多領域多背景人員的溝通。

在《交互設計實用指南》里指出，交互設計應當是創造承接人類與計算機之間的界面即人機界面(Human-Computer Interface。交互設計的出發點在於研究用戶和計算機交流(dialog)的時候，人的心智模型和行為模型，並在此研究基礎上，設計界面信息及其交互方式，用人機界面將用戶的行為翻譯給計算機，將計算機的行為翻譯給用戶，來滿足人對軟件使用的需求。

所以，交互設計一方面，是面向用戶的，這時交互設計所追求的既是可用性(Usability)，這也是交互設計的目的所在；交互設計的另一個方面是面向計算機實現的，這時我們關注於「軟件工程化」。

在交互設計中，可用性設計是一個關鍵內容，可用性指的是一個產品可以被特定的用戶在特定的使用情況中，有效、高效並且滿意得達成特定目標的程度(ISO9241)。其本身可以理解為有效，高效和滿意三個遞進層次。

有效性：有效性是指用戶完成特定任務和達到特定目標時所具有的正確和完整度。如果用戶不能完成他們的目的，那麼無論體驗是長時段，容易還是複雜，這個產品可能都沒有意義。

高效性：高效性是指用戶在完成特定任務和達到特定目標的容易程度和時間長短。這可能會牽涉到許多因素。例如，我們的軟件啟動速度太慢，處理速度太慢，這會影響到軟件的高效。再比如，在一個呼叫中心使用一個更高效的呼叫中心系統，可能造成操作員每天能夠處理更多的電話數。

滿意度：滿意度是指用戶在使用軟件產品過程中所感受到的主觀滿意度和接受程度。在用戶能夠有效、高效地使用軟件的基礎上，給予用戶一些更多地「體驗」，考慮那些更多內涵。這也是我們交互設計真正的水平所在。例如：我們需要避免用戶出錯，也同時能夠提高方法讓他們從錯誤中恢復；我們需要讓軟件易學，以便讓新手快速成長為中間用戶，讓需要的中間用戶成為專家；我們需要做精美的頁面讓用戶喜歡；我們需要塑造我們的品牌風格，讓用戶「膜拜」……

交互設計就是設計軟件上可提供的交互方式，來滿足人對使用軟件的三個遞進層次的需求。

也就是說，首先，應當保證軟件的有效性，如非有效，一切皆空。接着，保證軟件的高效性，軟件雖然已經完成了他的目標，那麼是不是可以在這個基礎之上，縮短完成目標的時間長度或者是降低認知成本等，最終達到提高生產力的目的。

在完成了這兩點之後，我們可以繼續考慮提高軟件的滿意度，這裡可以通過一些視覺的提升、品牌效應和創造新的體驗(蘋果一直是這方面的好例子) 等方法來提高軟件的滿意度。

用戶體驗五層模型

談交互設計一般會談到用戶體驗的五層模型，從抽象到具體分別是戰略層，範圍層，結構層，框架層和表現層。戰略層往往由公司最高層負責和制定。第二層範圍層，是具體設計軟件相關的功能和內容，該層往往由公司的產品部門負責和實施。第三層是結構層，包含交互設計和信息架構是主要內容，該層也是交互設計師最為關注的重點，一般交給公司的UED部門執行並負責。第四層為框架層，主要是完成交互產品的可視化工作，包括界面設計和導航設計和信息設計工作。最頂層為表現層，主要涉及到APP的視覺設計、動畫轉場、多媒體和文字排版等具體呈現的形態。

對於視覺設計，UI和配色等往往一般有專門的美工或視覺設計工程師，因此對於交互設計工程師來說重點還是在框架和結構層。交互設計要解決的核心問題還是基於業務場景和目標，如何構建一個合適的框架結構，以方面最終的用戶基於這個框架結構快速的完成目標。

易用性和交互設計關係

對於軟件產品的易用性，也可以理解為前面交互設計談到的可用性。即主要解決有效，高效和滿意三方面的問題。交互設計和易用性的關係，可以理解為交互設計是一個業務目標驅動的動態過程，而易用性是最終的產品交互設計輸出的結果。

沒有結合交互設計的易用性輸出，往往更多僅僅是點上的改變，而結合交互設計的易用性輸出才是圍繞業務場景和目標這個線和面上的改變。

所以談交互設計的時候往往比談易用性的範疇更大。在06年我在新浪博客就總結過軟件易用性改進方面的一些內容，具體如下：

//軟件的智能和記憶功能

1.用戶登錄界面最好有用戶名和ID的記憶，焦點直接定位到密碼輸入框
2.單據錄入界面最好有保存和載入默認值的功能
3.單據搜索界面可以保存用戶自定義的各種搜索條件組合
4.用戶調整過的GRID的列寬，窗口的位置可以自動記憶
5.系統可以根據用戶的使用頻度對相關功能進行自動的優先級排序
6.系統能夠記憶不同用戶的使用偏好，使用系統的固有模式和常用的自定義設置
 
//減少不必要的重複交互

1.減少不必要的各種操作，能夠點一次鼠標或敲一次鍵盤完成的絕不作出兩次或多次。
2.提示信息要適度，太多不好，太少也不好。
3.數據項完整性校驗問題要注意光標焦點自動定位到錯誤處
4.完整業務功能不要讓用戶在多個窗口切換多次才能夠完成。盡量減少這種切換。
5.為了方便用戶切換窗口，相關的表單最好都作為非模式的形式。
6.相同的信息不要讓用戶在系統中多處或多次錄入，保證入口的唯一性
7.系統要儘可能根據用戶已經錄入信息自動獲取其它附屬信息，而不需要用戶重複的選擇或錄入。
 
//導航和界面跳轉

1.表單新彈出對話框，對話框再彈出對話框的這種層次要控制在3層以內。
2.所有的非模式活動窗口最好有類似桌面任務欄一樣的停靠方式，方便切換窗口
3.系統可以支持用戶自己定義常用功能和菜單
4.對於常用功能應該提供便捷的快捷鍵和工具欄按鈕
5.對於系統中提供的各種業務和表單功能能夠讓用戶便捷挑轉到幫助信息上
6.對錶單和界面聯動和交互的時候要注意相關界面數據的自動刷新
7.一個窗口中最多不要出現超過三個的GRID控件
8.BS方式不要左右滾屏。CS模式既要避免左右滾屏也要避免上下滾屏
9.需要根據業務查看需求和數據的展現需求來選擇合適的界面控件
 
//系統性能和健壯性方面的

1.系統中相關的耗時操作都必須必須轉變鼠標為等待狀態
2.系統耗時操作超過30秒的最好能夠提供給用戶相關的進度條功能
3.系統耗時功能超過2分鐘的最好能夠設計為異步多線程的方式進行處理
4.系統應用有友好的完整性和約束校驗的提示信息，方便用戶修改錄入數據
5.在系統出現異常情況下應該有友好的統一的提示信息，同時後台應該記錄詳細的異常日誌
 
//界面友好性和易用性方面的

1.表單應該能夠根據屏幕分辯率自動適應。在界面上讓用戶一次能夠看到足夠多的信息
2.表單應該支持Tab鍵功能，順序為從左到右，從上到下。
3.常用的表單應該同時支持鍵盤操作和鼠標操作。
4.界面上控件的布局應該間距適當，標籤和控件對齊，有適當的錄入提示信息。
5.界面的配色應該盡量簡單，盡量少使用各種刺眼的顏色
6.用戶看到表單後應該就基本清楚相關功能，表單要盡量自我解釋，不要設計過多的隱含在界面裏面功能
 
//數據的錄入和檢索

1.根據業務需要選擇適合的數據錄入控件
2.數據錄入控件應該有完備的數據完整性和一致性校驗功能
3.系統應該提供用戶暫時保存錄入數據的功能
4.能夠自動獲取數據不要讓用戶再去錄入，能夠選擇錄入數據不要讓用戶手工錄入
5.數據檢索條件應該適中，不應太多也不應太少。檢索支持組合條件檢索。
6.為了滿足不同需求檢索可以提供簡單檢索和高級檢索多種方式。
7.應該在第一時間提供給用戶檢索數據，因此檢索功能存在性能問題時候要考慮分頁。
8.在檢索功能較耗時的時候應該提供給用戶相關的進度條顯示進度
9.表格最好能夠提供行顯示和列顯示等多種顯示模式，方面用戶查看數據

當然這個總結更多的是面向傳統BS端軟件應用的，那麼對於移動互聯網和手機端應用軟件，實際上核心思路雖然相同，但是具體的交互設計和易用性設計出現了很大的變化。對於這塊網上也有專門的文章進行總結。

而對於交互設計和易用性，今天還是結合我們自己的軟件研發的一些情況，對裏面經常出現的一些交互設計和易用性問題進行總結和思考。

交互設計和易用性核心是什麼

最近我一直在思考一個問題，就是交互設計和易用性的核心究竟是什麼？我們可以聽到很多和易用性相關的一些說法，包括了UCD用戶為中心，目標導向，可視化設計，信息架構分層，UI界面設計，減少記憶等很多內容。

但是真正交互設計的核心仍然是我前面談到的一句話，即：

交互設計核心是深刻理解業務場景和用戶需求，然後設計最合適的通達需求的路線。這就已經解決了可用和高效的問題，其次就是注意整體風格，配色，一致性等靜態設計，以獲取更好的一個使用體驗感受，達成使用產品過程愉悅。

簡單來說交互設計需要完成從業務場景到業務功能實現之間的映射，而這個映射的另外一個關鍵就是角色，不同的角色往往驅動了不同場景下不同的功能點和內容的編排。

角色是一個抽象的概念，比如我們常說的審批者，普通員工，管理者，財務會計，項目經理等。一個人員本身又可能擁有多重角色，比如張三既是一個普通執行者，同時也是一個管理者或審批者。由於存在這種組合，也導致整體的交互設計或功能設計會變動更加複雜。

對交互設計的一些舉例說明

在這篇文章我不準備再去講解太多交互設計理論或易用性原則的內容，而是結合這些原則舉一些實際的場景和例子來說交互設計和易用性設計。

功能滿足粗粒度特性

在談SOA架構和接口服務設計的時候，經常會談到服務具備粗粒度特性，即任何一個服務都是滿足某一個業務場景需求而設計實現的，同時僅僅提供消費者需要的內容，屏蔽任何和需求無關的實現細節，內部的複雜性不要暴露給客戶。

即使我只想看到我希望的內容，其他都是干擾。

舉一個簡單的例子，採購系統提供了供應商信息模糊查詢功能，任何需要查詢供應商都可以通過該功能，該功能有諸多的模糊查詢條件，供應商信息查詢結果也會顯示基本信息，地址信息，擴展明細表格信息。

但是有一個業務場景很簡單，即僅僅通過供應商編號，快速的查詢到供應商的名稱，組織結構代碼，法人代表，聯繫人姓名和電話。

如果這個功能使用場景相當大，按粗粒度原則就應該單獨設計和實現一個獨立的小功能，這個小功能一方面可以減少信息過載，同時本身也保證其他信息安全，同時由於返回信息量小可以實現更加高性能的查詢響應速度。

操作入口和首頁設計

「操作入口明確」，就是指產品的任何一個功能都要有明確、合理的入口。「操作入口」，指的是產品內部不同模塊之間的轉接元素，例如在Web產品中，按鈕控件、輸入框、文字鏈等都屬於操作入口；「明確」指的是入口的視覺感是清晰的、可識別的；「合理」是指入口的出現是符合用戶操作邏輯的，適時的。

任何一個APP類應用可以看到，首頁都是最關鍵的一個設計頁面。因為所有的用戶在登錄進入到APP後，首先看到的就是首頁這個界面。

首頁的設計不是簡單的堆放幾個快捷圖標，給出幾個統計分析圖表，而是真正要從業務場景和角色驅動去思考，一個用戶在登錄進來就最希望做什麼事情？那麼這個事務就必須顯示最方便，最容易達到的地方。

一個報銷APP來說，對於普通員工登錄後最想做的事情就是報銷，那麼報銷的核心功能必須放在首頁最顯眼的地方，而不是放在任何二級目錄下。

其次，一個用戶兼顧了多個角色的時候需要同時考慮如何設計多角色兼顧的首頁和展現，比如一個管理者登錄報銷系統，本身有單據報銷的需求，也有單據審批的需求。那麼就必須考慮兩者如何更好的整合展現。

首頁對每一個APP應用來說都相當珍貴，不應該浪費掉絕佳的內容展現機會，一個好的首頁一定會促進內容的消費和使用，同時也提升整個APP應用的粘性。

APP端和PC端獨立設計

對於一個SaaS類應用，如果同時存在APP端和PC端兩個入口，那麼即使對於同樣的功能實現也需要分開獨立設計。要知道同樣的功能內容展現形式，交互方式，在APP上都和PC端存在巨大的差別，完全不能用同樣的一套標準或思路進行設計和實現。

舉一個最近看到的例子進行說明

一個申請單的創建功能，在設計PC端的時候設計了一個通過excel批量導入數據的功能。而在APP端卻完全照搬這個功能，那就是一個完全的反例，也是脫離使用場景的產物。

試想以下，APP端本身就不適合Excel處理和編輯，難度在APP端進行申請單創建的適合，我們還先在PC端處理好Excel，再將Excel發送到APP端，然後在APP端進行導入。如果有問題又需要在PC端進一步修改再同步到手機上。

顯然上面這個場景本身就不存在，APP端本身也不應該設計上面這種功能。

效率和易用性有時反而是矛盾

最近看到一個PC端的功能實現，整體採用了嚮導式的設計風格，看起來挺不錯，每一個步驟都有詳細的說明和提升，即使第一次操作這個功能也可以無須他人幫助完成。

Don’t Make me think，這是在產品易用性設計中經常談到的。但是不思考並不代表用戶就是傻瓜，而是應該盡量通過引導的方式減輕用戶的記憶負擔。

什麼是記憶負擔？

一個功能如果你一個月才用一次，那麼下次再使用的時候很可能有些操作步驟或錄入要求你無法記憶清楚了。但是如果一個功能你天天用，每天還用上100次，在這種場景你是不存在任何記憶負擔的說法的。

比如上面的功能，這個功能僅僅是給企業的財務人員用，而不是面向所有用戶使用，財務人員每天可能都用這個功能進行成本核算相關工作，功能使用頻度相當高。

那麼我們嚮導式設計反而是糟糕的設計。

即由於採用嚮導式設計，反而導致一張單據的處理會增加20秒的時間，如果1天財務人員要處理100張單，那麼就會多花半個小時的時間。

這反而極大的犧牲了功能的易用性和使用效率。

單功能設計到多功能協同

在前面談交互設計核心的時候就談到，交互設計往往需要基於場景來進行多功能間的動態協同設計。實現各個功能點之間基於業務場景的自銜接。

要做到這點，一個交互設計師或需求人員必須深刻的理解業務場景。任何一個功能都不應該是孤立存在的，而是為了一個業務場景或目標的達成。

還是拿一個報銷系統來舉例。該系統提供了出差申請，在線預計酒店機票，出差報銷等諸多的業務功能點。而一個員工要出差的場景為：

首先提交出差申請單，出差申請等待主管領導審批
領導審批通過後，進行機票預訂，進行酒店預計
出差返回後進行報銷

那麼如果考慮場景下的多功能協同則是，當提交了出差申請審批通過後，是否會快速的引導我進入到機票預訂界面，還是我要找半天機票預訂在哪裡？其次，出差申請已經填寫了出差的地點和日期，當進入到機票預訂界面的時候是否可以快速的對地點，日期等進行默認輸入，而減少輸入工作量。最後在我基於某次出差申請進行報銷的時候，是否會自動的對出差期間發生的機票，酒店，打車等費用進行自動的歸集，而不再需要我手工導入。

當談到這些內容的時候就可以看到，即使對於一個最簡單的出差場景，都可以做大量的場景分析，基於場景來分析功能點之間如何協同，如何更加自動化和智能化的銜接。

易用性和軟件智能化