目錄

第四章 介面設計方法及程序 ...............................四—1

介面設計程序的特點 ............................................四—2

1. 以使用者為中心的設計方法......................四—2

2. 『時間』要素的加入 ................................四—3

3. 人類學的研究方法的加入 .........................四—4

4. 使用者介面設計的團隊政治考慮 ..............四—4

LUCID ..................................................................四—5

1. LUCID 的設計程序 ....................................四—5

2. LUCID 的設計範疇 ....................................四—9

新界面的設計程序 ..............................................四—10

第二節 設計階段一：發展產品概念 .................................四—12

第一項 定義使用者、決定產品功能 ..........................四—13

第二項 訂定需求事項／工作方針..............................四—14

文字與圖像（icons） .........................................四—14

四—1
 螢幕顯示編排的議題﹕.......................................四—15

輸入和輸出的設備 ..............................................四—16

第三節 設計階段二 : 執行研究與需求分析......................四—17

第一項 使用者的不同................................................四—17

第二項 人類學的觀察................................................四—18

準備....................................................................四—18

田野調查.............................................................四—19

分析....................................................................四—19

報告....................................................................四—19

第三項 參與式的設計................................................四—21

第四節 設計階段三﹕任務分析與架構路徑.......................四—23

第一項 任務分析 .......................................................四—23

操作分析和設計..................................................四—25

階層式任務分析..................................................四—27

第二項 架構路徑發展................................................四—28

第五節 設計階段四：構想發展.........................................四—33

四—2
 第一項 語意設計和句法架構 .....................................四—33

語意設計.............................................................四—33

句法架構.............................................................四—36

第二項 使用構想輔助工具.........................................四—37

設計核心路徑 .....................................................四—37

構想流程圖 .........................................................四—38

故事板(storyboards)...........................................四—38

第六節 設計階段五：建立原型.........................................四—41

第一項 原型的定義及種類.........................................四—42

原型的種類 .........................................................四—43

第二項 構建原型的軟體工具 .....................................四—46

軟體工程團隊的工具 ..........................................四—46

工業設計與視覺傳達設計師的工具.....................四—47

第七節 設計階段六: 進行細部設計 ..................................四—49

第一項 詳細指明使用的設備 .....................................四—50

第二項 發展最終軟體................................................四—50

四—3
 第八節 設計階段七﹕評估測試.........................................四—51

第一項 專家式(expert)評估 .......................................四—52

第二項 觀察式(observational)評估............................四—55

第三項 調查式(survey)評估 ......................................四—57

訪談....................................................................四—57

情境訪談 .....................................................四—58

問卷調查.............................................................四—58

封閉式問題的等級評比方式 ........................四—59

第四項 實驗式(experimental)評估 ............................四—61

第五項 可用性工程(Usability Engineering)測試........四—62

第九節 設計階段八﹕產品發表與提供支援.......................四—64

第四章作業：任務分析與架構路徑發展 .............四—65

第四章作業：設計實作最終發表 ........................四—65

四—4
第四章 介面設計方法及程序

本章摘要

介面設計程序雖然植基於傳統的設計程序，但是其人機互動的特性帶來不同的特
點，本章節前段則專文介紹此特性。

其後闡述介面設計程序。綜合各文獻資料及作者本身實務經驗，將介面設計程序以
符合工業設計及視覺傳達設計師專業的觀點，分為八大設計階段，並佐以實務的設
計案例。此八大介面設計階段包括發展產品概念、執行研究與需求分析、任務分析
與架構路徑、構想發展、建立原型、進行細部設計、評估測試、產品發表與提供支
援。

由於「時間」要素的加入，設計的步驟及工具則有別於傳統的工業設計程序。本章
節後段則介紹了介面設計的工具，比如故事板、構想流程圖、以及製作原型的軟體
工具。

四—1
本章節闡述介面設計程序的八大階段，並佐以實務的設計案例。在
正式引介此八大階段之前，我們必須了解：介面設計程序與傳統的
設計程序的不同之處：

傳統設計中，仍脫離不了描繪產品外形的預想圖 (可能是用電腦輔
助所完成)、製作比例模型等較靜態的模擬方法，來做設計概念與意
象的檢討。至於介面部份，只做簡單地探討，並不排入正式設計方
法之中，以致於時間上並不容許設計師進一步思考使用者與介面互
動的適切與否。

介面設計程序的特點
介面設計程序雖然仍以傳統的設計程序為基礎而出發，但是其人機互
動的特性則帶來以下四項介面設計程序的特點，茲分述之﹕

1. 以使用者為中心的設計方法
近代介面設計在企業裡大多以軟體研發流程為主體、是較為技術導向
的步驟，對於介面的易用性考慮不多，同時也引申出極為棘手的問題。
為了改善這些現象，介面設計的程序必須扭轉以工程研發為中心的設
計方法，轉變為以使用者為中心的設計方法；也就是設計過程中專注
於使用者的需求，以與使用者相關的議題為中心，而不是以技術上的
考量為主。

其次，為了完整的瞭解使用者的需求，除了一般的需求分析外，也實
行任務分析(task analysis)以收集使用者所需執行的作業、以及關於作
業環境之詳細相關資資料。任務分析強調的是系統需要『什麼』功能
(functionality)，而不是強調『如何』去提供這些功能（本章的設計階
段三的任務分析，將有詳細的討論及範例）。

四—2
此外，在設計過程初期，必須以使用者為對象，實行初期的測試與評
估，以確保系統的設計符合使用者的需求。在設計過程進行的期間，
必須重複多次循環式的設計(iterative design)，也就是並不期望一次就
創造出一個不需改變完美的介面，而把目標訂在設計一個持續不斷演
進的介面，在每次循環設計中調整、改進以更合乎使用者的需求，也
就是依須要而重複以下步驟：
『設計－>與使用者進行測試－>再設計』
(design－>test with users－>redesign)。

2. 『時間』要素的加入
介面設計之所以有別於傳統的工業設計程序， 主要原因在於隨著電子
化產品日漸增加，產品的生命常常是與使用者接觸後才真正開始，因
此設計活動應該認真考慮人與產品之間的關係。因為界面是動態的，
而『時間』要素的加入甚多，故而設計程序更像拍攝電影，由三度空
間邁進四度空間，所以必須有腳本、故事板、介面模擬等具有控制時
間變數的設計工具的加入（本章的第ｘ節將會詳細的討論這些工具）。

讀者可能要注意的是，這裡所提及的電影拍攝工具的使用，會同時出
現在設計階段的兩個地方：首先會在設計階段二執行研究和需求分析
使用。這裡的腳本、故事板被當作情境設計的劇本導引工具、藉以輔
助設計師與設計團隊、經理人去深一層地瞭解使用者的生活情況、操
作時的動機、與介面互動的可能情境模擬。這時劇本裡的主角是使用
者的不同群組的代表人物。

其次在設計階段三、四時、腳本、故事板被當作進行雛型之前，藉
以構想介面本身如何被操作、如何反應、如何與使用者互動的任務

四—3
分析的定性工具。此時因為界面是動態的，所以必須把控制時間變
數的設計工具的加入。這時劇本裡的主角是介面本身。

3. 人類學的研究方法的加入
人類學的方法已經應用於辦公室工作觀察、企業組織管理、和其他與
「人」有關的領域。進行人類學的觀察的目標是要獲得重新設計介面
所需要的有關資料。其研究方法包括﹕用以評估之用的方針訂定，田
野調查的執行，資料的分析，和研究結果的報告。依循正確的人類學
程序可以減少忽略重要資訊、妨礙正常設計程序的可能性。

在文獻中較完整的介面設計程序為下述的 LUCID。雖然 LUCID 較偏

重考慮系統工程程序的陳述，稍後本章節闡述的八大階段的介面設計
程序仍以此為本，依作者本身實務經驗加入設計語義、句法架構的設
計階段。

4. 使用者介面設計的團隊政治考慮
Norman(1983)認為，使用者介面是一部機器中最具權謀性的部分1。
事實上，在設計過程中展現對使用者的尊重，同時也代表著削弱技術
人員對計劃的掌控權力、同時可能也是引申出更多的工作負擔。介面
設計經常引起技術團隊與行銷經理及工業設計、視覺傳達設計師之間
的對立。因此，使用者介面的設計過程中一定要建立良好的溝通管道
（不管是在正式的會議之中、或在非正式的溝通場合）
、很有技巧地加
以處理爭議性的議題及將會增加工作負擔的決議，以免關鍵人員的反
彈。通常在設計過程中需要所有相關單位的共同參與，以防止組織內

1 Cushman, William H.,著。蔡登傳，宋同正譯。Human Factors in Product Design. 產品設計

的人因工程。六合出版社。八十五年八月。
四—4
部的傾軋，意氣用事，而導致設計延誤，或被迫推出有重大瑕疵的產
品。

LUCID
在各文獻資料中，對介面設計程序有較完整的討論的是 Ben
Shneiderman，在其著作中對 LUCID 有詳細的介紹2。而 LUCID 也
是本章所提出的八大階段的介面設計程序的主要來源。在詳細闡述
介面設計程序之前，設計師可以參考、部分採用 LUCID 設計步驟的
概念：

1. LUCID 的設計程序
LUCID 為「邏輯性的以使用者為中心（導向）的互動式設計方法
（Logical User-Centered Interaction Design Methodology）」的縮
寫。由專長於使用者中心的設計的商業設計公司 Cognetics 公司所創
造。LUCID 的前身為「量化使用性工程 Quality Usability Engineering
(QUE)」
，為實務顧問經驗的學界人士提出了第一個專注於使用界面的
設計方法。

此設計程序提出了六個設計階段:發展產品概念、執行研究和需求分
析、設計概念和關鍵﹝key-screen﹞螢幕原型、進行循迴的設計和修
正、進行軟體設計、設計階段、提供產品發表支援＜詳細的步驟列於
圖表 4-1＞。LUCID 的完整性來自於經過不同專案的實務執行而證實
和修正。然而、每一項專案都有特別的需求, 所以任何設計方法只是

2 Shneiderman, Ben. Designing the User Interface: Strategies for Effective Human-Computer
Interaction. Addison Wesley Longman, Inc.. 1998.
四—5
專案管理的起點。LUCID 提倡一個循序漸進、有次序的設計程序、設
計階段的步驟可以重覆循環執行使用、每一設計階段背有的可預見的
進展。現實狀況有時更複雜，尤其是新專案的部份設計常常需要回頭
至最初的設計階段重覆循環執行。

四—6
＜圖表 4-1＞LUCID。
邏輯性的以使用者為中心（導向）的互動式設計方法（Logical User-Centered Interaction Design
Methodology, 簡稱 LUCID），由位於新澤西州、Princeton Junction 的 Cognetics 公司所提出
(Kreitzberg, 1996).。

設計階段 1： Develop product concept 發展產品概念

