試用 。 結果 做出來 的 系統 好用 、 能 用 、 容易 了解 。 好 的 設計 是 可以 達到 的 ， 但 要 從 設計 初期 就 開始 （ 請 參照 Gould , Boies , Levy , Richards & Schoonard , 1987 ） 。 圖 2.1 __UNDEF__ 一 個 人 帶 球跑 。 這 個 球 著地 的 路線 是 Ａ 、 Ｂ 或 Ｃ ？ 波士頓 某 個 學校 的 六年級 學生 只有 4% 答 是 Ａ （ 正確 答案 ） ， 其他 的 學生 回答 Ｂ 、 Ｃ 各 半 。 高中生 也 沒有 好 到 哪裡 。 41 個 剛 學 一 個 半 月 牛頓 力學 的 學生 ， 只有 20% 答對 了 ， 回答 Ｂ 、 Ｃ 的 各 半 （ White & Horwitz , 1987 ） 。 圖 2.2 __UNDEF__ 行動 循環 （ 左 ） 。 人 的 行動 有 兩 個 層面 ： 執行 和 評鑑 。 執行 是 做 某 一 件 事 ； 評鑑 是 比較 執行 後 外界 的 狀況 和 我們 希望 的 狀況 。 圖 2.3 __UNDEF__ 執行 階段 （ 右 ） 。 最 上方 的 「 目標 」 是 我們 想 達到 的 狀態 ， 我們 把 目標 轉化成 一 種 意願 以便 採取 行動 。 意願 必須 化成 一 組 內在 的 指令 ， 一 序列 的 行動 ， 可以 用來 執行 以 滿足 意願 。 這 序列 行動 仍然 是 內心 的 想法 ， 需 加以 「 執行 」 才 會 對 外在 世界 有所 作用 。 圖 2.4 __UNDEF__ 評鑑 階段 （ 左 ） 。 評鑑 是 從 我們 對 外界 感覺 作 開端 。 再 根據 我們 的 期望 加以 詮釋 ， 然後 比較 我們 的 意願 和 我們 的 目標 。 圖 2.5 __UNDEF__ 行動 七 階段 （ 右 ） 。 圖 2.3 執行 階段 （ 意願 、 行動 順序 、 和 執行 ） 和 圖 2.4 評鑑 階段 （ 觀察 、 詮釋 、 和 評鑑 ） 兩 者 連接起來 ， 有 著 共同 的 目標 。 圖 2.6 __UNDEF__ 穿插 膠捲 於 電影 放映機 。 右邊 較 粗 的 細 線條 是 膠捲 穿插 的 路線 。 這 圖片 並 未 表明 整 個 情況 ， 因為 影片 數 個 地方 張力 需要 恰好 ， 不能 太 鬆 ， 也 不能 太 緊 （ 取自 ： 美國 陸軍 和 空軍 1966年 5月 出版 的 《 電影 放映師 手冊 》 〔 Projectionist ’s Manual 〕 ） 。 圖 2.7 __UNDEF__ 用 行動 七 階段 來 問 設計 的 問題 。 如何 讓 使用 者 容易 回答 下列 問題 ： 1 .
 
__UNDEF__ 這 個 用品 有 什麼 功能 ？ 2 .
 
__UNDEF__ 什麼 行動 是 可行 的 ？ .
 
__UNDEF__ 系統 是否 處於 期望 的 狀態 ？ 3 .
 
__UNDEF__ 意願 和 物件 動作 之間 如何 配對 ？ .
 
__UNDEF__ 系統 狀態 和 詮釋 之間 如何 配對 ？ 4 .
 
__UNDEF__ 如何 執行 行動 ？ .
 
系統 的 狀態 是 什麼 ？ 第二 章 日常 運作 的 心理學 有 一 次 我們 全 家 到 英國 ， 租 了 一 棟 家 具 全備 的 房子 。 有 一 天 ， 我們 的 女 房東 回來 尋找 一些 私人 文件 。 她 設法 要 打開 公文櫃 最 上面 的 抽屜 。 可是 她 左推 右 推 ， 上 推下 推 ， 前 推 後 拉 都 沒辦法 打開 這 抽屜 。 我 往 前 幫忙 ， 搖 一下 抽屜 ， 扭 一下 前端 ， 往 下 用力 壓 ， 再 用 手掌心 打 一下 前面 ， 結果 抽屜 就 開 了 。 「 噢 ！ 」 她 說 ： 「 我 對 一些 機械 的 東西 真是 沒辦法 。 」 錯誤 地 歸罪 自己 我 研究 過 人們 在 使用 器具 、 電燈 開關 、 電腦 作業 系統 、 電腦 文書 軟體 ， 以及 在 飛機 和 核電廠 內 作業 時常 犯 的 一些 人為 錯誤 ， 毫無 例外 地 ， 每當 錯誤 發生 ， 他們 都 很 內疚 ， 而且 不 是 設法 隱藏 錯誤 ， 就是 怪 自己 太 笨 或 手腳 不 靈活 。 我 經常 不 容易 得到 觀察 他們 操作 的 許可 ， 因為 沒有 人 喜歡 在 操作 不良 時 被 觀察 。 儘管 我 告訴 他們 東西 的 設計 有 問題 ， 別人 也 犯 了 類似 的 錯誤 ， 他們 還是 怪 自己 。 這 種 現象 尤其 在 所 需要 做 的 工作 看來 簡單 時 ， 更易 發生 。 他們 似乎 悖於 常理 地 認為 自己 在 操作 上 無能 。 ❶ 有 一 次 ， 有 一 家 大規模 的 電腦 公司 請 我 鑑定 一樣 新 產品 。 我 花 了 一 天 的 時間 學會 用 它 並 試 了 一些 問題 。 我 發現 當 使用 鍵盤 輸入 資料 時 ， Enter鍵 和 Return鍵 有 不同 的 功能 。 如果 使用 錯誤 ， 花 了 幾 分鐘 的 工作 ， 恐 就 白費 心血 ， 無法 救回 。 我 於是 告訴 設計 這 新 產品 的 人 說 我 自己 犯 了 好幾 次 錯誤 ， 而且 照 我 分析 其他 的 使用 者 也 很 可能 犯 同樣 錯誤 。 該 設計師 的 第一 個 反應 是 「 你 為什麼 犯 那 個 錯 ？ 難道 你 沒 先 讀 使用 者 手冊 ？ 」 接著 ， 他 就 解釋 這 二 個 功能 不同 之 處 。 「 是 ！ 是 ！ 」 我 連忙 解釋 ： 「 我 知道 這 兩 個 鍵鈕 ， 只 是 我 被 它們 搞昏 了 。 它們 的 功能 很 接近 ， 在 鍵盤 上 的 位置 也 差不遠 ， 而且 對 一 個 相當 熟悉 打字 的 我 ， 經常 只是 習慣性 的 按 Return 這 個 鍵鈕 而 不加 思索 。 我 相信 別人 也 有 類似 問題 。 」 「 沒有 。 」 這 個 設計師 說 。 他 聲稱 我 是 唯一 埋怨 的 人 ， 公司 裡 的 祕書 也 用 了 幾 個 月 這 個 新 產品 。 我 不 太 相信 ， 便 一同 去 問 幾 個 祕書 是否 曾經 想 按 Enter 結果 按 了 Return ， 並且 因此 而 損失 了 一些 工作 資料 。 祕書 們 說 ： 「 噢 ， 當然 啦 ， 這 經常 發生 。 」 我們 就 問 祕書 為何 沒 人 提起 這 事 ， 況且 公司 還 鼓勵 她們 如 遇到 問題 時 應該 報告 。 理由 很 簡單 ： 當 該 產品 有 故障 或 出現 奇怪 的 現象 時 ， 祕書會 據實 報告 ， 可是 她們 如果 想 按 Enter 卻 按 Return 時 ， 她們 就 怪 自己 。 原因 是 她們 應該 知道 怎麼 做 ！ 可是 卻 做錯 了 。 當然 ， 人 都 會 犯錯 。 較 複雜 的 設計 經常 需要 有 說明 ， 使用 者 沒 看 說明 就 去 用 自然 會 做錯 和 混淆 ， 可是 設計 者 應 十分 用心 ， 設法 讓 這些 可能 錯誤 無傷大雅 。 下面 是 我 對 人為 錯誤 的 看法 ： 一 個 可能 發生 的 錯誤 ， 就 會 有 人 去 犯 它 。 設計 者 應該 假設 所有 可能 發生 的 錯誤 都 會 發生 ， 所以 在 設計 時 應 設法 降低 它們 發生