Joel on Software

Joel on Software 周思博趣談軟體

 

程式師的使用介面設計手冊
第1章
第2章
第3章
第4章
第5章
第6章
第7章
第8章
第9章

其他Joel on Software文章( 繁體中文)

其他Joel on Software文章(英文)

與作者聯繫 (英文)

 

程式師的使用介面設計手冊
第6章: 為節省大家的麻煩所作的設計


作者: 周思博 (Joel Spolsky)
譯: 梅普華
2000年4月26日

當你在設計使用介面時, 最好能記住兩個原則:

  1. 使用者是沒用手冊的, 即使他們有手冊也不會去讀.
  2. 事實上使用者是不會去讀任何東西的, 就算有東西可以查他們也不想去查.

嚴格講起來這並非事實, 不過你應該假設這是事實並照著去做, 因為這樣能讓你的程式更容易而且更親近使用者. 設計時心存這個想法就叫做尊重使用者, 意思就是不要太尊重使用者. 看不懂嗎? 讓我來解釋吧.

怎麼樣才算是讓東西容易使用呢? 度量方法之一就是看看真實世界中的使用者有多少比例能在指定時間內完成工作. 舉例來說, 假設你程式的目的是讓人們把數位相機的照片轉成網路相本. 你可以找些一般使用者來, 請他們用你的程式完成這項工作. 如果你的程式愈好用, 就會有愈多的使用者能成功地建立一個網路相本. 用科學的方法來說, 就是假設有100個真實世界的使用者. 他們不一定要熟悉電腦. 他們各有所長, 不過其中有些人是不太會用電腦的. 有些人在用你的程式時還會分心. 電話會突然響起. 喂. 什麼? 小孩在哭. 什麼? 貓跳上桌子追老鼠. 我聽不清楚啦!

雖然我沒有看著這個實驗進行, 我有相當的把握敢說, 有些使用者就是無法完成工作或者要花非常長的時間才完成. 我並不是說這些使用者是笨蛋. 相反的他們可能非常聰明, 他們也可能是很高超的運動員, 不過對你的程式而言, 他們就是無法把他們的運動技巧和腦細胞用上去. 你可能只抓住他們30%的注意力, 所以你必須與一個顯然不是全心投入的使用者打交道.

 

使用者不讀手冊.

首先使用者是真的沒手冊. 可能是根本沒手冊. 就算真有手冊, 使用者也可能因為各種原因拿不到: 人在飛機上; 正在用由網站拿下來的試用版; 人在家可是手冊在公司; 他們的資訊部門從來不提供手冊. 說實在的, 就算可以拿到手冊, 除非他們別無選擇, 否則就是不會去讀. 只有少數的例外, 才會有使用者抱著手冊讀一遍後再去使用軟體. 通常你的使用者都是想完成某項工作, 而且他們認為閱讀手冊是浪費時間, 就算不是浪費時間, 至少也會讓他們分心而阻礙他們完成工作.

 

你能讀這本書, 表示你是高等知識份子中的精英. 沒錯, 我當然知道能用電腦的人通常都閱讀, 不過我敢保證其中很多人都會覺得讀東西是很煩的. 手冊所用的語言可能不是他們的母語, 也有可能他們還不夠精通. 他們也可能只是小朋友! 如果真的必要, 他們還是能搞懂手冊內容, 不過沒必要的話他們是絕對不會去看的.  使用者只有在絕對需要時, 才會臨時去看手冊.

所以結論就是你可能沒有選擇, 只能把軟體設計得不用手冊就可以上手. 唯一我能想到的例外就是使用者缺乏領域專業知識時 -- 他們根本不懂這個程式的功用, 不過卻知道自己最好要去學. Intuit極受歡迎的小企業會計軟體QuickBooks就是個很好的例子. 這套軟體有很多使用者都是對會計完全沒概念的小企業主. 而QuickBooks的手冊就假設它得教大家會計原則. 這是一定要的. 不過如果你已經懂會計, 即使沒有手冊QuickBooks還是很容易用.

事實上使用者根本不會讀任何東西

這聽起來可能有點刺耳, 不過你很快就會懂了, 當你在進行可用性測試時, 會有相當數量的數用者根本不看畫面上的字. 不管你在畫面上顯示什麼樣的錯誤訊息, 他們根本都不看. 這可能會讓身為程式員的你驚惶失措, 因為你想像自己正與使用者對話. 嗨, 使用者! 你不可以開啟這個檔案, 我們不支援這種檔案格式! 不過經驗顯示, 對話框裡放的字愈多, 愈少人會實際去讀.