Create a high concept. 創造『高概念』 。
Establish business objectives. 制定商業目標。
Set up the usability design team. 建立可用性設計團隊。
Identify the user population. 確定使用者。
Identify technical and environmental issues. 確認技術和環境的問題。
Produce a staffing plan, schedule, and budget.
產出人員運用計畫, 時程計畫表, 和預算表。

設計階段 2: Perform research and needs analysis 執行研究和需求分析

Partition the user population into homogeneous segments.
將使用者區隔為不同的市場消費族群。
Break job activities into task units. 把工作活動拆開成為任務單元。
Conduct needs analysis through construction of scenarios and participatory design.
透過情境設計以及參與式設計執行需求分析。
Sketch the process flow for sequences of tasks. 為一序列的任務描繪出程序流程圖。
Identify major objects and structures which will be used in the software interface.
確認將用於軟體界面的主要目的與架構。
Research and resolve technical issues and other constraints.
研究、解決技術問題與其他的限制。

設計階段 3: Design concepts and key-screen prototype

設計為基礎以用戶需要的概念和關鍵螢幕原型
Create specific usability objectives based on user needs.
創造以使用者需求為基礎的特定可用性目標。
Initiate the guidelines and style guide. 開始訂定設計方針和風格指南。
Select a navigational model and a design metaphor. 選擇導引模式與隱喻設計。
Identify the set of key screens: login, home, major processes.
確認關鍵畫面: 登入, 家, 主要過程。
Develop a prototype of the key screens using a rapid prototyping tool.
使用快速原型工具以發展關鍵畫面的原型。
Conduct initial reviews and usability tests. 實施初步訪談與可用性測試。

設計階段 4: Do iterative design and refinement 執行循環式的設計與修正

Expand key-screen prototype into full system.
將關鍵畫面原型擴展至完整的系統設計。
Conduct heuristic and expert reviews. 實施啟發式和專家評估。
Conduct full-scale usability tests. 實施完整的可用性測試。
Deliver prototype and specification. 提出原型和規格。

設計階段 5: Implement software 執行軟體設計

Develop standard practices. 發展出標準化的軟體設計慣例實務。
Manage late stage change. 處理最後階段的修正。
Develop online help, documentation and tutorials. 發展線上輔助, 文件和指南。

設計階段 6: Provide rollout support 提供首次展示的支援

Provide training and assistance. 提供訓練和援助。
Perform logging, evaluation, and maintenance. 執行事件紀錄、評估、和維護。

四—7
Ben Shneiderman 自己在１９８３年研討會的論文中也整理出人機
界面設計的八大設計活動＜圖表 4-2＞，茲表列於下3，設計師可斟琢
採用。

＜圖表 4-2＞人機界面設計的八大設計活動。作者在每一項的後面列出相對應於設計
案的步驟：

1. 設計案開始、收集資訊
決定使用者是誰，即將完成哪些任務
閱讀實務和學術性的文章 (設計原則方針與文獻研究)
設計測試策略(初步實驗)
2. 設計語義架構
定義高階目標和中層次的需求(問題陳述)
設計以使用者為主的作業流程以及關鍵流程的使用情景說明(操作系統分析)
將操作組織成細部執行步驟
創造資料架構的認知模型 (為心智概念模型設計隱喻)
發展操作的認知模型 (為心智概念模型設計隱喻)
與管理階層和顧客取得協議，包括：目標、需要、和語意的設計
3. 設計句法架構
比較與主流設計不同的顯示型態
創造操作的句法(syntax for operations)
設計每一步操作的情報回饋
發展錯誤診斷
準備使用手冊，參考手冊，輔助設備，和教材
檢討與評估設計規格，隨時修正
使用原型模型，執行使用紙筆的初步測試或田野調查
4. 詳細指明使用的設備
選擇軟硬體
選擇聲音，圖象，或者周邊裝置
建立溝通方式的需求
執行進一步的初步實驗
5. 發展軟體
使用現有的對話式管理工具
以實際使用負荷量，進行徹底的軟體測試
6. 整合系統，銷售給使用者
7. 組織使用者團體
8. 準備改進計劃

3Shneiderman, Ben. Human Engineering Management Plan for Interactive systems. IEEE
Computer Society Press, Silver Spring, M.D. 1983. Pp. 230-238.
四—8
 2. LUCID 的設計範疇
作為管理策略，LUCID 為促使以用者為中心的設計更清晰明確，藉由
設計活動、理念傳達、和設計評估，強調了可用性工程（usability
engineering）在軟體研發過程中的角色。在每一個 LUCID 的設計階
段，下列 12 項範疇的設計活動必須加以評估，每一個設計階段都與
時間點緊密結合，並透過設計評估提供即時回饋：

1. 產品定義：為經理人員和市場行銷人員建立『高層概念』

2. 商業考慮：價格、期望利潤、在投資上的回報、競爭

3. 資源：持續時間、工作層次、團隊成員、備用計畫

4. 硬體物理上的環境：人體工學、物理建構、溝通臺詞

5. 技術環境：用以研發與整合的硬體與軟體

6. 使用者：跨社區性的訪談，使用者測試，行銷

7. 功能性：為使用者提供的服務

8. 原型：初期紙上作業原型、關鍵螢幕原型、可運作的原型

9. 可用性：訂出可測量的目標、執行測試、修正界面和設計目標

10. 設計方針：現存方針的修正、評估程序的執行

11. 文件的內容：文字、聲音、和影像資料版權的檢視與取得

12. 文件、訓練和協助：規格, 發展, 和測試的文件，錄影帶、和

四—9
 線上的版本。

新界面的設計程序
作者根據文獻整理以及初步實驗的經驗，在 1994 年的碩士畢業論文
中，以學術論文格式的觀點，提出了一個新界面的設計程序＜圖４–3
＞。核心路徑由六項步驟組成：背景研究，文獻探討，初步實驗，架

構設計，設計執行，和軟硬體的提案。此六項步驟相對於學術論文格
式為第一章介紹及背景研究〈包括問題、假設與限制〉
，第二章設計原
則、方針與文獻探討〈包括快速原型、初步實驗〉
，第三章設計程序與
文獻探討，第四章設計架構與執行〈包括實驗評估、介面修正、與結
＜圖４–3＞與論文格式呼應的介面設計程序。作者於碩士畢業論文 An Innovative
Interface Design - Home Entertainment Systems 中提出。1994。

Conventional system study

Background Study Problem statement

Introduced
Optional solutions study
in Chapter
I and II
Design principles and guidelines

Literature Reviews Methodologies

Establishment of new design model

Pilot Study 2.7 Revision of new model

4.1 Task analysis

4.2 Assigned tasks and design approaches

Structure Design
4.3 Operational system analysis and design

4.4 Structural path development

4.5 Semantic Structure Design

1) Design user-oriented task flow and
scenarios for critical tasks
2) Design metaphors for the conceptual model
3) Develop cognitive mode of operations
Design 4) Design syntactic structure
implementation
4.6 Create syntax for operations
1) Design informative feedback for each
operation
2) Develop error diagnostics, help facilities, and
tutorials.
3) Review and evaluate design specifications and
revise where necessary.

Hardware and software

proposals
四—10
論〉。學術界也可以參考此格式的設計程序，進行調整採用。

四—11
本章以下八節闡述介面設計程序，綜合各文獻資料及作者本身實務經

驗，將介面設計程序以符合工業設計及視覺傳達設計師專業的觀點，
分為八大設計階段，並佐以實務的設計案例。此八大介面設計階段包
括發展產品概念、執行研究與需求分析、任務分析與架構路徑、構想
發展、建立原型、進行細部設計、評估測試、產品發表與提供支援，
茲分述如下：

第二節 設計階段一：發展產品概念
一開始，設計者必須設定使用者對於一個特定界面的需
求。相關知識與設計者的創造、操作界面的主軸的概念將
被發展出來。同時，它也描繪出界面的目的以及達到此目
的方法〈Philips IMS 4〉。

令人驚訝的是，業界開始進行介面軟體開發時，竟然為數不少的產品
概念仍未清楚成形。一般估計軟體研發失敗率高達百分之 60，而有大
約百分之 25 的專案從未完成，而百分之 35 僅僅達成部分目標5。此
問題的原因大多可歸咎於在研發初期缺乏對設計議題的注意。若在軟
體發展早期便能謹慎的付出心力於以使用者用為中心的設計，便可以
縮短研發時間、減少成本。

在產品概念階段，專案領導者定義商業目標、建立設計團隊、確立環
境與技術或法律上的限制、準備專案計畫和預算。以下為兩大工作事
項﹕

4Philips IMS. The CD-I Design handbook. Addison-Wesley publishing company. 1992.
Pp. 64. 此為Philips IMS替互動式光碟光碟CD-I建議三個實務設計階段之第一步驟。這些步驟也
可以應用於圖形使用者界面的設計。
5 Shneiderman, Ben. Designing the User Interface: Strategies for Effective
Human-Computer Interaction. Addison Wesley Longman, Inc.. 1998.
四—12
 第一項 定義使用者、決定產品功能
雖然在第二階段將會對使用者有進一步的研究，但在第一階段的最初
時，便必須透過文件、會議，將使用者簡短地描述出來，也就是決定
目標使用者是誰。其次，產品的目標、功能、特點，可以達成哪些任
務，也必須同時被定義出來

介面設計師可以在此初步階段提供貢獻。可以運用市場區隔板、或情
境版等圖示工具，加上圖片以刺激團隊的發想＜圖４–4＞。以下是使用
者定義的範例﹕

＜圖４–4＞LCD 液晶顯示器畫質調整介面設計：使用市場區隔板描述目標使用者的
背景、介面操作習性。作者，2001 年。

當由行銷企劃人員主控時，可能會提出初步的、文字形式的企劃書。
以下是產品定義的範例﹕

● 產品目標、功能、特點 ●
四—13
 新型的家庭銀行系統將為顧客提供帳戶的統一窗口。它支援
收支平衡餘額查詢、信用帳戶與貸款的管理、不同帳戶之間
的轉帳、電子帳單的支付、和共同基金的投資。此外，系統
將為顧客提供年終稅務運算。

在第一階段時，部分團隊甚至會要求工業設計單位配合提出簡略的
產品概念構想〈圖 4-5，圖 4-6〉，呈現方式可能是簡單的草圖、相
關圖片（可能以裱板或螢幕顯示、投影的形式）。 這些概念構想草
圖的目標是要把系統概念傳達給專案參與人員，以增強共識、或提
供討論的共通平臺。

第二項訂定需求事項／工作方針
在設計程序之初始階段，界面設計師應該提出一套工作方針。兩個人
一齊工作一星期可能可以產生出 10 頁的文件，若一打人可能可以提
出 300 頁的文件。 蘋果公司的麥金塔電腦成功的部分要件在於一開
始便訂下清楚明確的設計方針文件，提供給軟體開發工程師去遵循，
因而可以在介面設計中確保協調一致的設計6。

