程式師的使用介面設計手冊 第二章：找出使用者的期望

作者：周思博 (Joel Spolsky)
譯：Paul May 梅普華
Tuesday, April 11, 2000 A part of Joel on Software http://www.joelonsoftware.com

新使用者在操作一個程式時，心裡絕不會一片空白。他們會先預設程式會如何運作。如果他們以前曾用過類似的軟體，就會假設這個程式的動作應該與其他軟體一樣。如果他們以前沒有用過 任何 軟體，就會假設你的軟體會遵循某些常規。他們還可能很聰明，會猜測整個使用介面的運作模式。這被稱作 使用者模型 ：也就是使用者心中對程式所做的事的認知。

程式本身也有一個「心智模型」，不過這個模型是用數位方式編碼，並且由CPU確實地執行。這被稱作 程式模型 ，而且是 固定不變的 。我們在第一章說過，如果程式模型與使用者模型一致，就能擁有成功的使用介面。

我們來看一個例子。在Microsoft Word(及大多數文書處理器)中，如果在文件裡放一張圖片，圖片會被儲存在該文件同一個檔案內。你可以建立圖片並把圖片拖入文件內，然後 刪除原圖片檔 ，而文件內的圖片依舊存在。

不過HTML卻不能這樣做。HTML文件一定得把圖片放在分開的檔案裡。如果找個慣用文書處理器卻完全不懂HTML的使用者來，請他用FrontPage等還不錯的所見即所得HTML編輯器，他幾乎一定會認為圖片將會存在同一個檔案裡。這就叫 使用者模型慣性 (如果你願意這樣叫的話)。

所以使用者模型(圖片會嵌入在同一個檔案)與程式模型(圖片必須分開存檔)間就有個討厭的衝突，這樣使用介面一定會產生問題。

如果你正在設計一個類似FrontPage的程式，這就是你會發現的第一個使用介面問題。你不可能改變HTML。所以一定得做些事讓程式模型符合使用者模型。

你有兩個選擇。你可以嘗試改變使用者模型。不過這點將會非常困難。你可以在手冊裡面解釋清楚，不過大家都知道使用者根本不看手冊，而且他們可能也沒必要看。你也可以顯示一個小對話框說明圖片檔不會被嵌入，不過這又有 兩個 問題：熟練的使用者會覺得很煩，另外使用者也可能根本不看對話框。(我們會在第六章深入討論)。

所以呢，山不轉路轉…最好的選擇通常都是改變你的程式模型而不是使用者模型。或許你可以在插入圖片時產生一個圖片複本，存到文件檔所在處的子目錄中，這樣至少能符合使用者認為圖片已複製(可以安全地刪除原圖)的印象。

我要怎麼知道使用者模型呢？

這件事其實很容易。只要問他們就好了！在你的辦公室裡隨便抓五個人或是找朋友或家人，然後用普通的說法說明你的程式(這是個製作網頁的程式)。接下去描述狀況：「你正在編一個網頁，現在有張圖叫Picture.JPG。你要把圖插入到網頁內。」然後問幾個問題來猜測他們的使用者模型。比如「圖片會放在哪裡？」，「如果你刪除Picture.JPG，這個網頁還能正常顯示該圖片嗎？」

我有個朋友正在做一個相簿形式的應用程式。當你把照片加進去之後，程式會顯示一堆小圖：也就是每張圖的縮圖複本。由於產生小圖要花很長一段時間(如果照片很多時時間更長)，所以他想把小圖存在硬碟 某處 ，這樣小圖只要產生一次就好了。有很多方法可以達成這個目的。可以把所有小圖存在一個叫 小圖 的大檔案中。也可以把各個小圖分別存檔，不過放在同一個叫 小圖 的子目錄內。小圖也可以在作業系統內標示成隱藏檔不讓使用者發現。我的朋友選了一種自認最妥當的方法：把各張圖片 picture.JPG 的小圖另存成名為 picture_t.JPG 的新檔，放在原圖的目錄中。如果你本的圖片有30張，完成後該目錄含小圖就會有60個檔案。

