主題一個成功的交互系統必須能夠滿足用戶的需要。這意味著不僅要能夠識別各種用戶群，而且還可辨別各個用戶所掌握的技能、經驗以及他們的偏好。 雖然開發人員和管理人員很容易自認為他們了解用戶需要，但實際情況常常不是這樣。人們往往關注于用戶應該如何執行任務，而不是用戶偏好如何執行。多數情況下，偏好問題不僅僅是簡單地認為已掌握了用戶需要，盡管這本身就很值得研究。偏好還要由經驗、能力和使用環境決定。這些問題對于設計過程相當重要，因而才會出臺 ISO 13407 國際標準，標題為 human-centred design processes for interactive systems。下文中將從一般意義上對這些標準及其相關問題進行討論。 通過系統的用戶界面，用戶可以了解系統并與系統進行交互。界面中介紹的概念、圖像和術語必須適合用戶的需要。例如，允許客戶自助訂票的系統將與售票員專用的系統迥然不同。關鍵差異不在于需求，甚至也不于在詳細用例，而在于用戶的特征和各系統運行所在的環境。 用戶界面還必須至少從兩個維度迎合潛在的廣泛經驗，這兩個維度指的是計算機經驗和領域經驗，如下圖 １ 所示。計算機經驗不僅包括對計算機的一般性了解，還包括對尚待開發的系統的經驗。在計算機領域和問題領域都經驗不足的用戶（如圖左前方所示）所需的用戶界面與專家用戶（如圖右后方所示）的界面將區別很大。 
圖 1：計算機和領域經驗對易于學習和易于使用的影響 一條仍然適用結論需要引起我們的注意：經驗不足的用戶經過一段時間也會成為專家。有幾條因素可能會阻礙用戶成為專家，例如：低使用頻率、缺乏積極性或高復雜性。相反，有些系統的主要用戶可能經驗相當豐富。那么培訓、高使用頻率或積極性（與日常工作息息相關）則可能是影響他們的因素。表 1 顯示了其中一些問題及其對用戶界面設計的影響。 ? | 低 | 高 | 計算機經驗 | 簡單問答、簡易表格填寫、Web（超鏈接）或菜單界面風格 | 復雜表格填寫、Web（超鏈接）或菜單界面風格（簡單的問答或表格填寫將令經驗豐富的用戶大失所望） | 領域經驗 | 常用術語和概念 | 領域特定術語和概念 | 培訓 | 側重于易于學習（一致、可預知、易于記憶） | 側重于易于使用（直截了當、可自定義、無干擾） | 使用頻率 | 易于學習和記憶，界面風格簡單 | 易于使用，為用戶控制提供多種快捷方式和技巧 | 積極性 | 值得使用，功能強大但表面上并不復雜。 | 眾多高級和可自定義功能，系統較為復雜。 |
表1，影響用戶界面設計的一些因素 交互系統必須設計為能夠適合一定范圍內的用戶經驗和用戶環境，或者必須采取步驟限制設計領域。例如，通過培訓可以減少復雜系統內部對易于學習的需求。或者，可以縮小系統規模，以便更好地滿足用戶的核心需求（這是 Alan Cooper 在他的著作 The Inmates Are Running the Asylum COO99 中提出的建議）。 用戶的技能及其生理特征是我們在以用戶為中心的設計中應該考慮的問題。這類問題已越來越多地體現在法規中。這主要是為滿足殘疾用戶的需要。但是，人們普遍認為讓系統適用于更大多數人將對用戶群這個整體大有好處。 下表顯示了世界各地的相關法規和資源： ?表 2a，各國家、地區或團體有關殘疾方面的法規 如下所示，除了法規之外，以用戶為中心的設計和用戶界面設計正日益成為標準化設計的主題。 說明 | Web 站點／標準 | ANSI | www.ansi.org | ANSI ANSI-HFES ANSI-NSC | ANSI 和 Human Factors and Ergonomics Society 出版了一系列聯合標準。ANSI 還出臺了 ANSI-NSC Z365，它與控制和防止由多重壓力引發的紊亂，又稱重復性勞損 (RSI) 有關。 ANSI 現正起草有關人機交互的標準，作為 Information Infrastructure Standards Panel (IISP)（位于 http://web.ansi.org/public/iisp/std_need/needcat.html）的一部分。 | ISO | www.iso.ch | ISO 9241 | 一系列眾多的標準，主要涉及工作站環境中的人類工程學，同時也包括關于可用性的指導（第 11 部分）。同時也作為開發中的 ANSI-HFES 200 的基礎。 | ISO 10075: 1991 | 與腦力勞動相關的人類工程學原理 | ISO 17041-1: 1995 | 用于文本編輯的光標控制 | ISO 11581 | 尚在開發中的處理圖標和指針的系列標準。 | ISO 13407: 1999 | 用于交互系統的以人為本的設計過程的標準。 |
?表 2b，ANSI 和 ISO 用戶界面和以用戶為中心的設計標準 關于以用戶為中心的設計的構成內容尚未達成明確的共識。但是 John Gould 和他在 IBM 的同事于 20 世紀 80 年代開發了一種稱為 Design for Usability (GOU88) 的方法，它包括了最為普遍接受的定義。它從若干交互系統的實踐中發展而來，其中最著名的系統是 IBM 公司的 1984 Olympic Messaging System (GOU87)。? 該方法由四個主要部分組成，如下所述。 Gould 提出：開發人員應決定用戶的組成，并讓用戶盡可能早地涉入。他提出了幾種熟悉用戶、他們的任務以及需求的方法： ???? 與用戶交談 | ???? 到辦公地點拜訪用戶 | ???? 觀察用戶工作 | ???? 將用戶工作錄像 | ???? 了解工作組織 | ???? 自我嘗試 | ???? 使用戶在工作時邊想邊說 | ???? 讓用戶參與設計 | ???? 在設計小組中包括專家級用戶 | ???? 執行任務分析 | ???? 利用調查和問卷 | ???? 制定可測試的目標 |
?在 RUP幾個關鍵階段中都有研討班，但要使理解更為精確，則還須補充 Gould 所描述的種種活動。（這樣做的部分原因在于：人們描述他們做什么和他們實際怎樣做之間往往大相徑庭。他們常常遺忘或省略一些例行任務或表面上無足輕重的細節，諸如工作布局或令人費解的紙片等，因為這些并非“正式”屬于當前流程的一部分。） 可用性任務應在開發的初期并行執行。這些任務包括勾畫用戶界面、起草用戶指南或聯機幫助，Gould 同時還指出可用性應當是小組的職責。?? 集成化設計的一個重要特征是：詳細用戶界面設計的整體方法（即框架）要在初期進行開發和測試。這是以用戶為中心的設計和其他單純的遞增技巧之間存在的重要差異。它確保此后各階段中進行的遞增式設計能夠天衣無縫地適合框架，而且用戶界面在外觀、術語和概念上都能保持一致。 在 RUP 內部，可以通過領域建模來建立該框架，確保用戶界面中出現的所有術語和概念都是業內的共識，尤其要讓用戶理解這些術語和概念。（領域模型中存在某些與特定的用戶組相關的子集。應細心組織領域模型，以保證很容易地就能確定這些子集。）在需求工作流程中進行用戶界面設計時，很多領域類將在接口中表示為邊界類。各個邊界類以及它們之間的關系應與領域模型保持一致，而且還應保持對設計中的系統所有部分在表示方式上的一致性。（這不僅對用戶有所幫助，而且對用戶界面構件的復用有所改進。） 初期用戶測試針對的是初期原型，通常指作為低精確度原型的圖紙及樣型。高精確度的原型將在隨后的流程中出現。 樣型可與用例結合使用，用來為設計之中的系統編寫具體使用場景。可以采用以下形式：講解、帶圖示的講解（用樣型演示）、示意板、（與用戶）預排以及用戶核心小組的基礎。盡管很多軟件開發人員不太熟悉這些方法，但是比起在實施開始后才發現設計不當或需求理解有誤，這些方法顯然更為成本合算。 面向對象的開發已經成為迭代式流程的同義詞。迭代式設計最適合于需要增進了解以及需求常變更的問題。迭代式設計是以用戶為中心的設計的關鍵，這一點毋庸置疑。原因部分在于用戶的需要會隨時間有所改變，另外還在于出臺可處理多種需要的設計解決方案本身就具有復雜性。 請注意：在以用戶為中心的設計中，迭代式設計是在一個集成化的框架內部進行的。我們有意回避在一個統一的框架之外進行遞增式開發，因為那將產生一個“拼拼湊湊”的解決方案。 開發適合用戶需要的系統意味著在需求分析中要付出巨大努力。在以用戶為中心的設計中，重點應放在最終用戶上。他們是業務建模工作流程中的業務主角（對業務外部用戶而言）和業務角色的中的一部分人員。在需求工作流程下文中，他們被更詳細地描述為主角。（主角、業務主角和業務角色三者之間的關系在指南：從業務模型到系統中有所討論。） 但是，以用戶為中心的設計著重強調的問題是：我們要了解充當上文工件中所描述角色的實實在在的人們的需要。特別是，我們必須避免為了方便軟件系統設計而設計假想的人。描述最終用戶的工件必須在和用戶有切實的親身接觸之后進行編寫。在以用戶為中心的設計中，這種親身接觸是有時稱為情景查詢過程的一部分。Hugh Beyer 和 Karen Holtzblatt（在他們的著作 Contextual Design, BEY98 中）將情景查詢的前提闡述如下： “...到客戶工作的地方去、觀察客戶如何工作、然后與客戶談論他們的工作。” （與之有關的具體示例已列在關注用戶中。）此方法不僅可以用來更好地了解系統需求，而且也可以更好地了解用戶本人，了解他們的任務和環境。以上各因素都各有屬性，綜合在一起則稱為使用環境。在 ISO 有關以用戶為中心的設計的標準中有詳細說明（請見下文）。 ISO 的 Human-centred design processes for interactive systems (ISO13407) 確定了設計的第一步是要了解和細化使用環境。建議利用如下屬性： 環境 | 屬性 | 任務 | 系統的用途、使用頻率和持續時間、健康與安全考慮、活動分配、人員與技術資源之間的操作步驟。任務不應僅僅描述為產品或系統所提供的功能或特性。 | 用戶（對每個不同的類型或角色） | 知識、技能、經驗、教育、培訓、生理特征、習慣、偏好、能力。 | 環境 | 硬件、軟件、材料；自然環境和社會環境、相關標準、技術環境、周邊環境、法律環境、社會環境和文化環境 |
表 3：ISO 有關以用戶為中心的設計標準中的使用環境 最好將用戶環境按組成內容分為兩個部分（用戶類型和角色），然后再考慮所有四個環境的相互關系。 
圖 2：環境之間的關系 圖 2 顯示了每個任務都在由某個環境中的某個用戶以某種角色來執行。這些環境對應 RUP 中的工件，如表 4 所示。 ISO 13507 環境 | RUP 工件 | 環境 | | 用戶 | | 角色 | | 任務 | |
?表 4, ISO 有關以用戶為中心的設計標準的環境及其 RUP 工件 每個環境都將對適當的用戶界面設計產生重要的影響。因此，我們會遇到數不清的排列方式。即便是一個小型系統，也可能有 2 種環境（例如：辦公地點和客戶所在地）、3 種用戶（銷售新手、銷售專家和管理人員）以及 6 種角色（電話銷售助理、對外銷售代表等等）。這就意味著每個任務都有多達 36 種潛在的變化形式，盡管實際合理的組合通常要少得多。 顯然，我們應當分別對任務進行說明，但是單單一個說明不可能適合所有排列情況。方法之一是：將用戶和環境因素融入角色說明。這是 Constantine 和 Lockwood 所采用的解決方案 (CON99)。該方案涉及到為每個重要的角色、用戶和環境的排列情況都單獨提供一個“用戶角色”，然后用描述性短語，而不是用簡單的名詞為這個用戶角色命名。例如，比較“客戶”這個角色與“臨時用戶”、“Web 用戶”、“常規用戶”和“高級用戶”等用戶角色。 每個用戶角色說明都包括角色自身的細節外加其用戶（稱作角色承擔者）和環境。這種方法在 RUP 中體現為選取對應用戶角色的主角。 場景、用例和核心用例這三個術語由于概念交叉，在一定程度上容易混淆，因而用在不同的設計方法中，代表的事務稍有不同。例如，“場景”在 RUP 內部指用例實例，即只是一個經過可能的基本流和備選流的特定“路徑”。但是，在以用戶為中心的設計方法和用戶界面設計方法中常常將場景描述為使用經歷，這實際上包含了更多的細節，而不僅局限于事件流。雖然該附加信息可能與后來的設計階段無關，但它對于了解用戶、任務和環境卻必不可少。因此，場景可以在業務建模工作流程（制作示意板和角色扮演）中廣泛應用，但是在需求工作流中，重點則轉移到用例上。 圖 3 顯示了這種交叉的本質。最上一級的標尺將一系列趨向于同時變化的不同因素合并到一起。例如，當越來越以需求為目的時，結構通常變得越為正式。核心用例出現在通用用例右側，因為用戶角色使它們稍加特殊（請參見上一節），這樣它們的結構也更為正式。 
圖 3：以用戶為中心的設計中場景和用例在概念上的交叉 系統用例和核心用例之間的差異最好通過舉例來說明。?表 5 顯示了 Constantine and Lockwood 的 Software for Use (CON99) 中的一個用例： 用戶動作 | 系統響應 | 插入信用卡 |
讀取磁條
請求中斷
| 輸入 PIN |
核實 PIN
顯示事務選項菜單
| 按下相應按鍵 |
顯示帳戶菜單
| 按下相應按鍵 |
提示輸入金額
| 輸入金額 |
顯示金額
| 按下相應按鍵 |
退出信用卡
| 取出信用卡 |
出鈔
| 取現 | ? |
表 5：從 ATM 提取現金的通用用例 該示例詳述了主角與系統之間的事件發生順序，中間隔開兩欄的垂直線代表用戶界面。請注意：盡管 Constantine 和 Lockwood 建議核心用例采用此樣式，但這個特定用例并不屬于核心用例。因為它的基礎是交互操作的句法細節。即：交互是如何發生的。核心用例側重于交互的內容（稱為語義）。表 6 才是交互操作的核心內容。 用戶意圖 | 系統職責 | 表明身份 |
核實身份
提供選項
| 選擇 |
出鈔 | 取現 | ? |
表 6：從 ATM 提取現金的核心用例 此用例提煉出了提取現金交互操作的本質。“用戶動作”與“系統響應”兩標題分別由“用戶意圖”和“系統職責”取代，用以反映強調重心的轉移。良好的界面設計是以用戶目標和意圖為中心的，這在常規用例中常常體現不出來。?? 但是，核心用例自身也確實存在缺點。對表 5 中顯示的如此直截了當的用例提煉本質時，肯定會大有爭議。例如，插入信用卡識別的是客戶還是帳戶？Constantine 和 Lockwood 在此例中選擇了能夠識別客戶，但實際上絕大多數現有的 ATM 機只能識別帳戶。考慮到技術的創新，如視網膜掃描和指紋鑒定等，這可能是作者有意的選擇；否則就可能是作者的疏忽。如果是前一種情況，持有多個帳戶的用戶還必須繼續再作選擇。 核心用例帶來的另一個難點是：由于本質抽象，它們不適合最終用戶和其他涉眾復審。部分原因在于：核心用例必須轉回到代表用戶動作的具體形式。通過編寫具體描述交互操作的腳本，得到設計模型，就可以進行這一步驟。（盡管它與用戶系統交互有關，而與內部對象協作無關，但與用例實現類似）。 RUP 并未明確地引用核心用例，但在活動：用戶界面建模中，以核心用例為起點，隨可用性需求的不斷發展和擴充，從而創建用例示意板，詳情請參見指南：用例示意板。?? - 首先要闡明用例本身，而不是用戶界面。首先要使用例說明不受用戶界面影響，對未經研究的用例更應如此。隨著對用例的理解，事件流示意板可隨用戶界面和可用性等方面逐步補充。[來自指南：用例示意板]
這意味著需要刪除所有設計或當前實施細節，而只留下語義（交互的含義）。隨著各種備選設計的完善，句法細節（交互采用的方式）作為一種實現方式添加到核心用例中。（每個備選設計實際上是同一核心用例的一種實現方式。） 這些用例示意板用作活動：用戶界面原型設計的輸入，用以開發用戶界面原型。
? |