雖然不同的專案都有不同的需求，但是設計方針應該加以審慎的訂
定出來，設計師可以參考下列設計方針必須規定的事項7﹕

文字與圖像（icons）
用詞 (目的和行動) , 縮寫, 和標題
符號集, 字型, 字型大小, 和字型格式 (粗體, 斜體, 加底線)

6 Shneiderman, Ben. Designing the User Interface: Strategies for Effective

Human-Computer Interaction. Addison Wesley Longman, Inc.. 1998.
7 Shneiderman, Ben. Designing the User Interface: Strategies for Effective
Human-Computer Interaction. Addison Wesley Longman, Inc.. 1998.
四—14
 圖像 , 圖形, 和線寬
顏色, 背景, 強調部份, 和閃滅的使用。

螢幕顯示編排的議題﹕
選單的選擇, 填充表格、和對話框的格式

＜圖４–5＞工業設計單位所提出的初步產品概念構想，以刺激團隊成員充分討論的
共通平臺。作者繪，達創電子，2002。

＜圖４–6＞音響遙控器介面初步概念構想。長庚大學，蔡承諭，2001。

四—15
 提示, 回饋, 和錯誤訊息
確認、空白 、和邊界大小
項目和列表的資料輸入與顯示格式
頁首和頁尾的格式。

輸入和輸出的設備
鍵盤、顯示、游標控制、和指向的裝置
聲音, 聲音回饋, 觸控式的輸入, 以及其他的特殊輸入模式
或者設備
執行不同操作的回應時間
操作程序
直接操作的敲擊、拖拉、拖放、與動作
指令的上下文、語意、操作程序
可程式化的功能鍵
錯誤處理與和回復程序。

方針的訂立應該是組織內互相尋求共識的社會化的溝通過程。引起爭
議的方針 (例如：功能鍵的定義、使用聲音警示的時間點…) 應該由
同事之間討論或者進行實驗來決定。下列工作的程序應該制定下來﹕
發行方針文件的程序，確認執行的程序，例外允許的程序，和修改許
可的程序。方針文件應該是可變可調的「活」文件，可配合需求的變
更、以及隨著經驗的累積而調整。藉由評估哪項方針是不可變的標準、
確立在實務上哪項方針較為可行、與分辨出哪項方針可以有較靈活的
運用，如此便可以釐清了哪項方針較重要，哪些項目較可以妥協。

四—16
在執行專案之初，方針文件的提出應該把焦點集中於界面設計上的注
意事項，並提供團隊互相討論爭議性議題的機會。當開發團隊取得共
識而採用共通的方針時，設計執行便可以加速進行，設計變更也得以
減少。

第三節 設計階段二 : 執行研究與需求分析

第一項 使用者的不同
介面規劃者必須認知：就如同人體計測學中沒有”平均人”一樣，產品
的使用者也沒有”典型使用者”的存在。每個人都有其獨特的技巧與限
制，因而產生了不同的行為與產品使用模式8。一般而言，產品必須
針對各種不同能力的使用者設計，而使其能安全而有效率地使用。

在設計過程中，須考慮的使用者差異事項如下：

1. 人體計測學及生物力學上的不同：如身體尺寸、靜態及動態的力
量，運動技巧等。

2. 不同的知覺能力：如視力與聽力。

3. 不同的認知能力：如短期及長期記憶、空間及序列處理的技巧、
學習能力等。

4. 不同的情緒屬性：如憂慮的程度、挫折的容忍度、以及對地位/
認可的需求。

8 Cushman, William H.,著。蔡登傳，宋同正譯。Human Factors in Product Design. 產品設計

的人因工程。六合出版社。八十五年八月。
四—17
當專案計畫就緒後，設計團隊可以開始拜訪使用者以瞭解他們的需
求及能力，支援的商業程序，和系統的功能需求。團隊領導人可以
決定是否要採用參與式的設計會議，以徵求用戶的意見、建立起操
作流程的情境說明、和定義核心的設計目的。

第二項 人類學的觀察
人類學的方法已經應用於辦公室工作觀察、空氣-交通管制、和其他的
領域。大部分人類學觀察（Ethnographic Observation）的初期步驟
包括對使用者的觀察。因為界面使用者大多形成特殊的文化，在工作
場地裡以人類學的觀察方式進行研究就變得越來越重要。作為一個人
類學者，以公開地或者隱匿的方式，從個體行為到組織環境裏進行廣
泛地研究，他們長時間的沈浸其中，以洞察人們的日常生活：比如紀
錄人們發生的事情、聽別人說了什麼事情、人們問了哪些問題。

界面設計師雖然可以移植人類學的方法，但是不同於傳統的人類學者
之處在於：除了理解他們的觀察對象外，他們同時也觀察界面，以作
為改進界面之用。此外，傳統的人類學者花上數週或者數月的時間，
把自己融入當地文化中；而使用者界面設計師必需要讓此過程局限於
數日或者甚至數小時中，以獲得重新設計介面所需要的有關資料。

人類學觀察常常被誤用，導致於妨礙專案的執行、忽略重要資訊。依
循下列正確的人類學程序可以減少這些問題發生的可能性9﹕

準備
了解組織政策（規定）和工作文化。

9 Shneiderman, Ben. Designing the User Interface: Strategies for Effective

Human-Computer Interaction. Addison Wesley Longman, Inc.. 1998.
四—18
 熟悉系統與其歷史。

設定初始目標和準備問題

獲得受觀察者或受訪者的允許。

田野調查
建立與經理人員和使用者的情誼。

在工作場所觀察或者訪問使用者，搜集主觀與客觀的定量、
定性的資料。

追查任何從訪問中得到的線索。

把訪談記錄下來。

分析
將收集的資料轉化成數字、文字、和多媒體的資料庫。

量化資料和編輯統計資料。

減少資料量和解釋資料。

修正目標與使用的程序

報告
考慮不同的聽眾和目標。

準備報告和發表研究成果。

四—19
以上程序雖然看起來簡單易行，但在不同的情況裏則需要不同的解讀
與不同的注意。例如，瞭解到經理人員和使用者對於於目前使用界面
的效率有著不同看法，如此將會提醒設計師去探尋每一群體不同的挫
折來源。例如，管理人員可能會抱怨下屬不願意去更新資訊，但是實
情是：下屬也許不想使用這界面，原因只是在於登入過程極為耗時。

當準備觀察之前，了解組織規定和工作文化是非常重要的。比如訪談
之前，經理事先來電提出善意的忠告：由於該公司禁止在工作場所內
穿著牛仔褲，建議提醒研究生穿著要依照規定。此外，學習目標使用
者常用的術語是建立交情的第一步。而針對目標、將一長串的問題過
濾出來，然後把焦點集中於此是很有用的。另外，瞭解不同團體的使
用者的差別，將幫助使觀察和訪談的過程更有效率。

資料收集可以包括定性的資料﹕各式各樣的主觀印象、或者主觀的反
應，可由定量的分析法如尺度表或評比中搜集而來。客觀資料可以包
括使用者的經歷：比如定性的軼事或關鍵事件，或者可能是定量分析
的報告。例如：六個受測者在一小時的觀察期間內出現的錯誤的數目。
此外，提早決定要獲得什麼可用的資料是重要的步驟。但是在執行的
過程中，對未預期的狀況的也保持警覺。在大部分的情況下，每個訪
談的初稿抄本太多，在分析之前是沒有多大用處的。因此，以文字呈
現的報告概要是有其必要的。

將人類學程序深思熟慮地精心策畫、而具體化，經過證明有其優點：
因為藉由訪問工作地點、設計者對組織的複雜性將會有第一手的瞭
解，因而能夠增加信賴、加強可信度。親自到現場讓設計師得以與使
用者建立工作關係，互相討論構想、最重要的是，使用者可能扮演新
界面設計中的積極參與的角色。
四—20
 第三項 參與式的設計
參與式的設計在許多方面是具有爭議性的。許多專家提倡參與式的設
計策略，他們最喜歡的論點是：讓更多使用者介入可以得到更精確的
資訊、為使用者提供一個影響設計決策的機會、參與感讓使用者投入

而加強接受度而增加最後成功的機率10。

另一方面反對的意見則是：擴大使用者的介入也許比較昂貴、可能讓
執行時期延長、與被排除在外或提出意見被拒絕的使用者產生敵對關
係、設計者也可能為了滿足參與者的不適當要求而損害了原設計而適
得其反。

參與式設計的實驗通常獲致正面的結果，而且為其辯護者通常能夠指
出許多若不是參與式設計則會錯失的貢獻。參與式設計擁護者喜愛
PICTIVE 法（英文全名為﹕Plastic Interface for Collaborative
Technology Initiatives Through Video Exploration，中譯即是「藉由
錄影探索法而為協同技術設計的可塑性介面」）這是正式的、多重個
案研究的方法，使用者親自畫出介面草圖、然後使用便條紙、塑膠片、
膠帶創造出非常粗略的草模原型。然後主導者將情境錄影下來、展示
給經理人員、使用者、或其他設計師。若有正確的導引，PICTIVE 能
夠有效地激發出新構想，提供參與者極有意義的樂趣。

小心選擇使用者，如此則有助於創造成功的參與式設計體驗。若安排
挑選使用者的活動（選拔會）則可以增進參與者認知到此活動的重要
性、和強調此專案計劃的嚴肅性。參與者可能將被要求參加一再重複

10 Shneiderman, Ben. Designing the User Interface: Strategies for Effective

Human-Computer Interaction. Addison Wesley Longman, Inc.. 1998.
四—21
的會議、和被告知關於他們所扮演的角色、以及他們的影響的被期望
的事項。他們可能必須瞭解組織所使用的技術、與組織的商務計畫，
和充當他們所代表的更廣大的使用者的溝通管道。

隱藏在參與式設計的難題是：圍繞在複雜界面設計過程中的的社會、
政治環境並不會完全按照嚴格定義的方法或控制下的實驗去運行。 社
會和工業心理學家對這些問題極感興趣，但是，可以充分倚賴的研究
和執行策略也許從未出現。敏感性強的專案領導者必須依靠自己的判
斷、必須決定使用者在不同的狀況裏必須介入到什麼程度。設計團隊
成員和使用者的組成佔有決定性的重要因素，因此納入群體互動和社
會心理學專家作為顧問是非常有用的。

經驗豐富的使用者界面設計師知道：組織政治和個人的好惡選擇也許
比控制互動式系統的技術問題更為重要。舉例如下﹕由於新導入的互
動式物料採購系統在電腦螢幕前提供上層主管即時的最新的資訊，採
購催料管理人員可能意識到自己的職位正遭受威脅，因而延遲資料的
輸入、或意興闌珊而使得資料精確度受到影響。界面設計者應該重視
使用者的影響，及早去除參與者所有無謂的擔心、以避免招致反效果
和改變的阻力。新事物對許多人造成威脅，所以清楚的告知未來改變
之後期望的結果將會如何便有助於減少參與者不必要的焦慮。

四—22
 第四節 設計階段三﹕任務分析與架構路徑

第一項 任務分析
任務分析(task analysis) 的目的在於完整的瞭解使用者的需求，用以
收集使用者所需執行的所有任務(作業)。為了在設計過程中專注於使
用者的需求，以使用者相關的議題為中心，而不是以技術上的考量為
主，故作業分析強調的是使用者需要『什麼』功能，而不是強調『如
何』去提供這些功能。

任務分析應該是表列式的，把所有可能的功能都詳盡的用文字列出〈可
用圖片輔助，但是也可使用純文字〉
，然後做簡單的分類。任務分析可
以幫助設計師全盤的掌握介面的所有功能、所有可能。在構想發展之
前，團隊成員將介面的所有功能條列出、依重要程度考量、依群組作
初步的分類，或可以幫助團隊成員對整個操作過程有較全盤的掌握，
也可以刺激團隊成員找出設計的重點。同時也可以避免設計執行接近
完成時，竟然發現當時團隊成員沒有考慮到的可能操作任務，而這種
可能竟然在其他非參與人員眼中是顯而易見的。

任務分析不是用途分析。工業設計師傳統所擅長的用途說明、使用情
境、或功能解說都可以拿來輔助，但是這些大多是產品定義階段，或
最終構想決定了，工業設計師用來說明或推銷自己的構想的工具，而
非一開始構想還未成形、甚至產品能做什麼都還沒確定時所做的任務
分析與架構路徑發展。

以家庭娛樂系統為例：根據使用頻率，控制家庭娛樂系統的操作程序
可以分成三個群組- 常用群組、中度使用群組、和罕用群組。
〈圖表
四—23
4-7〉表列出三個群組的操作細節分析：(部分較次要的操作細節已省
略列出)。此分類可以運用於初步實驗中的雛形，進一步產生界面的基
〈圖表 4-8〉則提供了另
本架構，或根據初步實驗的結果，加以修正。
一個範例：智慧型洗衣機介面任務分析。

〈圖表 4-7〉家庭娛樂系統的操作細節分析。

1 基本群組

1) 開／關控制

2) 選項選擇：電視、卡式錄放影機、光碟機、錄音帶、收音機

在這個選項選擇，使用者能夠選擇他們想要操作的裝置。在選擇以後，所選的設
備自動開啟，而保持先前關機前的設定或原廠設定

2 中度使用群組

1) 電視

1] 頻道/選擇，顯示。

2] 音量/ 調整，靜音。

3] 操作順序指示，"回主選單" 按鈕。

2) 錄放影機：略 3)光碟：略 4)卡帶：略 5)收音機：略

3 罕用群組

1) 錄

1]調整日曆和時鐘 2]輸出選擇 3]輸入選擇 4]調整時計

2) 調整

1] 電視： 音質，亮度，對比，對焦，水平垂直控制

2] 卡式錄放影機：Hi-Fi 調整，頻道選擇，搜尋

以下略…

3) 聲音：略

四—24
〈圖表 4-8〉智慧型洗衣機介面任務分析。台灣科技大學，闕敏原。

以一般家庭所會用到的功能，區分為六大類。第一為洗衣，第二為放水量，第三衣服
種類，第四為脫水，第五為預約，第六為網路設定。其他按鍵為電源和其它指示燈。

主選單 一般、進階

洗衣 開始、進階

放水量 低水量、中水量、高水量

衣服總類 一般、貼身衣物、厚重衣物、絲綢(麻)衣物
選項
脫水 弱、中、強

預約洗衣 幾月、幾日、幾點、幾分

網路設定 連線、斷線、設定密碼

操作分析和設計
操作系統分析不是單獨存在的關鍵步驟，卻可以用以輔助任務分析，
對操作的特性作對更深入的探討。在此表列式的工具裡，操作任務、
操作與建議的操作次序、指定的操作、設計元素、與可能的回饋一一
被仔細的詳列出來。其中『操作與建議的操作次序』即代表著操作的
文法，也是同一任務裡，每一操作被執行的步驟。右邊列出的『設計
元素』可以列出表達每一操作的圖像或文字的使用，或可能的代表元
素。最後『可能的回饋』可以列出在每一操作執行之後，介面將會產
生何種變化，或顯示出任何回應以告之使用者。雖然回饋的選擇已經
牽涉到細部的進一部設計，但是在此階段便作初步的思考則有助於之
後對介面的整體的掌握。

接續上述家庭娛樂系統的例子：依據操作的特性，這些委派的操作任
〈圖表 4-9〉顯示了必要的設計元素、
務被分成兩個群組：名詞和動詞。

四—25
〈圖表 4-9〉操作分析：必要的設計元素、回饋設計、以及指定的操作。家庭娛樂
系統。

操作任務 操作與建議 指定的操作 設計元素 回饋

的操作次序

Selecting 1. Start the Select the Two I Turn to next

Verb operation function button of overlap + "Recording"
(To of recording squares T pages
accomplish recording + arrow
a certain + text
operation)

Selecting 2. Select Click on the number T 1. The chosen

Noun the displayed number is
(Objects) memory memory storage highlighted
storage number
number 2. The
number in the
column
changes

Selecting 3. Adjust Click the Two S The number in

Verb (To the dates, up-arrow and arrow the time
accomplish hours, and down-arrow to symbols column
a certain minutes, adjust the changes
operation) numbers

Selecting 4. Select Click on the "TV", TV, CD, I The chosen

Noun the "CD', or "Stereo" and item is
(Objects) recording button stereo + highlighted
resource icons
T

Selecting 5. Select Click the Two S The number in

Noun the up-arrow and arrow the channel
(Objects) channel to down-arrow to symbols column is
be adjust the changed
recorded numbers

Selecting 6. Adjust
Noun the VCR
(Objects) mode

7. Confirm Click the "OK?" Text T Message from

the button "OK?" the
previous information
operations board on the
screen

Request Click the "Help" Questio S Turn to next

more button n Mark + "Help" pages
information + text T
about the
operation

T:文字 S:象徵 I:Icon G:圖案影像

回饋設計、以及指定的操作。

四—26
 階層式任務分析
通用階層式任務分析(Generic Hierarchical Task Analysis，縮寫 HTA)
及其混合形式為多數業界所使用11。HTA 以圖表顯示事件及其反應，
適合處理階層式的計劃(Hierarchical Planning)，可以用在工業工程的
作業分析、也適合用於介面設計裡更詳細地描述使用者的操作內容與
次序。HTA 的分析方式為：將大任務拆解成次作業，一一編號。然後
以階層式樹狀結構的方式，由次作業構成主任務。描述計劃(Plan)是
使用編號數字來標示其組合內容及次序，如〈圖表 4-10〉所示。

〈圖表 4-10〉
一個 HTA 的一部份，此例描述在 Microsoft Word 中，如何移動一個文字區
塊。

4.2 移動一個文字區塊

計劃 4.2 1-2-3-4

1 選定文 2 選擇『剪下 3 將游標 4 選擇『貼上

字區塊。 (cut)』(功能表 移至所要 (paste)』(功能表
項目) 。 插入文字 項目)以插入區
的地方。 塊。

11
Preece, Jenny. A Guide to Usability - Human Factors in Computing. Addison Wesley. 1993.
人機介面與互動入門-電腦之人因工程。陳建豪譯。何碩科技出版。1998。
四—27
 第二項 架構路徑發展
架構路徑發展承續任務分析的結果，設計以使用者為主的作業流程以
及關鍵流程的操作分析，進一步地將使用者所需執行的任務(作業)作
更詳細的規劃，組織成細部執行步驟。架構路徑將重點放在操作的次
序，此次序即是執行任務的路徑。架構路徑應該是樹形圖式的，把使
用者所有可能的操作路徑用方格詳盡的列出，然後用具有方向性的線
條加上箭頭連結起來。

在此步驟裡，設計團隊成員首次觸及使用者心智模型的議題。架構路
徑可以幫助設計師進一步掌握介面操作的所有可能次序，也可以讓團
隊成員開始對使用者的心智模型作初步的探討、模擬。在建構心智路
徑的過程中，團隊成員應該仔細地參考本書的資料，包括第二章所提
供的心理學相關知識：人類資訊處理、記憶、學習、預設用途、使用
限制、可見性、配對，以及第三章所提供的介面設計方針：回饋設計、
互動對談原則、對話形式的選擇、以及實務性的指導方針。

在人與人的溝通裡，通常我們有好幾個方式來表達同一個想法或提出
同一個問題。在介面互動的過程裡，由於使用者的思考與經驗的不同，
也導致每個獨立的個體的操作路徑也會有不同的呈現。故架構操作路
徑時，應當特別注意第二章所提及的靈活系統。此靈活系統允許使用
者不同的思考模式、提供不同的指令路徑，讓使用者完成同一項任務。

延續以上所舉例的家庭影音介面設計案：修正家庭影音設備的操作程
序之後，界面的基本架構可以分成兩個主要群組 - 基本操作和進階操
作〈圖 4-11〉
。此外，在此範例裡，架構的靈活性已經加以設計：當
使用者並不『遵照』主路徑操作時，次路徑〈Alternative path，
『旁門
左道』或甚至是捷徑〉應當被認真的考慮、引導。讀者可以同時參考
四—28
KIOSK 圖形操作介面設計的架構路徑發展〈圖 4-12〉
，以及兒童通訊
產品的架構路徑圖〈圖 4-13〉。

四—29
〈圖 4-11〉 描繪出〝錄畫〞的細節操作架構。其中加入了其他相同的目的但不同的操
作路徑。

TV C ontrol
Main men u Panel

Advanced Basic
Operati on Operati on Alter nati ve path
VCR
Control
Panel

Setting
Recor ding
Pop-up m enu

Storag e Memor y
Memor y inform ation stor age Confirm
stor age display selec tion
selec tion

"On" tim e "Off" time Confirm

Timer input
setup input

TV Chann el
Sour ce Confirm
selection selection

Radi o

CD Mode Confirm
VCR selection

Reco rder Tap e

selection

Confirm

〈圖 4-12〉KIOSK 圖形操作介面設計：路徑架構與操作流程。台灣科技大學，黃賜濱。

四—30
四—31
〈圖 4-13〉兒童通訊產品的架構路徑圖。台灣科技大學，黃昱仁。

四—32
 第五節 設計階段四：構想發展
設計階段四進行構想發展，與傳統設計程序相同之處在於創意的發想
仍然遵照發散〈廣度〉與收斂〈深度〉的過程，不同之處則在於：界
面是動態的，故『時間』要素的加入，所以必須有腳本、故事板、介
面模擬等具有控制時間變數的設計工具。此外，構想發展時則更為慎
重的考慮操作介面時的文法〈即執行任務時的次序〉
、更深入探討人機
互動的引導、以及更為嚴謹的創造及檢驗視覺元素的代表語意。

第一項 〈圖 4-14〉Philips 公司的介面構想草圖。

語意設
計和句
法架構

語意設計
接續於任務分析
與架構路徑之
後，設計師開始
進行語意設計的
構想發展。此階
段包括：創造路
徑架構的認知模
型、發展操作的
認知模型、為心
智概念模型設計
隱喻。與此並進
的是，設計師必
須與管理階層或

四—33
顧客保持良好的溝通，溝通事項包括：設計的目標、使用者的需求、
和語意的設計。設計團隊應反覆檢驗上述事項是否取得共識，雙方對
於共識的內容是否有一致的認知。

發展出適切的隱喻是一件具有挑戰性的工作。其重點在於時間的壓力
之下，如何利用創意設計，如何排除主觀認定、以選出合適的構想。
先前第二章的『在使用者介面中使用隱喻』已談到：語意的創造過程
與完整的工業設計程序基本上無異。首先必須了解前後的架構、介面
的環境、以及使用者的背景。設計階段三的『任務分析與架構路徑』
即提供一個全盤了解使用者的程序。其次進行語意的構想發展、修正
〈參見圖 4-15〉，這過程可以包括發散〈廣度〉與收斂〈深度〉的過
程，也就是在構想先期，設計師必須被要求提供出一定數量的構想後
才能進行評估，此時應著重於構想方向的創意、廣度、不同方向的發
想，強調量、較不強調質。如此可避免設計師一開始便一廂情願的主
觀認定最初的構想已達到滿意的水準，而不願意再進一步探索其它的

圖 4-15 創意的發想：發散〈廣度〉與收斂〈深度〉的過程

四—34
可能性。其次將為數眾多的廣度構想經過評估、篩選之後，選擇具代
表性、策略性的構想初胚作進一步的深度發展，將之合併、變形轉化。
在此收斂階段則著重於深度，強調質，較不強調量。也就是注重構想
的合理性、問題解決的邏輯思考。

讀者可以同時參考本書第二章隱喻的發想輔助表格＜圖 2-11＞，設計
師可以使用腦力激盪的方式，快速的想出可能使用的語意（用簡短的
文字來表達）
、圖案，填入隱喻的欄位裡。其它兩欄則讓設計師把隱喻
細節的描述與意圖表達的意義寫下來，有助於設計師在心中釐清想要
表達的內容。

實例：接續前述家庭影音介面設計案，經過先前的初步實驗及隱喻的
構想發展，選出了架構界面的主要隱喻：
『三個遙控器面板』
，包括一
般操控 (固定於螢幕上方)、基本操控及進階操控 (浮動的、螢幕下方、
升起後內含更多細節)。 〈圖 4-16〉架構界面的主要隱喻：〝三個遙控
〈圖 4-16〉說明了這個 器面板〞
概念。在層次概念中強
調下列三個觀念： Recording

1. 根據使用的頻率， Memory
storage
selection

將功能按鈕分成兩 Timer
setup

個群組：基本、進 Source
selection

階的操作控制面 Path indication--

from top to bottom,
from left to right

板，以提供層次分
Recorder
selection

明的操作分類。 Confirm

2. 當游標靠近面板

四—35
 時，面板便升 〈圖 4-17〉家庭影音介面的句法架構設計。

起以顯露操作
Main

的細節。 General control

Basic
control panel Advanced
(Home) control panel

3. 跳出式對話框 Hierarchy 1.
Click on the Title/ Contents
Basic
operational
提供更進階的 control panel,
and the panel
rises up. Click on the Advanced operational
Hierarchy 2.
Detailed operation
indicates that control panel, and the panel rises up.
one This indicates that one man-machine
man-machine conversational sentence begins.
操作的細節。 conversational
sentence
begins.

句法架構 Operational
area
(Elevating
menu)
Operationa
area
(Elevating
在語意設計的同 menu
Hierarchy 2.
Detailed operation

Hierarchy 3.
Basic operational
時，句法架構設計也 control panel
(Home)
More spicific details of operation

被設計出來。句法、 Pop-up menu

語法(syntax) 在電 Pop-up menu

Operational
aera

腦術語的意義即
是：指字元或字元組
之間的關係。而在人 〈圖 4-18〉XX 公司的遙控器介面的句法架構設計。

類的語言裡的意義
即是：規定一套語法
範疇(如名詞短語和
句子)的規則，或是
文法。語意設計是詞
彙的創造，而句法架
構設計即是文法的
訂定，也就是創造操
作的句法(syntax for operations)：其中包括決定互動的先後次序、創
造引導使用者的語意或隱喻、設計每一步操作的回饋。

四—36
實例：接續前述家庭影音介面設計案，最終設計內含的語義架構 (圖
4-7)，主要根據下述兩項方針：

1. 句子架構的一致性：句子架構的文法方向是從左至右，從上而下
(圖 4-17)。

2. 隱喻：地圖上的路徑 (前圖 4-16)。控制面板就像地圖一樣，顯示

操作的路徑。設計方針為下列二項： 1) 錄影指令全部位於在同一頁。
2) 地圖路徑的隱喻展示出操作的 "文法"。

讀者也可以參考〈圖 4-18〉的句法架構設計範例。

第二項 使用構想輔助工具

設計核心路徑
從設計過程的開始到結束，設計者應該精確的控制概念及構想。與
傳統的設計草圖不同的是，介面輔助設計工具可使用構想流程圖、
和〈數位〉故事板12，以用於輔助發展和評價構想，控制設計核心

〈圖 4-19〉使用設計工具

Develop electronic
storyboard within
authoring
environment

Design Produce Load images

sketch electronic Verify into Test
storyboard storyboard structure application application

Critical path

Capture images
for program
simulations

12Philips IMS. The CD-I Design handbook. Addison-Wesley publishing company. 1992.
Pp. 64.
四—37
路徑〈圖 4-19〉。這幾種設計 〈圖 4-20〉介面構想流程圖。

輔助工具敘述如下：

構想流程圖
設計階段三的任務分析與架
構路徑有助於設計師全盤的
掌握介面的所有功能、所有
操作可能。而構想流程圖則
以上述的架構為基礎，在紙
上快速的描繪出介面設計案
的樹形圖架構，加以變形轉
換、考慮達成同一架構的不
同可能方法，期能創造出突
破性的構想〈圖 4-20〉。此構
想流程圖適合在團隊小組成員內部之間討論、溝通、或甚至腦力激盪。
但若要對外發表，仍須轉換成較正式、較深思熟慮之後的格式，比如
架構路徑的形式。

故事板(storyboards)
故事板是將介面內容與互動方式，加入時間的要素，以視覺化，動態
的形式，具體簡單呈現出來的最佳工具13。故事板應該描述介面模擬
操作的所有步驟、每一操作的簡短描述、操作細節、草圖、或回饋。

13 Kemp, Jerrold E. and Smellie, Don C. 教學媒醴的企劃、製作與運用。譯自：Planning,

producing, and using instructional media, 6th ed. 中國視聽教育學會主編．民83

四—38
介面設計使用的故事板概念來自於電影公司的分鏡故事板 (圖 4
-21 )。分鏡故事板是攝影、美工設計、錄音、錄影等工作的說明和依
據。分鏡故事板須針對每一畫面做詳述或描繪包括場景說明、鏡頭安

〈圖 4-21〉電影公司的分鏡故事板範例。

四—39
排，並附上旁白及音效 〈圖 4-22〉Philips 公司的使用情境構想故事板。
說明。每一畫面都寫明
主題的大小，例如遠
景，中景，特寫等。場
景的拍攝鏡頭亦被標
明出來，如仰角、俯角
等。

界面的構想故事板則
承續電影分鏡的精
神，在設計案發展期
間，故事板將會修正成
幾個版本〈圖 4-22〉。
在開始的時候，它是大
略的、一般性描述的、
一連串的草稿和草
圖，目的在給人們對設
描述家庭娛樂系統的遙控器介面的構想故事板。
計案的內容及風格有
一個概括的想法和了
1 2
解。經由檢討、回饋、 Main Menu VCR
TV TV
VCR VCR
和修正的過程，故事板 Stereo Stereo
CD CD

在最後則會加入更多
Phase 1) Commonly-Used Phase Phase 1) Commonly-Used Phase
1. On/Off control 1. On/Off control
2. Volume control
的細節。 2. Volume control
3. Menu selection: TV, VCR, CD, TAPE,
RADIO.
In this selection, Users can select the devices
3. Menu selection: TV, VCR, CD, TAPE,
RADIO.
In this selection, Users can select the
which they want to operate. If no further devices which they want to operate. If no
operations, the device will be turned on and further operations, the device will be turned
statues remain the same as before( or internal on and all statues remain the same as
set status). before( or internal set status).
Design description Design description
In every key button of A-V system, two

最初階段，故事板也可
以做成 3X5 吋卡片的

四—40
格式，或使用背膠的自黏貼紙，將每一個操作行為寫下，畫出草稿和
草圖，用膠帶或圖釘固定在牆上。依此方式製作出其他的卡片，以有
次序的排列，一一固定在牆上。在此階段，可以使用腦力激盪的方式，
列出所有相關的故事板，不考慮前後關係、或刪減的問題。也可用不
同的顏色來幫助分類、辨認。使用此方式的好處是由於故事卡是畫在
單張卡片上的，可以隨時更動位置，也可輕易的增添或刪減內容。需
再強調的是，盡量列出所有相關的例子、事實、地點、注意事項等，
愈多愈好。等下個步驟真正進行編排故事卡時，刪減多餘的內容總比
增添容易。

在此構想發展進行的後期，內容大致底定後，便可邀請專家、同事、
經理、或決策人員針對視覺化的表現及介面的組織架構、連續性等問
題提出意見，或有助於發現某個過程是否遺漏了畫面，或有些地方需
要重新編排。

第六節 設計階段五：建立原型
設計互動式介面時的困難點是：專案經理和使用者可能沒有足夠的知
識與經驗去想像最終介面完成時看起來將會如何，也無法思考一些設
計上的決策及其產生的結果。此外，因為互動式介面在許多情況下是
全新的設計，管理階層、使用者不易瞭解到設計決策時所考慮的層面。
而當主系統已接近完成時，若任何主事者有強烈的意見，或測試上有
重大明顯的瑕疵，此時再進行設計變更將會非常困難、昂貴、和耗時。
在傳統設計教育方面，學生對於操作介面是否真的如所陳述的可行，
大多顯示出信心不足的態度，其原因也是傳統設計程序裡並不安排介
面的互動模擬。
四—41
因此，在設計程序裡加入原型設計的步驟便可以克服上述的問題。原
型可以模擬最後系統的在現實世界呈現出的樣貌，讓管理階層、使用
者與類似於真實的系統進行互動，他們便可以參與討論、提供意見。

