Joel on Software

Joel on Software 周思博趣談軟體

 

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

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

其他Joel on Software文章(英文)

與作者聯繫 (英文)

 

程式師的使用介面設計手冊
第9章: 一個產品的設計程序


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

 

我們已經講過良好設計的原則, 不過原則只是提供方法來評估並改善現有的設計. 不過...一開始要如何找出正確的設計呢? 很多人會先寫出一大本功能綱要, 涵蓋所有想到的功能. 然後設計各個功能並把功能連到功能表項目(或網頁)上. 等他們完全後, 程式(或網站)就會具備所有要的功能, 不過用起來並不順暢. 人們會看著程式卻不知道它能做什麼, 也不知道要如何完成他們要做的事.

 

Microsoft對這個問題的解決方法是一種叫"活動式規劃"(Activity Based Planning)的方法. (就我所知, 這個概念是Excel團體的Mike Conte所發明的, 他後來做煩了就改行去當賽車手). 其關鍵所在是要找出使用者會進行的活動, 然後努力讓這些活動很容易完成. 用下面的例子來解釋最為貼切.

你決定要架一個網站讓大家可以製作賀卡. 如果選用較簡單的作法, 你可能會列出如下的功能列表:

 

1. 把文字加入卡片
2. 把圖片加入卡片
3. 由卡片庫取得預先設計好的卡片
4. 傳送卡片:
           a. 透過電子郵件
           b. 列印出來

如果缺乏較好的方法思考這個問題, 很可能就會做出一個大約1984年代麥金塔的典型使用介面: 一個一開始有張空白卡片的程式, 有幾個功能表選項可以加入文字,圖片,由卡片庫中載入卡片,以及送出卡片. 使用者得坐下來瀏覽各個功能表, 嘗試找出所有可用的命令, 然後各自找出如何結合這些基本命令製作出一張卡片.

 

活動式規劃要求你必須找出一個使用者可能會做的活動清單. 所以你就找可能的使用者談, 結果得出這"前三項"列表:

  1. 生日賀卡
  2. 宴會邀請卡
  3. 結婚紀念卡

現在暫時不要用程式員的想法考慮程式(也就是想著製作一張卡片要哪些功能), 要像使用者一樣地考慮(也就是使用者會做哪些活動). 主要的活動是:

  1. 送一張生日賀卡
  2. 計畫一個宴會, 然後邀請大家來參加
  3. 送一張結婚紀念卡

突然間各式各樣的點子都出現在你腦海裡. 所以一開始可以顯示如下的選單而不需要用空白卡片:

 

你想要做什麼?
  • 送一張生日賀卡
  • 送一張結婚紀念卡
  • 送一張宴會邀請卡
  • 由空白卡片開始

這樣使用者會突然發現你的程式變得非常容易上手, 他們不再需要先瀏覽功能表了. 因為基本上程式會引導他們逐步完成所有的活動.(這裡會有個風險, 如果你沒有選對活動, 就會疏遠或搞混那些原本會用你的程式的使用者, 比如說要送賀年卡卻找不到選項. 所以要小心挑選能涵蓋大部份目標市場的活動.)

 

光看到這三個活動就會出現很多可以加的好功能. 舉例來說, 如果你正在送一張生日或結婚紀念卡, 可能希望能在明年提醒你寄卡片給同一個人...所以你可能會勾選寫著"明年提醒我"的選項. 另外宴會邀請卡都會需要回覆是否能參加, 所以可以加個功能讓你以電子方式收集回函. 這些點子幾乎是光看到使用者會做的活動就浮現了, 不過看著應用程式的功能是不會想到的.

這個例子沒什麼; 不過對正式的應用程式來說, 活動式規劃的好處就更可觀了. 當你從頭設計一個程式時, 你對使用者會做的活動已經有個想法了. 把這個想法弄清楚一點都不難, 幾乎不必費什麼工夫, 只要和同事做些腦力激盪, 把可能活動都寫下來, 然後決定把重點放在哪些項目. 強迫自己把這些活動寫在紙上, 對你的整體設計幫助很大. 

當你在製作現有產品第二版時, 活動式規劃會變得更重要. 這時候觀察客戶樣本使用你的程式做些什麼事, 可能會是件很重要的事. 

從Excel 1.0到4.0這段期間, Microsoft裡大多數人都認為最常見的使用者活動是做財務上的模擬分析, (比如改變通貨膨脹率看看獲利所受到的影響). 

當我們設計Excel 5.0時開始正式使用活動式規劃, 大概看了五個客戶使用產品之後, 就瞭解到有很多人只是用Excel來記錄清單. 他們完全不會輸入任何公式或做任何計算! 我們以前根本沒有考慮過這件事. 結果發現在Excel中保存清單比其他活動普遍得多. 而這也讓我們發明出許多能更容易地保存清單的功能: 更容易的排序, 自動資料輸入, 幫助你看到清單某一部份的自動篩選功能, 以及多用戶功能(能讓多人同時編輯同一份清單, Excel會自動處理所有衝突).

當Excel 5正在設計時, Lotus推出了一套"全新典範"的試算表Improv. 根據新聞稿說, Improv是全新世代的試算表, 能把之前所有的產品都幹掉. 由於各種奇怪的理由Improv先推出了NeXT版本, 這對產品的銷售當然沒有幫功, 不過卻有很多聰明人認為Improv之於NeXT就像以前的VisiCalc之於Apple II: 它會是個殺手級應用, 會讓人們為了用一個程式而去買全新的硬體.

當然啦, Improv現在已經是歷史的註腳了. 在網路上搜尋這個名字, 唯一找到的是一位太有條理的倉庫經理不知為何所建的網站, 裡面列出他們賣不出去放著積灰塵的存貨.

為什麼呢? 因為在Improv裡幾乎不可能只製作列表. Improv設計者認為大家都是用試算表來建立複雜的多維財務模型. 可是如果他們去調查一下, 就會發現製作列表比多維財務模型常用太多了, 可是在Improv裡就算有辦法製作出列表, 也是非常的麻煩.

所以活動式規劃不光是能幫助應用程式初版(你必須猜測大家所想做的事), 對於打算升級的程式更是有用, 因為你能瞭解客戶正在做的事.

另外有一個來自網路的例子, 就是deja.com的演進, 它剛開始是個名為dejanews的龐大Usenet可搜尋索引服務. 最初的介面只有一個編輯框, 寫著"search Usenet for blah," 就只有這樣. 在1999年少量的活動式規劃顯示, 一般使用者的活動是研究產品或服務, 比如研究"我該賣那一種車子"之類的. 後來Deja整個重新組織過, 現在已經偏向於產品意見搜尋服務了: Usenet搜尋能力幾乎被完全隱藏起來. 這對用該網站搜尋Matrox顯示卡是否能用於Redhat Linux 5.1的少數使用者來說很煩, 卻使得絕大多數只想買到最佳數位相機的使用者更喜歡.

活動式規劃還有另一個好處, 就是能讓你做出一份要做的功能清單. 不管你是要製作任何種類的軟體, 都會發現時間只允許完成1/3的功能. 而決定功能要做或不做的最好方法之一, 就是去評估哪些功能支援最重要的使用者活動.

想像使用者.

業界最頂尖的使用介面設計者都同意一件事: 你必須先創造並描繪虛構的使用者才能開始設計使用介面. 你可以回想我在本書介紹中所說的虛構使用者皮特:

皮特是在某家技術性書刊出版社裡工作的會計師, 使用視窗有六年經驗, 主要在辦公室用, 偶而也會在家裡用. 皮特很能幹而且很技術性. 他會自己安裝軟體; 會閱讀PC Magazine, 甚至還能寫些簡單的Word巨集協助辦公室的秘書開發票. 他家裡有裝纜線數據機. 皮特從來沒用過麥金塔. "太貴了"他會告訴你說"128MB RAM的700 Mhz PC才多少錢..." 好了, 這就是皮特. 我們都知道了.

當你在讀這段敘述時, 你幾乎可以想像出一個使用者. 我也創造了另一類的使用者:

派翠西亞是個英文教師, 出過很多廣為人知的詩集. 她從1980年起就已經用電腦作文書處理, 不過總共只用過Nota Bene (一套古老的學術用文書處理器)和Microsoft Word兩套軟體. 她不想花時間瞭解電腦運作的理論, 而且習慣把所有文件不更改目錄直接存檔.

很顯然的, 設計給皮特用的軟體和設計給派翠西亞的軟體一定會有相當的差異, 當然也和給麥克 (16歲, 在家裡用Linux, 會上IRC聊好幾個小時, 另外絕對不用"Micro$oft"的軟體)用的不一樣.

當你創造出這些使用者之後, 要考慮你的設計會變得容易許多. 舉例來說, 很多程式員都會高估一般使用者弄懂事情的能力. 每次當我寫說命令列使用介面很難用, 總是會收到一堆郵件說命令列功能超強, 因為可以完成像'gunzip foo.tar.gz | tar xvf -'之類的工作. 不過當你想想看要派翠西亞鍵入"gunzip..."時, 立刻就會明白這種介面永遠不會符合她的需要. 考慮一個"真實"的人能讓你有移情作用, 讓你做出符合這個人需要的功能. (當然啦, 如果你是為純熟的系統管理員製作Linux備份軟體, 就得創造像"法籣克"這些的角色. 他拒絕碰Windows, 而且"作業系統"形容Windows時總是加個問號, 用的tcsh是自己改過的版本, 他的機器整天都在執行X11 而且開了四個xterm終端機程式. 另外還同時開了大約11個xperf程式去監看所有電腦的CPU使用量.

總結起來, 設計良好軟體大概需要六個步驟:

  1. 創造一些使用者

  2. 找出重要的活動

  3. 找出使用者模型 -- 使用者期望如何完成這些活動

  4. 草擬出初版的設計

  5. 一直反覆把設計修改得更容易, 直到虛構使用者能輕易使用為止

  6. 找真人來看著他們試用你的軟體. 特別注意人們出問題的部份, 這很可能就是程式模型與使用者模型不符的地方.

良好的使用介面能讓軟體大賣, 不過也會讓人們快樂, 因為這是人們完成想做的事時的反應. 這也說明為何使用介面設計是個能令人滿足的領域. 還有什麼地方能讓你有機會讓數百萬人更快樂一些呢?





文件來源: User Interface Design for Programmers Chapter 9: The Process of Designing a Product (英文) 

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


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

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky