究竟是什麼構成使用者導向設計,目前尚無明確的共識。不過,John Gould 及 IBM 同僚已於 1980 年代發展出一套方法,稱為為可用性為設計 [GOU88],提出最為普遍接受的定義。這套方法源自於許多互動式系統上的情境經驗,最有名就是 IBM 為 1984 年奧林匹克運動會開發的傳訊系統 [GOU87]。這套方法有四大要素,說明如下。
Gould 建議開發人員要判斷使用者是誰,並及早讓他們參與。他提出許多方法來熟悉使用者、作業及需求:
· 與使用者交談。
|
· 登門拜訪客戶。
|
· 觀察使用者工作情形。
|
· 拍攝使用者工作情形。
|
· 瞭解工作組織。
|
· 親自操作。
|
· 要求使用者邊做邊說。
|
· 參與設計。
|
· 在設計團隊中納入專家級使用者。
|
· 執行作業分析。
|
· 進行問卷調查。
|
· 開發可試驗的目標。
|
在 Rational Unified Process (RUP) 中,許多重要階段都會舉辦研討會,但如果希望形成明確的願景,則這些會議必須再搭配 Gould
所描述的活動(對此論點的部分爭議在於人們經常言行不一。平常執行的作業和似乎不必要的細節,例如放置成果或發現「奇怪的」碎紙屑,由於不是目前流程的「正式」部分,經常會被遺忘或疏忽)。
可用性作業應該在開發早期並列執行。這些作業包括起草使用者介面和草擬使用手冊或線上說明。Gould 也表示應該由一個群組負責可用性。
整合設計的一項重要特色是早期開發和測試詳細使用者介面設計的整體方法 -
架構。這就是使用者導向設計和其他純粹漸進式技術的顯著差別。可以確定後期展開的漸進式設計一定可以完美地結合架構,且使用者介面在外觀、術語及概念上都能保持一致。
在 RUP 內,可利用領域模型來建立此架構,以確保整體商業和特定使用者知道和瞭解使用者介面中將出現的所有術語和概念
(也有一部分領域模型只與特定使用者群有關。必須小心確定領域模型的組織方式可以輕易辨識這些部分)。隨著使用者介面設計的進行,許多領域類別將形成使用者介面元素。使用者介面元素和彼此的關係,應該與領域模型保持一致,且在設計中的整個系統內,也應該以一致的方式表達(這不僅對使用者有益,更能提高使用者介面元件的重複使用性)。
早期使用者測試表示早期編排情節和早期開發低精確度的原型。流程後期將形成高精確度的原型。
分鏡腳本可以給合使用案例,共同為設計中系統撰寫具體的使用情境。這些可能以敘述形式表達,許多軟體開發人員可能較不熟悉圖解敘述(以實際使用者介面的圖例來解說)、分鏡腳本、實際演練(與使用者一起)及以使用者為中心的小組等方式。不過,相較於一旦實作展開之後才發現不適當的設計或誤解的需求,這很顯然很值得。
物件導向開發已等同於反覆式流程。反覆式設計很適合於需要不斷推敲且需求不斷變動的問題。由此可知,反覆式設計是使用者導向設計的重要元件。除了因為使用者需求會不斷變動以外,也是因為打造一套設計解決方案來解決種種需求,本來就很複雜。
請注意,在使用者導向方法中,反覆式設計是在整合架構內進行。在已達成共識的架構之外,我們刻意迴避可能導致「拼湊式」解決方案的漸進式開發方法。
互動式系統的成功關鍵在於顧及使用者的需求。這表示不僅在乎各式各樣的使用者群組,也關心個別使用者的技術水準、經驗及偏好。
開發人員和管理人員總是自認為很瞭解使用者的需求,但事實上不然。通常只在乎使用者應該如何執行作業,而非他們喜歡如何執行。即使偏好問題本身就很重要,但通常不只是內心的感覺而已。偏好也依經驗、能力及使用境情而定。這些問題非常重要,繫乎設計流程能否達到國際標準,請參閱
[ISO 13407] 報告 human-centered design processes for interactive
systems。以下內容清楚地討論這項標準及相關議題。
使用者透過系統的使用者介面來瞭解系統並進行互動。介面中呈現的概念、影像及術語,必須符合使用者的需求。例如,由客戶自己購票的系統和售票員專用的系統,一定相當不同。主要差異不在於需求或甚至是詳細的使用案例,而是使用者的特質及可能執行系統的環境。
如下圖 1
所示,使用者介面也必須迎合各式各樣的經驗,至少要兼顧兩個層面:電腦和領域經驗。電腦經驗不只是基本的電腦常識,也包括對於開發中系統的經驗。不熟悉電腦或問題領域的使用者(接近圖中的左側),在使用者介面中所需的方法極不同於專業使用者,顯示在圖中最右側。
圖 1:電腦和領域經驗在學習簡易性和使用簡易性上的影響
請注意,經驗不足的使用者不是最後都會變成專家。許多阻擾的因素,例如使用率低、動機不足或太複雜。相反地,有些系統可能有大量的專家級使用者。此時的因素就可能是訓練、高使用率或高度動機(職務相關)。表 1 顯示使用者介面設計的一些問題及其影響。
|
低
|
高
|
電腦經驗
|
簡單的問題和回答、簡單的表單輸入、Web(超鏈結)或功能表介面樣式
|
複雜的表單輸入、Web(超鏈結)或功能表介面樣式(對於有經驗的使用者而言,問題和回答或簡單的表單輸入毫無益處)
|
領域經驗
|
共通術語及概念
|
領域專業術語及概念
|
訓練
|
強調學習簡易性(一致、可預期、容易記住)
|
強調使用簡易性(直接、可自訂、不中斷)
|
使用率
|
容易學習和記住,簡單的介面樣式
|
容易使用,使用者控制項有許多捷徑和操作技巧
|
動機
|
值得使用,功能強大但不複雜。
|
精密且提供許多進階和可自訂的功能。
|
表 1,影響使用者介面設計的一些因素
互動式系統的設計必須迎合適當的使用者經驗和情境範圍,否則必須採取行動來限定設計範圍。例如,透過訓練可以減少在複雜系統中對於學習簡易性的需求。或者,可縮小系統的範圍,以更能符合使用者的核心需求 (由 Alan Cooper 在其著作
The Inmates Are Running the Asylum [COO99] 中提出的建議)。
在使用者導向設計中,我們需要考量使用者的熟練性和身體特質。這些問題目前已逐漸納入法規中。這很明顯是為了顧及殘障人士的需求。不過,讓各式各樣的使用者都可以使用系統,通常也代表對全體使用者群組有益。
下表顯示世界各地的相關法規和資源:
表 2a,各國、地區或法人組織的殘障人士相關法規
除了法規以外,使用者導向設計和使用者介面設計也逐漸成為標準化的主題,如下所示。
說明
|
網站/標準
|
ANSI
|
www.ansi.org
|
ANSI
ANSI-HFES
ANSI-NSC
|
ANSI 和「人因工程學會」已發佈許多共同標準。ANSI 也提出 ANSI-NSC Z365,與控制和預防累積性壓力症候群有關(又稱為重複性動作傷害或 RSI)。
ANSI 正在起草有關人機互動的標準,將成為資訊建設標準小組 (IISP) 的一環。
|
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 使用者介面及使用者導向設計標準
開發符合使用者需求的系統,表示在需求分析上投入大量心力。在使用者導向設計中,此投入成本以一般使用者為對象。
「商業模型」規範涵蓋商業工作者(在企業內部的工作者)和商業參與者(企業外部的工作者)的建模。
確實瞭解人們的需求是「使用者導向設計」強調的重點,這些人將扮演上述工作成果所描述的角色。
尤其,我們要避免為了方便設計軟體系統而捏造假想的人。一定要等到充分、直接接觸使用者之後,再著手撰寫描述使用者的工作成果。在使用者導向設計中,這種直接接觸屬於流程的一部分,有時稱為環境質詢。Hugh Beyer 和 Karen
Holtzblatt(在其著作 Contextual Design 中,[BEY98])對環境質詢的前提描述如下:
「...親自造訪客戶的工作地點、觀察客戶的工作情形,然後和客戶聊聊有關工作上的事。」
(重視使用者中列出一些具體的範例。)這種方式不僅可確實掌握系統需求,也可以深入瞭解使用者本身、作業及環境。各有其屬性,綜合起來統通為使用環境。ISO
的使用者導向設計標準中有詳細的討論,如下所述。
ISO 的互動式系統的人性化設計流程 [ISO13407]
指出設計的第一步是去瞭解和指定使用環境。建議的屬性包括:
環境
|
屬性
|
作業
|
使用系統的目標、執行的頻率及期間、健康和安全性考量、活動的分配、人力和技術資源之間的操作步驟。不應該只以產品或系統提供的功能或特性來描述任務。
|
使用者(每一個不同的類型或角色)
|
知識、技能、經驗、教育、訓練、身體特質、習慣、偏好、能力。
|
環境
|
硬體、軟體、教材;物質和社交環境、相關標準、技術環境、周遭環境、法規環境、社會和文化環境
|
表 3:ISO 使用者導向設計標準的使用環境
建議將使用環境切割為兩個成分(使用者類型和角色),再全盤考量四種環境的關係:
圖 2:環境的關係
圖 2 顯示每一項作業由使用者扮演的角色在環境內執行。這些環境對應於表 4 顯示的 RUP 工作成果。
ISO 13407 環境
|
RUP 工作成果
|
環境
|
|
使用者
|
-
高階:
-
-
商業願景 [區段:客戶資料]
-
關係人需求
-
願景 [區段:使用者設定檔]
|
角色
|
-
高階:
-
商業參與者(外部使用者)
-
商業工作者或商業系統(內部使用者)
-
詳細:
|
作業
|
|
表 4,ISO 使用者導向設計標準的環境及其 RUP 工作成果
每一個環境在設計適當的使用者介面時影響力都很大。因此,我們可能面臨大量的排列。即使在小型系統中,也可能有 2 個環境(例如辦公室和客戶場所)、3 種使用者(新進銷售員、資深銷售員及管理部門)及 6 個角色(電話銷售員、外部銷售代表等).
這表示雖然實際可行的組合通常很小,但每一項作業最多有 36 種可能的變化。
很顯然,作業必須個別地描述,但單一的說明不太可能適用於所有的排列。有一種辦法是將使用者和環境情境納入角色說明中。這就是 Constantine 和 Lockwood 採用的解決方案 [CON99]。其中為角色、使用者及環境形成的每一種有效排列另外提供一個單獨的「使用者角色」,並以敘述性措詞來命名此使用者角色,而非使用普通名詞。例如,請比較角色
"Customer" 與 "Casual Customer"、"Web Customer"、"Regular Customer" 及 "Advanced Customer" 等使用者角色。
每一項使用者角色說明包含角色本身的細節及其使用者(稱為角色演員)和環境。RUP 可選擇對應於使用者角色的參與者來採用這種方式。
「情境」、「使用案例」及「基本使用案例」三者的概念有些許重疊,在不同的設計方法中,分別代表稍微不同的事物。例如,在 RUP
裡,「情境」表示「使用案例」實例;只是基本流程和替代流程中的一個可能的特定「路徑」。不過,使用者導向設計和使用者介面設計方法(將情境視為使用情節)通常比單純的事件流程更詳細。儘管這項額外的資訊與後來的設計階段可能無關,但在瞭解使用者、作業及環境時不可或缺。因此,情境可能經常運用(在製作分鏡腳本和角色扮演中)在「商業模型」規範中,但在「需求」規範中會變成以「使用案例」為重點。
圖 3
顯示此重疊現象的本質。上方的比例尺含有許多傾向於一起變化的不同因素。例如,隨著議題愈往需求的方向移動,結構通常就會愈來愈正式。「基本使用案例」出現在一般「使用案例」的右邊,因為使用者角色讓這些案例更特殊(請參閱上一節),且有更正式的結構。
圖 3:使用者導向設計中情境和使用案例的概念重疊現象
「系統使用案例」和「基本使用案例」的差異以圖解來說明最清楚。表 5 顯示 Constantine 和 Lockwood 在 Software for Use [CON99] 中的一個使用案例:
使用者動作
|
系統回應
|
插入金融卡
|
讀取磁條
要求 pin
|
輸入 PIN
|
驗證 PIN
顯示交易選項功能表
|
按下按鍵
|
顯示帳戶功能表
|
按下按鍵
|
要求輸入金額
|
輸入金額
|
顯示金額
|
按下按鍵
|
退出金融片
|
取出金融卡
|
發行現金
|
取出現金
|
|
表 5:從 ATM 提款的一般使用案例
此範例詳細說明參與者和系統之間的事件順序,兩欄中間以垂直線代表使用者介面。請注意,雖然 Constantine 和 Lockwood
介紹這樣的「基本使用案例」,但這種特殊的「使用案例」不是基本的案例。理由是因為以互動的語句細節為基礎。亦即,互動如何發生。基本「使用案例」著注於互動是什麼(稱為語意)。表 6 是互動的基本版本。
使用者意圖
|
系統責任
|
辨識身分
|
驗證身分
提供選擇
|
選擇
|
發行現金
|
取出現金
|
|
表 6:從 ATM 提款的基本使用案例
此「使用案例」擷取到提款互動過程的本質。「使用者動作」和「系統回應」標頭已改為「使用者意圖」和「系統責任」,反映出語氣的變化。理想的介面設計很重視使用者目標和意圖;這些通常隱藏在慣用的「使用案例」背後。「基本使用案例」特別適用於下列狀況:
-
少數設計限制(例如,對於使用信用卡的隱含設計限制是 false)
-
可能已強化系統來使用其他辨識工具(例如某種安全的網際網路存取機制)
-
希望建立不受設計限制的「使用案例」,以便在沒有這些限制在專案中重複使用。
不過,基本「使用案例」有缺點。如表 5 所示,完全直述的「使用案例」到了開始釐清本質時很容易引起嚴重的爭議。例如,插入金融卡就馬上辨識客戶或帳戶嗎?雖然 Constantine 和 Lockwood 選擇以此辨識客戶,但在大多數現有的
ATM 中,稍後才會辨識。這可能是顧及一些新興的科技而刻意保留的決定,例如視網膜掃描和指紋辨識,但也可能就是疏忽出錯。在此情況下會多出一個額外的選項,擁有多個帳戶的客戶有必要做選擇。
基本「使用案例」還有另一項爭議,由於本質太抽象,並不適合供使用者及其他關係人審查。這個問題有一部分是因為基本「使用案例」必須轉換回代表使用者動作的具體格式。一旦「設計模型」成形時,即可利用具體詞語撰寫情境來描述互動
(儘管著重在使用者和系統的互動,而非內部物件合作,概念上仍然類似使用案例實現化)。
總而言之,下列狀況不適合建置基本「使用案例」:
-
使用者介面技術刻意提高限制(例如,系統必須接受信用卡)
-
預期的效用值得讓使用者花時間瞭解較抽象的「使用案例」。
RUP 並未明確提及基本使用案例,但在作業:設計使用者介面中,以基本使用案例為起點,然後以可用性需求來持續開發並擴充,最後建立分鏡腳本,如準則:分鏡腳本所述。
這表示清除所有設計或目前的實作細節,只留下語意 - 互動的意義。然後,隨著探索各種不同的設計替代方案,在基本使用案例上加入語句細節(互動如何發生),形成一種實現類型
(事實上,每一種替代設計只不過是同一個基本使用案例的一項實現)。
接著,作業:建立使用者介面的原型中可輸入分鏡腳本來開發使用者介面原型。
|