討論各種圖片儲存機制的優缺點可以吵上幾個星期，不過還是有比較科學的作法可以用。只要問問使用者對小圖存檔的想法就好了。當然會有很多使用者不清楚或不在意或是根本沒想過，不過如果你問過很多人，就會開始看到 某些 一致的意見。常見的選擇就是最佳的使用者模型，至於程式模型是否要和使用者模型一致就是你自己的事了。

接下來你得測試自己的理論。替你的使用介面建一個模型或原型，然後請大家用它完成某些工作。在他們完成的過程中問他們期望發生什麼事。你的目標是找出他們所期望的東西。如果工作內容是「插入一張圖片」，而你看到他們嘗試把圖片拖進你的程式裡，你就知道程式最好能支援拖放功能。如果他們去點「插入」功能表，你就知道「插入」功能表下最好能有一個「圖片」選項。如果他們把「字型」工具列裡的「細明體」換成「插入圖片」，你就知道這是個沒碰過圖形化使用介面，試圖使用命令列介面的老古董。

那麼要找多少人來測試你的介面呢？你的直覺可能會認為愈多愈好(對科學實驗來說完全正確)。不過你的直覺錯了。幾乎每個靠做可使用性測試為生的人似乎都認為五個或六個人就夠了。超過這個數字之後就會看到結果一直重複，所以繼續做其他使用者只是浪費時間。

你並不需要一個正式的可使用性實驗室，也不必真的去街上隨意挑使用者來做。你可以做個「5毛錢可用性測試」，也就是叫住下一個遇到的人，請他幫忙做個快速的可使用性測試就可以了。不過要注意別說溜嘴先告訴他要怎麼做。應該要他「好好想清楚」，然後再嘗試用開放性的問題找出他們的心智模型。

如果你的程式模型不單純，可能就不是使用者模型。

我6歲時爸爸買了一台世界上第一批的口袋型計算機(HP-35)回家，他努力告訴我那裡頭有一台 電腦 。我覺得不可能。星艦迷航記裡所有的電腦都是整個房間大小而且都有巨大的碟帶機。我認為只不過是按鍵的鍵和LED顯示上各個段落有很巧妙的連接關係，才會產正正確的數學答案(嘿，我才6歲而已)。

有個很重要的經驗法則，就是使用者模型不會非常複雜。當人們必須猜測程式的運作方式時，答案通常是簡單的而非複雜的。

找台麥金塔坐下來用。打開兩個Excel試算表檔和一個Word文件檔。幾乎所有生手都會猜測這些視窗間沒有關連。他們 看起來 就是沒有關係：

Excel_After.gif

從使用者模型來看，點Spreadsheet 1應該會把該視窗叫到最前面。可是 實際 發生的卻是Spreadsheet 2 跑到前面，幾乎對所有人來說這都是個讓人挫折的意外：

Excel_Before.gif

實際的情況如下。Microsoft Excel的程式的程式模型認為「你有一些隱藏的試算表，每個試算表都屬於某個應用程式，而視窗是連到這些隱藏的試算表的。當你把Excel叫到最前面時，所有Excel的視窗也會被移到前面。」

沒錯。隱藏的試算表。不過使用者模型裡具有隱藏試算表的機會有多少呢？大概可能是零吧。所以新的使用者總是會被這個行為嚇到。

Microsoft Windows上有另一個例子，就是按Alt+Tab鍵可以切到「下一個」視窗。大部份的使用者可能都會假設這個鍵是在所有可用視窗間循環。如果你有A,B,C三個視窗，A視窗是在作用中。按Alt+Tab應該會切到B視窗。再按一次Alt+Tab會切到C視窗。實際上第二次的Alt+Tab會切回A視窗。要切到C視窗一定要 按住 Alt後再按 兩次 Tab鍵。這在切換兩個應用程式時還不錯，不過幾乎沒人瞭解這個方法，因為比起在多個可用視窗間循環的模型來說，這個模型稍嫌複雜。

要讓程式模型遵循簡單的使用者模型已經夠難了。當使用者模型更為複雜時簡直不可能做到。所以要儘可能挑選最簡單的模型。

bullet.gif 下一章：選擇

這些網頁的內容為表達個人意見。
All contents Copyright 1999-2002 by Joel Spolsky。All Rights Reserved.