第一項 原型的定義及種類
介面原型(Interface Prototype)是一個軟體系統，它顯示介面的組織架
構、操作功能、互動運作，模擬系統最後顯現出的樣貌。它實際上可
以運作，換句話說，它不只是概念或圖畫。原型大致上並無一定的『生
命期限』
：一方面它可能在用過以後立即丟棄；另一方面它也有可能逐
漸『演化』為最終的系統。一個原型應該是以非常低的成本來創造，
也應以很短的時間來發展，為了強調這點，有些作者以『快速原型
(rapid prototype)』或『拋棄式原型(throw-it-away prototype)』來稱呼
14
。

建立原型是一種高度的『參與式的設計』的工具，運用此種設計工具，
讓具有代表性的使用者介入、對系統進行瞭解、參與評估系統原型的
各個層面，如：介面的架構與功能、運作的次序、所需的資訊顯示方
式及支援使用者的需求等，並提出改進意見。

利用原型所收集的資訊可協助設計師進行設計上的決策與了解設計的
得失，而進一步將參與者意見轉換成設計構想，進行不斷調整、改進，
以更合乎使用者的需求，因此原型亦體現『循環式的設計 (Iterative
Design) 』的概念。

原型有其優點與風險。最主要的優點是：它提供了一種評量早期設計

14
Preece, Jenny. A Guide to Usability - Human Factors in Computing. Addison Wesley. 1993.
人機介面與互動入門-電腦之人因工程。陳建豪譯。何碩科技出版。1998。
四—42
概念的具體可用的客觀方法。這往往是非常需要的，因為由一般研究
所獲得的資料，很少能回答所有在產品介面設計過程中所發生的問
題。原型可以由使用者取得有意義的回饋，提高產品功能符合預期的
可能性。此外，原型提供了具體可用的模型，為設計者及使用者提供
共同的參考平台，它不會有書面規範的模稜兩可或受到誤解。最後，
使用原型可以明顯的降低整個軟體發展的成本。若原型軟體無法直接
轉用在最終的產品上，節省的比例仍在 3：115（即每投資 1 元在原型
軟體上，即可節省 3 元的成本）。如果原型軟體可以重新使用在最終
的產品上，則將可以節省更多的成本。

原型方法最 大的風險在於：不易管理與控制。建立一個在產品上無
法執行的功能的原型是很容易的，因此有時原型建構階段會脫離設
計團隊的掌控，容易發展出無法在實際產品實行的功能，讓設計者
與使用者產生不切實際的期望。其次是將軟體的編碼由原型轉換到
產品上的問題。如果原型工具的軟硬體環境和實際的產品不同，所
生產的軟體可能必須全部重新編碼設計。

原型的種類
原型可能將重點焦距於互動式介面的某些重點，而忽略其它部分：原
型可能在系統大小、信賴度、穩定度，完整性及架構內容與最終的系
統有所不同。若以發展完整性及架構內容進行分類，它們包括16：

1. 完整式原型(Full prototypes) ：包含有完整的功能，但其執行效能

15 Cushman, William H.,著。蔡登傳，宋同正譯。Human Factors in Product Design. 產品設

計的人因工程。六合出版社。八十五年八月。
16
改編整理自Preece, Jenny. A Guide to Usability - Human Factors in Computing. Addison
Wesley. 1993.人機介面與互動入門-電腦之人因工程。陳建豪譯。何碩科技出版。1998。
四—43
 可能劣於最終的系統。

2. 水平式原型(Horizontal prototypes) ：僅顯示系統主要運作層面，

但未提供完整的功能。

3. 垂直式原型(Vertical prototypes) ：僅提供系統某個特定部份的完

整功能。

有些分類則依據原型發展的方向及方式，它們包括17：

1. 需求動畫原型 (Requirements Animation Prototype)：或稱關鍵

螢幕原型 (Key-Screen Prototype)。此原型只提供關鍵功能〈最
初系統規格訂定時的需求〉
，以動畫模擬，呈現出系統的主要導
引路徑，並可與使用者互動。一個選單系統的原型可能只有主要
的的一條或者兩條路徑是可以運作、而非如最後版本的上千個條
路徑。對於表格填寫系統而言，原型可以僅僅顯示其無法運作的
填寫格。關鍵螢幕原型可以用來把系統的提案展示給使用者，以
讓使用者評估、取得他們的修正建議。把關鍵螢幕原型也可以用
來作可用性測試和啟發式的評估。通常關鍵螢幕會引起熱烈的回
應，讓使用者提早參與，以及為設計師提供修正創造的動力。
Macromedia Director 和 Flash 是適合的軟體工具。

2. 快速(拋棄式) 原型(Rapid，throw-it-away Prototype)：此原型在

設計初期即開始建構。它的基本假設是：通常系統的需求在最初
訂定時都是不正確的。因此強調在拋棄原型前，對原型進行評

17
改編整理自Preece, Jenny. 同上。
四—44
 估、收集設計需求，以及可能的設計方案，以做為更進一步建置
『紙雛型 (paper prototyping)』適合於建構快速原
介面的參考。
型。紙雛型可以用紙、筆將介面草圖畫出，或使用文書處理工具
來列印出來，用手動顯示圖與圖間的關係給使用者檢視以進行評
估。其優點為：快速、簡易、成本低。缺點為：真實性低。

3. 演化式原型 (Evolutionary Prototype)：一種介於最終軟體產品與

原型間的妥協方式。此種原型可以在系統發展之前或之後配合進
行改變。此法可協助克服傳統上介於系統規格與最終結果的代
溝。由於演化式原型最後會被用於建置最終的系統，所以挑選設
備、工具時必須慎重考慮。在原型被評估後，會進行新增和修正，
而成為最終系統。

4. 漸進式原型 (Incremental Prototype)：漸進式的建立介面，搭配

整體的設計計劃而發展，使用可重複使用的軟體及高度模組化的
程式語言，一次一個階段，像是使用螺絲釘一般，將一些元件栓
緊組合成最終的系統。

事實上在建立介面原型時，很難下定論必須採用上述何種類型。發展
者可能想要有個拋棄式原型，但實際上它演化為最終使用的系統介
面。同樣地，發展者可能本意是要建立演化式的原型，但卻後來將其
棄置或用其它的系統取而代之。

四—45
 第二項 構建原型的軟體工具

軟體工程團隊的工具
常見的軟體工程團隊的原型工具包括：視覺化的整合發展環境工具，
如易於學習而且功能完整的微軟 Visual Basic 〈圖 4-23〉、Visual
C++ 、與 Borland's 的 Delphi。而複雜的程式發展環境工具，如 Visix
的 Galaxy 和昇陽的爪哇程式，則提供跨平臺的發展環境和豐富的多
樣的服務。

許多公司發展介面時，仍以軟體工程團隊的原型工具為主。此時設計
師必須與軟體工程師密切合作，甚至了解軟體工具的部分的特性與限
制。舉例而言，設計師必須親自了解微軟 VB 如何建構按鍵、如何輸

〈圖 4-23〉使用微軟 Visual Basic 製作 Driver 安裝介面。達創電子，賴紳洧提供。

四—46
入圖檔。設計師可能必須將圖檔以 bmp 的格式，將按鍵圖案分離出來
以供軟體工程師使用。或甚至執行設計決策：決定是否為了整體畫面
的完整性〈比如為了按鍵的落下式陰影的效果，無法將按鍵與背景圖
分離〉，而將所有按鍵與背景圖結合輸出給微軟 VB，而按鍵部分則
由軟體工程師在其上層建構透明的反應區。

工業設計與視覺傳達設計師的工具
設計師可以使用點陣圖 Adobe PhotoShop，向量式 Corel Draw..等繪
圖軟體來創造選項、按鍵、圖案、icons。近來為了讓介面更為立體、
擬真，也大量使用立體濾鏡、落下式陰影、材質，或使用外掛濾鏡軟
體 KPT 5.0 的 Shape Shifter 直接製作立體按鈕＜請參閱第二章圖
2-4：如何用繪圖工具達到立體的效果＞。

早期設計師也廣泛的使用界面模擬軟體 HyperCard 〈次頁圖

〈圖 4-24〉作者使用 MacroMedia Flash 來建構家庭影音介面原型，2001。

四—47
4-25、圖 4-26，麥金塔軟體〉近期的 Macromedia Director，或挪用
網路動畫特效軟體 Macromedia Flash 來模擬界面〈圖 4-24〉。本
書的附錄二商請陳冠竹先生為文，探討如何實務運用 Flash 來模擬
界面。由於坊間的 Flash 工具書大多專注在動畫或網路特效，相信
聚焦於介面原型模擬的專文對於本書讀者將有極大的助益。

四—48
 第七節 設計階段六: 進行細部設計
在設計階段六裡，設計師必須詳細指明使用的設備、執行每一細部的

〈圖 4-25〉界面模擬軟體 HyperCard，懷孕教學，1993。由蕭麗娟在修習亞歷桑那
州立大學的教育媒體與電腦科系時所製作。早期的 HyperCard 是黑白的，非常適合
製作電腦輔助教學軟體。由於最初原型可以修改為最終軟體，美國多媒體教育的學生
也將自己的作品出版，在各通路販賣。

〈圖 4-26〉家庭影音介面，初步實驗〈拋棄式〉原型， HyperCard，作者製作，1994。
由於 HyperCard 容易製作的特性，適合作為介面設計之初，用以執行初步實驗、蒐
集使用者資訊的拋棄式原型。

GO
PHASE 3-1

RECORDING
2

SELECT ONE TO BE RECORDED

TV CD TAPE RADIO
3

SELECT THEN GO NEXT

四—49
設計，同時進行初步測試，以確認設計成果是否如預期的運作。

第一項 詳細指明使用的設備
首先團隊成員必須選定下列事項：選擇最終使用的軟體、實際運作的
硬體、選擇聲音、圖象、或周邊裝置。然後建立溝通方式的需求，執
行進一步的初步實驗。

設計精良的使用者介面所使用的硬體的成本可能較高，因為需要更多
的記憶體、更強的中央處理器、及更好的顯示運算能力。專案領導者
可能受限於預算壓力，必須對硬體的等級作某種程度妥協，但是仍將
介面反應速度控制在使用者可以接受的
範圍。若部分運算速度仍無法達到要求， 〈圖 4-27〉麥金塔系統的進
度顯示。
應該修改介面以提供進度顯示〈圖
4-27〉，以避免使用者誤認為系統並未反
應而將操作重複再執行一次，而造成無法
預期的後果。

第二項 發展最終軟體
假若介面發展團隊選用的原型建構方式是演化式或漸進式時，實際上
在設計階段之初即已開始發展最終使用的系統介面。但若選用關鍵螢
幕原型，此時便需花費更多的心力磨合軟體團隊與設計團隊之建的鴻
溝。前面已提及，快速原型的建立過程常常發展出在實際產品上、或
在時間壓力之下無法完成的功能，因此此時的溝通、妥協就越顯重要。
以作者的經驗而言，有經驗的專案領導者，當發現快速原型發展出在
實務尚不易完成的功能時，應會在第一時間赴軟體工程部門溝通，研

四—50
究解決之道。或甚至更好的狀況是，尋求軟體工程師提早進行此困難
功能的設計，如此實現構想的機會便會大增。反之而言，若在設計階
段六進行細部設計時才開始尋求溝通，因為造成軟體部門的時間壓力
大增，此時很有可能造成部門對立的狀況，不只實現構想的機會大減，
更容易損及最終軟體的品質。

其次是將軟體的編碼由原型轉換到產品上的問題。如果原型工具的軟
硬體環境和實際的產品到最後發覺難以共用，或測試之後不如預期，
最終生產的軟體可能必須全部重新建構，而造成時間上的拖延。

第八節 設計階段七﹕評估測試
戲劇製作人都知道﹕將彩排獨家開放給戲評家觀賞得以確保首演之夜
的成功。最初的排演可能只需要穿著便服的一個或者兩個演員的走
秀﹔但是，當首演之夜逼近，使須要完整的卡司、佈景道具與燈光。
同樣的，飛機設計工程師進行風洞的測驗、建造夾板的機艙內裝模型、
製作完全仿真的駕駛座艙、並由機師實地測試第一個原型機。現有的
互動介面設計師已認知到﹕對顧客推出系統之前，他們必須執行許多
大大小小的初步實驗。除了許多專家評估方法之外，針對目標使用者
所做的測試、調查已證明有其價值。根據可用性研究的目標、期望的
使用者人數、錯誤所造成的危險性、和投資的大小，設計程序將有不
同的變化18。

評估的方法是指收集關於使用者介面運作，及使用者態度的資料之程

18 改寫自Shneiderman, Ben. Designing the User Interface: Strategies for Effective

Human-Computer Interaction. Addison Wesley Longman, Inc.. 1998.
四—51
序。基本上我們可以將介面常用的評估方法分類如下19：專家式評估、
觀察式評估、調查式評估、實驗式評估、可用性工程測試。其中最後
一項可用性工程測試其實是上述評估方式的混合，但是因為其測試方
式與介面可用性評估有緊密的關係，所以將其獨立介紹。以下針對這
五類評估方法詳述之：

第一項 專家式(expert)評估
專家式評估又稱為啟發式(Heuristic)評估，是一種『診斷(Diagnostic)』
的方式，讓專家參與評量使用者介面，而由專家們扮演成經驗不足的
使用者，描述一般使用者可能會遇到的潛在問題。為了要確保每個評
估者能夠客觀公平，原則上啟發式評估每次只由一個專家完成評估，
在所有評估者完成後，才讓專家們交換意見並將意見彙整起來。

19
Preece, Jenny. A Guide to Usability - Human Factors in Computing. Addison Wesley. 1993.
人機介面與互動入門-電腦之人因工程。陳建豪譯。何碩科技出版。1998。
四—52
介面評估實驗的過程

洪郁修，張育銘，陳建旭。電子通訊產品軟體介面評估系統之發展研究。數位化時代的設計教育：

研討會論文集。工業設計。第二十九卷，第二期，2001 年。

此篇論文針對電子通訊產品的軟體介面做出兩種不同形式的構想，一為文字式的介
面、二為圖像式的介面。其後利用介面評估實驗比較兩種構想的優劣，嘗試建立評估
決策模型。各個步驟如下：

STAGE 1： 尋找 5 位使用性工程專家，對其說明受測產品之基本功能，以便其訂定
『介面使用性評估準則』。此準則分別是：介面學習性、使用認知性、
介面記憶性、介面效率性、介面操作性。

STAGE 2： 使用性專家對各『介面使用性評估準則』從 1 至 9 作成對屬性權重評比。

STAGE 3： 挑選 20 名學生，男女各 10 名，在實際操作過兩實驗介面之後，給予問

卷〈如下表：介面提案評分表〉，依據專家評定之準則對兩介面設計提
案進行強度區別尺度之評分，在不同準則下勾選介面設計案其理想程度
之高低。

STAGE 4： 計算兩介面之綜合得分，以得出較佳的設計案。

STAGE 5： 最後讓 20 名學生填寫問卷，詢問何者為較滿意的設計案，與 STAGE 4

的綜合得分印證其結果。

介面提案評分表
文字式的介面 圖像式的介面
1 2 3 4 5 6 7 1 2 3 4 5 6 7

介面學習性
使用認知性
介面記憶性
介面效率性
介面操作性

在專家式評估中，
『專家』通常是指有使用者介面設計經驗、或從事人
因工程研究，可以獨立完成介面評估者。選擇專家是相當重要的﹕首
先，為確保得到較無偏見的建議，專家不應參與系統先前版本或雛型
的評估，以免有先入為主的觀念。此外、評估時專家所執行的操作，
以及拿到的使用手冊、教學課程、或其它文件必需有代表性，以能模
四—53
擬最終使用者所會面對的狀況20。

專家式評估的優點為：一小組專家通常可以找出使用者可能將會面對
的大部份潛在問題。如此評估方式則需要較少的資源，成本通常低於
參與式的評估，是較有效率的方式。此外，由於專家有豐富的使用者
介面經驗，通常設計團隊會要求專家對於所發現的問題提出建議、修
正方案。一般而言，使用者因經驗不足，所以僅能片斷地對某些問題
提出建議。

專家式評估的缺點包括：受限於角色扮演，專家可能會有其主觀的強
烈觀點或偏見，而無法完全反映真實使用者的行為。此外，初學使用
者可能會做出一些非常令人意外的事，而專家便無法預測到此種行
為。最後，良好的角色扮演需要大量的資訊，包括：使用者的知識程
度，使用者典型的作業及使用者對問題的反應等，而通常要找到同時
對某特定應用程式有經驗，並對人機互動有研究的專家並不容易。

20
改寫自Preece, Jenny. A Guide to Usability - Human Factors in Computing. Addison Wesley.
1993.人機介面與互動入門-電腦之人因工程。陳建豪譯。何碩科技出版。1998。
四—54
第二項 觀察式 台科大互動式介面期末作業：介面評估測

(observational) 試。
評估
測試報告重點如下：

觀察式(observational)評估
1. 找三個人當受測者。
在使用者實際操作使用介
面時對其行為進行觀察與 2. 訂定測試 Task (任務)，即是要求受測者
在介面原型上必須完成的工作，可以是你
追蹤，搜集到的資料提供了
認為此介面原型最具代表性的 Task ，或
使用者如何與介面互動的 是只要受測者能完成這項任務，幾乎可推
資訊。觀察可能在特別選定 斷他會操作這個介面。

的地點，如可用性實驗室
3. 簡短向測試者報告測試的背景及目的，
(usability laboratory)進行， 紀錄受測者完成測試 Task (任務)的時
可以對使用者的干擾降至 間，觀察他在哪個關鍵點出錯或猶豫，測

最低，或是非正式的場合， 後訪問受測者者的感想，可以改進的地
方。(因時間關係，本次作業並不要求你立
比如在使用者日常的工作
刻改進介面原型，但是你必須提出下一版
環境進行。 的介面原型可以改進的設計重點)

3. 測試報告包含：測試的背景及目的、受
觀察式評估的資料收集技
測者特徵、測試設備、地點、測試 Task (任
術包括21:：
務)描述，受測者完成測試 Task (任務)的
時間、測後訪問整理，下一版的介面原型
1. 直接觀察(direct 的設計改進重點。

observation)：當使用者
執行作業時進行觀察，觀察者在一旁對使用者的執行效能做註記，
並可能記錄使用者所採取行動之順序與所花的時間。然而直接觀察

21
Preece, Jenny. A Guide to Usability - Human Factors in Computing. Addison Wesley. 1993.
人機介面與互動入門-電腦之人因工程。陳建豪譯。何碩科技出版。1998。
四—55
 是一種較莽撞的方式，因為使用者通常會不斷的注意到有人一直在
監視他們的行為和執行效能，這可能會影響他們執行效能的程度。

2. 拍攝錄影帶(video recording)能記錄觀察使用者的活動。所拍攝的
錄影帶稍後將會被播放，使用者與評估者共同分析所拍攝的錄影
帶，以探討使用者在活動中所面臨的問題。此種使用者與評估者一
起參與調查的方式為上述參與式設計的程序之一。

3. 軟體記載(software logging)可以用來記錄使用者與介面之間的互
動狀態，其所產生的記錄檔通常有個『時間標記(time-stamped
log)』來記錄使用者的使用時間與系統之反應。其優點是不會打擾
到使用者。軟體記載的方法也可以將過程記錄下來之後，重新產生
〈重播〉整個對話過程以供分析。

4. 互動式的觀察(interactive observation)是一種直接的觀察式評估
之變化形式，亦被稱為『Wizard of Oz 法』
。它的特性在於操作員
隱藏於簾幕後，以模擬所有的系統互動。此觀察不讓使用者注意到
幕後操作員，因此使用者可以專注於與使用者介面之互動。此方法
尤其適合介面在可以運作之前的初期評估測試。

5. 口語調查(verbal protocols)用以記錄使用者所『說出』對事物之觀
察與想法，有時會同時配合拍攝錄影帶。最廣為人知的是所謂的『發
聲思考(Think Aloud)法』
。由口語調查法可以獲得廣泛的資訊，例
如使用者對特定操作的意圖、對指令的回憶，對介面運作、系統回
應與錯誤情況的瞭解等。然而在測試中通常會發覺，當使用者專注
於全解決問題時，要同時把想法用言語表達是相當困難的。口語調
四—56
 查的變化形式包括：在調查中加入問題詢問、或在作業完成後再進
行調查(即『事件後調查(post-event protocol)』)。在事件期調查中，
使用者觀看自己的操作紀錄錄影帶，並解釋當時操作的說明。此技
術的缺點是使用者可能會將他們的行動做合理化的解釋，而造成某
種程度的扭曲。其優點在於適合調查具有安全顧慮的、需要非常專
心的或在時間上緊迫性的作業。

第三項 調查式(survey)評估

調查式(survey)評估試圖透過訪談或問卷調查，以取得使用者對介面
的主觀意見。

訪談

訪談必須事先計劃，通常訪談進行前應該選定訪談形式：包括主題的
核對清單、問題的次序。訪談形式包括兩種 -結構式的訪談與彈性式
的訪談22:：

1. 結構式訪談(structured interview)：問題的次序是事先決定的，並
不進一步探求使用者的個人態度。這種固定結構式的訪談常見於關
於大眾意見的調查中。

2. 彈性式訪談(flexible interview)：事先決定問題，但未決定問題的次
序，訪談的進行是隨著受訪者對問題的回答，與其個人的態度而定。

22
Preece, Jenny. A Guide to Usability - Human Factors in Computing. Addison Wesley. 1993.
人機介面與互動入門-電腦之人因工程。陳建豪譯。何碩科技出版。1998。
四—57
與彈性式訪談相比，結構式訪談較易於進行，也相當容易分析其結果，
但關於使用者個人重要意見部份或許無法被記錄。

情境訪談

若以訪談的地點、受訪者的參與度更進一步細分，訪談也包括『情境
訪談(contextual interview)』
。情境訪談是情境調查 (contextual inquiry)
的主要技術：情境調查方法是使用者與研究人員共同的參與研究調
查，其目的在於探討使用者在自然的工作環境中所經歷的可用性問題。

在情境訪談中，使用者與研究人員討論使用者的目標、工作的方法、
及在使用系統時所遇到的問題等。任何所收集到的資料，如錄影帶或
是筆記，隨後會由研究人員與使用者參與共同分析。隨著多媒體系統
及群體共享之作業環境的日益增加，情境調查的使用可能會越普遍，
因為侷限在實驗室進行的可用性測試，將是較不易執行的。

問卷調查

問卷調查可以大致分為兩類問題結構：一是開放式問題(Open
Questions)，讓答問者可以自由地提供他自己的答案，此問題提供了
一個豐富的資料來源，但其結果可能相當難以分析。二是封閉式問題
(Closed Questions)，要求答問者由一群答案選項中選擇一項答案，
一般而言較開放式問題易於分析。

四—58
 封閉式問題的等級評比方式

封閉式問題通常會採取以下的幾種等級評比(Rating Scale)方式23：

1. 最簡單的等級評比方式為採用核對清單(Checklist)，此方式在特定
問題裡只提供基本答案選項。下圖所示是一個常見的核對清單，採用
『是、否、不知道(或不確定)』三個等級評比。通常核對清單也用於
檢查或記錄某些介面功能是否存在或遺漏‧

你會操作下列功能嗎？
會 不確定 不會
選擇預約頻道 □ □ □
調整預約時間 □ □ □

2. 多重點數(Multi-point)等級評比方式《是比較複雜的評比，它增加
了較多的等級，每個等級可能會標明其代表的程度，或僅標明兩端所
表示的程度，如下圖所示：

你認為「預約功能」對您有用的程度，請用下列比率來衡量
非常有用 □ □ □ □ □ 無用

23
改寫自Preece, Jenny. A Guide to Usability - Human Factors in Computing. Addison Wesley.
1993.人機介面與互動入門-電腦之人因工程。陳建豪譯。何碩科技出版。1998。
四—59
3. 喜好度等級(Liker Scale)評比方式是多重點數等級評比方式的變化
形式，如下圖所示：它顯示同意的程度，及衡量其程度的說明。

你認為本介面可以簡化「預約功能」的操作嗎？

非常同意 同意 沒意見 不同意 非常

不同意

4.語義區別(Semantic Differential)等級評比方式是人機互動研究中常
用的方式。如下圖所示，評比等級的兩端為兩極化的形容詞(如：使用
簡易一使用困難、清楚的一難懂的) ，每個等級的程度則成對地標示
於中間。

請在下列空格打勾來評估此介面

非常 有點 會 中立 會 有點 非常

使用簡單 使用困難

不易造成 容易造成
錯誤
錯誤
不花時間 花時間

5. 排序的評比方式是要求受訪者按照名次來排列某些項目的等級。例
如下圖，可以要求使用者對某些項目的操作困難度進行排序。此種方

四—60
式適合於較小的項目群組，若使用於對較大的群組項目可能會讓受訪
者感覺困擾。

你認為下列哪一步驟最難操作，最難的為 5，最簡單的為 1
選擇 調整 取消 編輯 啟動
預約頻道 預約時間 預約 預約 預約

問卷調查的優點在於所獲得的回答可以轉為數值資料，可運用統計學
來分析，因此可用於調查大量的使用者。其缺點在於問卷調查的回收
率可能會不高(尤其是郵寄的問卷調查)、可能包含訪問者與受訪者的
偏見。其訪談調查可能相當地耗時，分析過程可能過於複雜冗長。

第四項 實驗式(experimental)評估

實驗式評估使用科學的實驗方法以印證關於使用者介面的假設（如此
的假設必須可以加以測試，比如找出某變數對執行效能的影響）
。通常
此評估方式會小心謹慎地控制住四周的變數，因此得以建立各別影響
介面操作的因子的數据及相互關係（或條件）
，然後以統計的方式加以
分析。

實驗式評估的優點是評估方法有相當良好的可信度與有效性、其產生
的數據足以供統計分析、其實驗也可重複進行、也能夠對不同的使用
者群體進行比較。其缺點是需要大量的資源、需要具有專業實驗方法
四—61
的知識、實驗的時間很久〈代表著時間上較難與介面設計時程配合〉。
其評估作業可能是非常耗費人工的、而且並不是每次實驗結果都可實
際的套用於整個系統。

第五項 可用性工程(Usability Engineering)測試

可用性工程可以緊密的與介面設計發展過程結合，其中的可用性測試
著重於評估使用者效能。可用性尺度(Usability Metrics) 就是所收集到
用以描述和衡量介面可用性的資料。下述列出四大可用性尺度，包括﹕
可學習性、易用度、彈性、及態度24：

可學習性(learnablilty)：使用者需要達到某種作業上的效能所要的時
間與努力 (也稱為『容易學習(easy of learning)的程度』)。它包含由
特定一組使用者完成某特定作業所需的時間、每項作業所犯的錯誤數
量、花在參閱系統文件的時間等。

易用度(easy of use)：經驗的使用者在完成某些作業時，所需的時
間、作業執行的速度以及使用者所犯的錯誤等(也被稱為『單位時間內
能處理的輸出入總量(throughput)』) 。

彈性(flexibility)：隨著使用者對系統逐漸的熟悉，使用者能夠適應系
統新的互動方式的程度。

態度(attitude)：使用者對系統產生正面或負面的態度與評價。

前面已提及：可用性工程測試其實是上述評估方式的混合。可用性工

24
Preece, Jenny. A Guide to Usability - Human Factors in Computing. Addison Wesley. 1993.
人機介面與互動入門-電腦之人因工程。陳建豪譯。何碩科技出版。1998。
四—62
程測試採用問卷調查及訪談，以收集使用者意見的資料與數據。其評
估途徑普遍採用觀察式評估法，在建立起『基準作業(benchmark
tasks，為具代表性的主要操作流程)』之後，以錄影或自動化的方式
來記錄使用者執行基準作業的效能。其觀察有時也在『可用性實驗室
〈Usability Laboratory〉』中進行，這種實驗室內部設有一面單向透視
的鏡子，所以評估者可以觀察受試者，而不會被看到。

雖然可用性工程測試是較為嚴謹的評估方式，也可以提供有價值的資
訊與數據，但是仍然有其缺點：比如基準作業實質上與真正執行介面
操作仍有不小的的差距。其次在現實生活中，通常使用者擁有同事間
的互動幫助或其它社會網路的支援，而非隔離的狀態。最後在於時間
的壓力，實驗室內的時間限制通常是固定不可更改的，然而在實際環
境中，使用者經常自由決定與介面的互動時間。

讀者若想進一步研究可用性工程，請參照 Nielsen, Jakob. 的 Usability

Engineering〈可用性工程〉，AP Professional 出版。

四—63
第九節 設計階段八﹕產品發表與提供支援
在最後的第八設計階段，最終介面公開發表。 專案領導人必須排除
障礙、與市場行銷人員合作、激勵出採納公司產品的誘因。此階段
的工作包括：

1. 上市：整合系統、銷售給使用者。與市場行銷人員合作，準備
銷售計劃、組織使用者團體、發展售後服務。

2. 輔助文件：設計師與技術手冊撰寫人員合作，提供圖面、設計
特點。推出使用手冊，參考手冊，輔助設備和教材，或線上說
明、維護支援資料。

3. 檢討：蒐集相關反應、整理顧客意見調查表、檢討與評估設計
成品，進行改版修正計劃。

設計階段至此雖然告一段落，但是事實上，介面的生命與互動者接觸
之後才開始。第一次就創造出一個不需改變完美的介面的可能性幾乎
微乎其微，因此設計師必須調整觀念，將上市的產品視為持續不斷演
進的介面。蒐集顧客的回應，重複多次循環式的設計程序，在每次循
環設計中調整、改進以更合乎使用者的需求。如此生生不息的設計循
環將永不停止。

四—64
 第四章作業：任務分析與架構路徑發展
題目： 自選，得以反映互動界面設計理論與實務的題目。

內容： 1. 題目、問題陳述。
2. 任務分析。
3. 架構路徑發展。

格式: 網路發表：800X600 網路頁面，最少三頁，視同繳交報告。

課堂發表：設計簡短發表（每人五分鐘）
，互相觀摩，檢討。

注意事項：初學者常常誤以為任務分析與架構路徑發展便是用途說明
或使用情境。任務分析應該是表列式的，在構想還未成形之前，把所
有可能的功能都詳盡的用文字列出，然後做簡單的分類。任務分析的
目的在於幫助設計師全盤的掌握介面的所有功能、所有可能。

而架構路徑發展承續任務分析的結果，進一步地將使用者所需執行的
任務(作業)作更詳細的規劃，用樹形圖組織成細部執行步驟，也就是
操作的次序。

第四章作業：設計實作最終發表
題目： 如上述。

內容： 1. 標題、題目、簡介、作者。
2. 提案特點說明：說明提案特色。儘量展現介面設計的創新
度、思考清晰度、說服力，對使用者行為更深的觀察…) 。
3. 任務分析，架構路徑發展，語義架構和句法設計。

四—65
 4. 介面原型。
5. 測試報告。
6. 階段學習結論：請自由發揮。

格式: 網路發表：800X600 網路頁面，最少五頁，視同繳交報告。

課堂發表：設計簡短發表（每人五分鐘）
，互相觀摩，檢討。

注意事項：因時間關係，測試報告為小型初步測試，重點在於提出下
一版的介面原型可以改進的重點。步驟如下：

1. 找三受測者。
2. 訂定測試 Task (任務)，即是要求受測者在介面原型上必須完
成的工作，可以是你認為此介面原型最具代表性的 Task ，或
是只要受測者能完成這項任務，幾乎可推斷他會操作這個介
面。
3. 簡短向測試者報告測試的背景及目的，紀錄受測者完成測試
Task (任務)的時間，觀察他在哪個關鍵點出錯或猶豫，測後
訪問受測者者的感想，可以改進的地方。
4. 測試報告包含：測試的背景及目的、受測者特徵、測試設備、
地點、測試 Task (任務)描述，受測者完成測試 Task (任務)的
時間、測後訪問整理，下一版的介面原型的設計改進重點。

四—66