構建用例場景的交互界面設計方法研究

王偉

交互界面是人和機器進行信息交換的通道，用戶通過交互界面進行操作，機器則通過界面反饋各類信息。傳統的界面設計方法已經無法滿足這種復雜的設計要求，難點在于如何保證界面在交互狀態下其設計的合理性和科學性。這就需要探索一種全新的方法來解決交互界面的復雜性、可靠性和有效性的問題。本文試圖采用軟件工程的思維方式來解決交互界面設計的合理性問題。

長期以來，設計界一直存在兩種設計思維方式的爭論，一種是以系統為中心的設計思維方式，一種是以用戶為中心的設計思維方式。以系統為中心的設計方法經歷了科學發現、工業應用、用戶適應三個階段。這三個階段非常漫長，有數據表明，汽車進入25%的美國家庭花了55年的時間，錄像機花了34年，手機則花了13年。［1］這種方法設計的焦點主要集中在系統本身，設計思維方式更偏向于系統的功能和目標實現，但是，人機交互因素的提升加速了技術的普及和推廣。隨著工業技術和信息技術向縱深發展，這種以工程師為主導的產品設計文化正逐步過渡到以用戶需求為重心的設計文化，人和機器之間的視覺對話機制--人機交互界面使系統更具吸引力。無論是微軟的win系列還是蘋果公司的麥金托什系列，以及后來發展而來的ipod、ipad 、iphone，都讓人機交互界面成為一個重要的研究對象。我們看到了人機交互界面在產品上的成功，同時也看到了人機交互界面在產品上的失敗。如果說微軟win系列采用的人機交互界面策略是成功的話，從win95到win7系統還為桌面用戶保留了一致性的場景。但是，win8改變了用戶的使用場景，試圖改變用戶從桌面到移動端消費，結果導致win8在pc端銷售嚴重不暢，距離消費者越來越遠，以致不得不調整人機交互界面設計策略。

20紀90 年代中后期，諾曼博士明確提出以用戶為中心的設計思想。1998年，以用戶為中心的設計正式寫入ISO 9241-210 人機工效(Ergonomics of human-system interaction)標準指導文件中，強調用戶和產品之間的交互質量，包括有效性，效率和滿意度。［2］然而，以用戶為中心的設計思想僅僅作為一種設計理想化指引,實際在產品設計和開發中，如何無限接近這一目標，這是一個難題。以致諾曼博士在后來提出要把關注點從用戶的個體轉移到用戶的活動和為了這個活動所采取的任務上。［3］如何實現這種目標，諾曼博士沒有直接給出答案。本文試圖通過構建用戶用例場景分析，從用戶的場景活動出發來解決以用戶為中心的交互界面設計問題。

1 關于場景

場景設計的概念最早來自電影或者動畫工業，設計者基于某種假設、想象或者事實，通過圖畫兼簡短文字來描繪故事中的人物、場景和故事情節，通過連續性圖畫來表達一連串發生的人物行為和狀態。1967年，IvarJacobson博士在定義愛立信AXE系統的構架時候開始使用場景書寫方法來解決復雜的人機關系問題。Jacobson發明了對整個軟件工業都產生深遠影響的工具—用例。［4］這種方法不僅將以用戶為中心的設計意圖清晰地表達出來，并在平衡用戶、系統、環境三者之間的關系中發揮著重要的作用。1995年，Jacobson先生加盟Rational，與Grady Booch和James Rumbaugh三人一起創造了意義深遠的統一建模語言（Unif i ed Modeling Language ，簡稱UML）。市場根據UML開發了很多工具，包括有名的Rational Rose，Enterprise Atchitect（簡稱EA）工具，用例工具是其中重要工具之一，并大量應用于構建業務場景建模和系統建模過程中,這種方法促使交互界面的設計向更有效的方向發展。

場景用來記錄有關人及其活動的故事。場景描述的優點在于其不僅可以清晰定義用戶及其行為，還能夠清晰定義用戶所處的環境信息及其相互之間的交互關系。用戶通過觸發某個事件來完成任務，事件觸發的情景便構成了一個場景，不同的觸發順序和處理結果就形成事件流。這種分析和設計方法同時還被引入到產品測試中，通過用例測試，快速迭代，可以促使設計無限滿足用戶的需求，提高交互界面的質量，提高了交互界面的有效性、效率和滿意度。

2 用例場景設計

在最新的UML文檔中指出：“用例圖描述了環境中的演員通過使用主題系統來實現某個目標，那就是實現了主題系統為演員提供的一組服務。用例也可以被視為通過主體和演員之間的交互實現相應的功能或者能力。用例圖包含相互關聯的用例和參與者，以及它們之間的通信。演員代表可能對應于用戶的外部系統、系統、或其他環境實體的分類器角色。他們可能會直接或間接與系統發生相互作用。演員往往代表專業用戶類型或外部系統?！盵6]根據定義，用例圖可以理解為包含了用戶（Actor）、用例（Use Case）、系統邊界、關聯描述（如箭頭等）等要素，用于描述用戶和系統功能之間的關系，但并不描述系統內部工作的細節。例如，當用戶到銀行取款，我們為此場景創建一個用例。用文字可以這樣描述：“銀行客戶某某在ATM機上取款...”但并不描述ATM系統內部的工作細節。

圖1

用例是軟件系統工程里的一個重要概念，用例是對一組動作序列抽象的描述，系統執行這些動作序列，產生相應的結果。這些結果可能反饋給用戶，也可能作為其他用例的參數。通過用例的方法來描述動作序列的場景，應用于產品設計和開發中，可以清晰地記錄出用戶的需求，［5］更重要的是通過用例圖可以發現其中的問題。用例可以采用自然語言的描述方式，如文本法；也可以采用形式化語言的表達方式，如活動圖、序列圖、交互圖。文本法就是講故事的方法，這種方法通常應用在項目早期階段，但不夠直觀，也不易操作。對于復雜的產品來說，很難把用戶和系統關系陳述清楚。活動圖就是將用戶的行為用圖表的形式表達出來，其缺點在于很難捕捉到用戶的行為目的，也很難應付復雜的場景。序列圖克服了文本法和活動圖的缺點，能夠清晰描述用戶和系統之間的交互關系，這種表述方式最大的優勢在于明晰了交互關系以及用戶動作所產生的后果。因此，用例圖、活動圖、序列圖并輔以簡短的文字描述方法簡潔、直觀，邏輯性強，強調用戶行為驅動的事件流，能夠清晰有效地建立用戶和系統之間的交互關系，準確捕獲到用戶的實際需求和潛在需求。

在設計用例之前，首先要選擇用戶（Actor）。從UML文檔可以看出，用戶是指存在于被定義系統外部并與該系統發生交互的人或其他系統，他們代表的是系統的使用者或使用環境。這里的用戶是人也可能是其他對象，如系統時鐘。不同的用戶對產品會執行不同的行為或類似的行為。因此，對用戶進行畫像分類，建立用戶模型是非常必要的工作。一般根據用戶本身的性別、年齡、教育程度、收入等數據進行分類畫像，也可以根據用戶的主要活動、工具、工作環境等等來進行分類畫像，建立人物原型實例?！癡B之父”Alan Cooper曾建議不要為超過三個以上的用戶畫像，這容易造成需求沖突。

其次，建立用例（Use Case）。用例用于表示系統所提供的服務，它定義了用戶如何使用這個系統，描述了該系統所提供的某一完整功能以及用戶與系統之間發生的交互關系，用例的描述通常采用動賓表達形式，表示用戶發出的一個動作。例如：添加賬戶、刪除賬戶等。（圖1）

再次，選擇通訊關聯（Communication Association）。通訊關聯用于表示用戶之間或用例之間的對應關系，它表示用戶使用了系統中的哪些服務（用例），或者說系統所提供的服務（用例）是被哪些用戶所使用的。關聯通常用泛化（Generalization）、包含(Include)、擴展(Extend)來表示。關聯能夠有效界定用例的邊界。

泛化通常指用戶之間或用例之間的繼承關系，例如，ATM機用戶可以分為銀行客戶和管理員。用戶和兩者就構成了繼承關系。銀行客戶和管理員使用系統的目標完全不同，因此，泛化強調子用例之間的互斥性關系。

包含描述了用例和用例之間的關系，可以將一個復雜的用例分解成比較小的步驟。例如，銀行持卡在線用戶可以通過手機來維護個人賬戶，維護賬戶可以分解成添加賬戶、修改賬戶、刪除賬戶、查詢賬戶。維護賬戶就和四個用例構成了包含關系。用例之間的包含關系還描述了在執行基本用例的實例中插入了一個行為段?；居美煽刂婆c包含用例的關系，并可依賴于執行包含用例所得的結果。例如，當用戶進行商品在線交易時，購物、交易、退款或者轉賬時都需要識別客戶，至于采用何種方式識別并不重要。

擴展關系通常指基本用例功能之外的延伸。例如，網上購買商品后需要“查詢賬單”，這是個基本用例，但是，客戶可能需要“打印賬單”。打印賬單和查詢賬單之間就構成了擴展關系。擴展強調行為的偶發性，在查詢賬單時并不一定需要執行打印行為。

在用例設計過程中，用例必須是由一個角色觸發而產生的活動。如果存在角色不產生交互行為的用例時，要考慮將其并入到其他用例中，或者檢查該用例的用戶有沒有被遺漏的可能。如果發現有任何用例與不相關聯的用戶存在，就應該考慮該用戶是如何與系統發生對話的。

除了用戶作為用例的用戶之外，還有一個特殊的系統用戶—系統時鐘。在很多情況下，我們需要在系統內部定時執行一些操作，如檢測系統使用狀況、供電情況、內存情況、給用戶發送消息 等等。從表象上看，這些操作并不是由用戶觸發的動作。但是，我們把定時器抽象出來作為一個特殊用戶，利用該用戶來觸發某些定時操作。例如：當學生將在線課程加入到選課計劃里的時候，課程將在某個時點開始，我們需要將時鐘用戶加入進來，當臨近這個時間點的時候，系統會自動向用戶發送上課提醒信息。

單純描述用例是分析界面交互設計的第一步。在哪些環節需要界面，哪些環節不需要，這就必須要清晰描述用戶和系統之間的交互關系，選擇序列圖來描述是個非常有效的方法，從可視化的行為邏輯中容易暴露出潛在的問題。序列圖（圖2）為交互和可視化界面設計提供詳盡的信息。沒有這些內容，交互和可視化界面設計就缺乏堅實的邏輯基礎。

實踐發現，通過用例圖的方法來構建場景是交互界面設計的有效方法，這種場景可以有效地將設計從系統轉移到用戶和系統環境的研究上來，引導出相關的交互界面，也更貼近以用戶為中心的設計目標。這種方法還帶來一個好處，即能夠有效地控制系統功能的細分粒度，既不會設計多余的功能，也不會因為缺少某些功能而導致系統無法滿足用戶的需要。

圖2 序列圖（登錄案例）

3 書寫用例規約

為了進一步細化用例表述的信息，需要書寫用例規約（表1）。書寫用例規約通常包括以下幾個方面：

1.簡要說明 (Brief Description) ，簡要說明此用例的目的和作用

2.用例場景 (Use-Case Scenario) ，包括能夠完成預期目標的場景以及完成目標失敗的場景，場景主要由兩個流組成，包括基本流和備選流。也就是說，為用戶提供多種完成任務的過程描述，確保用戶能夠在實現目標任務的過程中完成任務或者能夠正確退出任務。

3.事件流 (Flow of Event) ，包括基本流和備選流?；玖魇敲枋鲇脩粽_完成任務的過程。備選流也叫異常事件流，就是用戶在完成任務過程中可能發生的種種異常事件的描述。描述事件流可遵循一些基本方法，例如只書寫“可觀測到的”事件，使用主動語句，用參與者或者系統時鐘作為主語等等。

4.特殊需求 (Special Requirement) ，描述與該用例相關的非功能性需求（包括性能、可靠性、可用性和可擴展性等）和設計約束（所使用的操作系統、開發工具等）。［9］

5.前置條件 (Pre-Condition) ，執行用例之前必須指定系統所處的狀態，這種狀態是交互事件發生的前提條件。

6.后置條件 (Post-Condition) ，用例執行結束后系統可能處于某種狀態，等待下一個事件的發生。

表1 用例規約案例

單純描述用例是分析界面交互設計的第一步。在哪些環節需要界面，哪些環節不需要，這就必須要清晰描述用戶和系統之間的交互關系，選擇序列圖來描述是個非常有效的方法，從可視化的行為邏輯中容易暴露出潛在的問題。序列圖（圖2）為交互和可視化界面設計提供詳盡的信息。沒有這些內容，交互和可視化界面設計就缺乏堅實的邏輯基礎。

實踐發現，通過用例圖的方法來構建場景是交互界面設計的有效方法，這種場景可以有效地將設計從系統轉移到用戶和系統環境的研究上來，引導出相關的交互界面，也更貼近以用戶為中心的設計目標。這種方法還帶來一個好處，即能夠有效地控制系統功能的細分粒度，既不會設計多余的功能，也不會因為缺少某些功能而導致系統無法滿足用戶的需要。

用例規約為產品設計提供了豐富的信息，也為產品開發和測試提供了詳盡的文本。其意義體現在一下幾個方面：

· 擬真性。場景的描述記錄了用戶的真實行為，構建可視化場景。

· 準確性。能夠準確地描述用戶的每一個動作以及系統應該給予用戶準確的反饋信息。

· 交互性。能夠詳細描述了人和系統之間交互關系。

· 可評估性。能夠對用例或者事件流作出科學評估。

· 意外事件。能夠準確預測用戶在使用產品的過程中可能發生的意外，并采取相應的設計來避免這種意外的發生，并建議建立安全的退出機制。

· 非功能性需求。能夠對非功能性需求提出明確的要求，如密碼安全等級提醒。

通過描繪場景的用例的設計方法是研究和梳理人、機、環境之間的重要方法之一。當面臨一個既模糊又復雜的需求場景時，通過書寫用例的方法能夠比較快速地準確捕獲需求，能夠將需求通過交互界面準確映射到人、系統和環境之間的交互關系中。用例的重要性在于在產品設計和開發過程中，通過用例捕獲用戶需求，通過人機交互界面來傳達需求，通過用例來發現系統對象，根據用例來跟蹤產品測試。

4 結語

用例工具和序列圖工具是解決人機交互界面建模問題比較科學的方法。通過上述方法構建人機交互界面具備以下優點。第一，交互界面堅持了以用戶需求為導向的設計思想，而不是靠設計師的主觀構造。第二，實現系統交互界面設計和需求分離，重點關注用戶的需求。第三，便于系統交互界面之間的跟蹤測試。第四，能夠靈活適應用戶的需求變更，快速完成設計迭代。第五，用例圖描述場景簡潔、直觀，表達清晰，便于項目參與人員和客戶之間的溝通。第五，減少捕獲需求過程中的各種資源消耗，有利于敏捷開發。［10］

用例圖是用戶場景建模的優秀工具。但是，也可看出用例并不擅長描述某些非功能需求， 對于系統的性能、可靠性、穩定性、健壯性無能為力，這些在交互界面表現層面又顯出特別重要的意義，例如密碼安全級別提示就是一種重要形式，這些有賴于用例規約的創新性設計和慎密的思考。