使用者不讀手冊這個事實, 讓很多軟體設計者認為程式應該在事情發生當時加以敘述以教育使用者. 所以你會在程式各處都看到說明. 理論上這是可以的, 不過實際上由於人們討厭閱讀, 所以這招還是很不通的. 有經驗的使用介面設計者會努力把對話框內的字數減到最少, 以增加使用者看內容的機會. 當我還在Juno的時候, 負責使用介面的人懂這個道理所以試圖寫出簡短清楚的文句. 可惜的是公司總經理以前在長春盟名校主修英文; 他沒受過任何使用介面設計或軟體工程的訓練, 卻深信自己是個優秀的文字編輯. 所以他否決了使用介面設計專家的文句, 反而加了很多他自己的長篇大論. Juno典型的對話框如下:

與Windows對應的對話框比較:

你在直覺上會認為說明有80個字的Juno版本會比只有5個字的Windows版本更"優秀"(也就是更易使用). 不過等你對這類事情做過可用性測試後就知道正確答案了.

  • 進階的使用者會跳過說明. 他們假設自己懂得使用方法, 沒時間去讀複雜的說明
  • 大多數生手會跳過說明. 他們不喜歡看太多字而且希望預設值就能用
  • 其他認真的生手會嘗試閱讀說明(其中有些人只是因為在做可用性測試, 覺得應該要去看), 卻常被恐怖的字數和概念攪亂了. 所以即使使用者很有把握第一次能會用這個對話框, 這些說明還是會讓他們更迷糊了.

不管怎麼說, Juno的老闆顯然都管太細了. 講明白點, 如果你在哥倫比亞大學主修英文, 那麼你的讀寫能力和一般人根本是完全不同的, 而且你應該要非常小心去寫那些似乎很有幫助的對話框內容. 儘量把文句縮短簡化, 把括號裡的複雜子句都拿掉, 並且進行可用性測試. 不過千萬寫得像長春藤聯盟的教學備忘錄一樣. 在對話框裡甚至連加上"請"這種似乎禮貌而有用的字, 都還是會把使用者拖慢: 增加字數會減少閱讀文字的人數, 而且影響是可以測量得出來.

另一個重點是很多人都怕電腦. 這一點你大概已經知道了, 對不對? 不過你可能還不瞭解其中的暗示. 我曾經看著某個朋友要跳出Juno. 不知道為什麼她一直遇到問題. 我注意到當要跳出Juno時會出現下面的對話框:

我的朋友會去按No, 然後就有點驚訝Juno竟然沒有結束. 這個對話框是在詢問使用者選擇, 卻讓她馬上認為自己做錯事了. 通常程式會要你確認某個命令, 是因為你正在進行某些你可能會後悔的動作. 所以我朋友就認為既然電腦在質疑她的決定, 那麼電腦一定就是對的, 因為電腦畢竟是電腦而她只不過是個, 所以就按了"No".

要求人去讀11個無聊的字會不會太過頭了? 顯然是會. 首先由於離開Juno並不會產生傷害, 所以Juno應該不需要提示確認, 像現有的其他圖形使用介面一樣直接離開就好. 不過即使你深信在結束前必須要人們先確認, 也可以用兩個字而非11個字:

少了完全不必要的"thank you"和鼓勵後悔的"are you sure?", 這個對話框就不太會產生問題了. 使用者一定會看這兩個字, 對著程式說聲"嗯?"後就按"Yes".

你會說Juno的離開確認對話框只會困擾少數人, 不過有這麼嚴重嗎? 每個人到最後總有法子跳出那個程式的. 不過個中差異在於可以用還是容易使用. 即使是經驗豐富又聰明的高階使用者, 還是會感謝你為慌張無經驗生手所作的簡化. 旅館的浴缸都有很大的扶手. 它們的用途只是要幫助殘障者, 不過大家都會用這些扶手離開浴缸. 即使對身體健康的人來說, 這些扶手也能讓生活更輕鬆.

下面一章我要討論一些關於滑鼠的事. 就像使用者不會/不想/不能閱讀一樣, 有些人也不擅長使用滑鼠, 所以你必須配合他們.



> 第7章

文件來源: User Interface Design for Programmers Chapter 6: Designing for People Who Have Better Things To Do With Their Lives (英文) 

約耳.斯珀儿斯奇是Fog Creek Software (設立在紐約的一家小型軟體公司) 的創立者. 約耳畢業於耶魯大學 (Yale University) ,並曾經在微軟, Viacom 和 Juno 擔任程式人員与管理工作.


這些網頁的內容為表達個人意見
Copyright ©1999-2005  Joel Spolsky. 所有權利皆予保留 使用規定

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky