主要原則



如果你不懂得好的用戶界面的設(shè)計，你不可能夠設(shè)計出更有用的程序。讓兩個程序員來考慮同樣的一個用戶界面，將會產(chǎn)生一場爭論。每一個人都會有自己的觀點和看法。但是真正的關(guān)鍵是什么在起作用。因為缺乏客觀的測試，我們不得不依賴于良好的人機對話的通用原則。Jacob Neilsen將其歸納為10條清晰顯著的啟發(fā)式。從我們以往與開發(fā)者工作的經(jīng)驗中我們發(fā)現(xiàn)以下的基本原則是易于學習和易于應(yīng)用到實際設(shè)計決策中的。其中有五項（原則）被非?？鋸埖姆Q為可用性規(guī)則的指標；它們?yōu)楹玫挠脩艚缑嫣峁┝艘粋€框架以及通用的對象。其它六項（原則）則涵蓋了好的用戶界面的特殊方面的準則。

牢記這些主要的準則并不能保證一個好的用戶界面，但是在已發(fā)布的原則的基礎(chǔ)上作出的決策將提高這種可能性。一個觀念是：在一條或更多的已被驗證的準則上而不是在個人觀點和看法的基礎(chǔ)上謹慎且自覺的做出用戶界面設(shè)計決策。這當然不可能涵蓋所有事情；甚至藝術(shù)和美學也沒有被提及。一個好的用戶界面常有圖形的優(yōu)美和可視化的要求。但換句話說，在將美學放在必要用途之前考慮是一種普遍的錯誤，這將導致產(chǎn)生一個漂亮卻難以使用的用戶界面。



第一條準則：可用：一個好的系統(tǒng)應(yīng)該不需要任何幫助和指導，就能被那些具有系統(tǒng)所涉及領(lǐng)域的經(jīng)驗和知識卻對該系統(tǒng)沒有經(jīng)驗的用戶使用。



第二條準則：效率：一個好的系統(tǒng)不會干預或中斷那些對系統(tǒng)有豐富經(jīng)驗的熟練用戶的高效使用。



第三條準則：漸進：一個好的系統(tǒng)在用戶漸漸獲取系統(tǒng)使用經(jīng)驗的同時，在知識，技能，易用性以及適應(yīng)性上有相應(yīng)的持續(xù)改進。



第四條準則：支持：一個好的系統(tǒng)能設(shè)法幫助用戶輕松，簡單，快速而且有趣味地完成任務(wù)。



第五條準則：環(huán)境：一個好的系統(tǒng)可以適應(yīng)于實際配置的環(huán)境中的條件和情況。



結(jié)構(gòu)原則：使用有意義且有用的方法，在用戶所能清楚了解的簡明一致的模型中，將有關(guān)聯(lián)的事物合并，把無關(guān)聯(lián)的事物分離，以此來有意識地組織用戶界面。



簡單化原則：使簡單通用的任務(wù)易于執(zhí)行， 用用戶自己的語言直接溝通，并為長的操作過程提供好的快捷方式。



可視化原則：保持所有需要的選項和材料可視，并避免讓一些外部的或是多余的信息來分散用戶的注意力。和WYSIWYG（所見即所得）相比，我們提倡WYSIWYN：What-You-See-Is-What-You-Need.



復用原則：通過使用外部或內(nèi)部的組件或行為來減少用戶的再記憶或再思考，保持和目標一致性更勝于僅僅武斷而得的一致。



反饋原則：使用對于用戶而言簡明、清晰的語言及時向用戶告知：行動和解釋、條件和狀態(tài)的改變以及錯誤或例外。



容錯原則：靈活和寬容。通過容許不同的輸入和順序，和合理地解釋清楚合理的行為，來避免可能的錯誤；利用“重復”（redo）和撤銷（undo）來降低錯誤或誤用的代價。

基本用例有點象場景，也許更像它們所基于的用例。最好是通過例子來區(qū)分場景、用例和基本用例。場景是對一次非常明確的交互的具體描述。例如，一個用戶撥打計算機控制的幫助熱線的場景： 



Ian Smith在凌晨4點撥通了TechnoTech的支持熱線，他聽到了要求輸入用戶ID的提示。于是他在電話鍵盤上鍵入17682002，此后他聽到了TechnoTech的產(chǎn)品線的菜單。 



不會有人建議專門為一個通宵工作的名叫Ian Smith的人設(shè)計一個系統(tǒng)，但是也很難判斷如何從這樣的場景中獲得通用的案例，以及這樣的一個具體例子當中又包含有什么不必要的細節(jié)。 

用例是一種通用的場景，它描述與特定用戶界面的一種類型的交互。TechnoTech的用例為： 



用戶撥通支持熱線并聽到登錄的提示。之后用戶鍵入用戶ID號聽到菜單。 



用例假定了一個特殊的用戶界面，在該事件中有一個供聲音輸出及數(shù)字鍵入的電話機。在這個用例中還隱含了一個用戶界面的假設(shè)。用戶通過在電話按鍵上鍵入的用戶ID號來鑒別他們的身份，選項被指定為聲音菜單。 

基本用例是一種用于表示抽象交互的廣義的理想化的用例。在這個例子當中它可以用以下的形式表示： 

調(diào)用幫助熱線；鑒別自身；選擇幫助。 



換句話說，場景、用例、基本用例表示了抽象、理想化、一般化的繼承關(guān)系。基本用例被簡化到交互的最小化極點。如果我們仔細的設(shè)計一個用戶界面并使其最接近基本用例。我們會很幸運的設(shè)計出最小而且最易于使用的系統(tǒng)。無論如何，我們要保證始終關(guān)注如何真正的滿足用戶的需求。 

真正的應(yīng)用系統(tǒng)包含了很多相互關(guān)聯(lián)的基本用例。一個用例也許就是另一個用例的特例。例如，在遠程銀行應(yīng)用系統(tǒng)中獲取存款余額（GettingSavingBalance）就是查詢帳戶（QueryingAccount）的特例或是子集。一些基本用戶案例也許作為附屬進程依附于其他用戶案例。例如在一個制圖工具當中，做標記（Labeling）就作為一個設(shè)置員工職位（InsertingStaffPosition）的附屬進程。另一個非常有用的關(guān)系就是由Jacobson提出的擴展（extension）。擴展是在其他用例進行期間插入，用于表示一種選擇或是例外，或是變更交互的一種用例。在一個往文檔中插入特殊符號的工具中，瀏覽符號（BrowsingSymbols）可能是插入符號（InsertingSymbol）的一個擴展。在用戶看不到他們需要的符號時將用到瀏覽符號（BrowsingSymbols）。擴展，特殊化和次要性(?)使我們能夠更縝密的描述應(yīng)用程序的完整結(jié)構(gòu)，因為我們不需要重復的寫入或者拷貝同樣的用例。它們還使我們明白用例之間如何關(guān)聯(lián)，由此我們可以組織用戶界面的架構(gòu)。有時在一個項目開始階段我們不能很好的了解特定用例之間的關(guān)系，但是我們可以認為他們有著共同的一些特性。 



Role me over 

做筆記，這是一次測驗

可用性測試是制作更好的軟件的重要部分。只有客觀的測試才能最終解決關(guān)于什么可以工作什么不能工作等并不清晰的問題。精心構(gòu)造的測試也能夠揭露沒有設(shè)計方針可以覆蓋和沒有專家檢查能識別的可用性的問題?？捎眯詼y試有許多變體，但其主題是簡單的：你使用戶或是有效的替身在一些版本的軟件前就坐并觀察他們試用。你讓他們持續(xù)去做，嘗試，然后通過你觀察分析所得到的就是什么會使系統(tǒng)更有趣，有時，更昂貴。有效的做法就是建立一個可用性測試的實驗室，用成排的計算機和聲視頻設(shè)備裝備起來，再配備上心理學家，技術(shù)人員和人機交互專家。這將使你可以向用戶以及工業(yè)分析員指出可視化體系來證明你對于軟件的可用性的最高優(yōu)先權(quán)的承諾。

現(xiàn)場測試（Field testing）是可用性測試的貧窮的姊妹。它沒有明亮的實驗室供相片成冊，所有需要的設(shè)備僅是筆記本和鉛筆。從另一方面，低預算的現(xiàn)場測試也有一個優(yōu)點，就是它著眼于人們在普通裝備的工作環(huán)境下進行真實的操作時要做些什么。這并不令人驚奇，當技術(shù)人員走出他們的辦公室進入到實驗室時，傾向于以不同方式來思考和行動。測試并不能解決軟件可用性的問題，因為測試來得太晚。正如他們在整體質(zhì)量管理中提及的，你不能有測試質(zhì)量的方式。在促成錯誤，然后發(fā)現(xiàn)它，之后設(shè)計補丁或是其它工作上已花費了太多。一開始就正確地設(shè)計和構(gòu)造它或很早就發(fā)現(xiàn)錯誤將是更經(jīng)濟的。如果不是這樣，就算是擁有成千上萬的beta測試員的大量的測試程序也不能發(fā)現(xiàn)足夠的錯誤。通過測試得到的大量的模糊的不足將被不確定的終止，因為沒有人知道如何去修正他們或是問題已經(jīng)深入以及密切的嵌到在軟件的體系結(jié)構(gòu)當中。你可以利用可用性測試來協(xié)調(diào)好有爭議的特征，或者解決關(guān)于改變方法的途徑的爭論，備份大塊的硬數(shù)據(jù)或大膽的證明新的偏差是正確的，但是你別指望能測試出真正有用的軟件的方法。


通?；居美梢杂赡切椭覀儗⑺伎嫉慕裹c由用戶轉(zhuǎn)向使用的抽象模型中衍生而來。用戶通過不同的角色與系統(tǒng)交互。角色是一種用戶和系統(tǒng)間的抽象關(guān)系。正如軟件方法論學者Rebecca Wirfs-Brock所提出的，它是共同興趣、行為模式、和期望的集合。 

再次思考在線電話目錄應(yīng)用程序。許多用戶僅用中等頻率訪問這個系統(tǒng)，通常是要尋找單個的電話號碼。這些用戶用我們稱之為偶然用戶（Casual Caller）的角色進行交互。通常他們都確切的知道他們需要什么，但是偶爾也只是有一些模糊的、大概的想法或是部分的信息。另一類用戶則是大量地訪問系統(tǒng)，經(jīng)常要和在一個特定的集合或組里的一系列的人聯(lián)系。例如一個特殊職能的小組，或是所有的產(chǎn)品經(jīng)理。公關(guān)助理（Social Coordinator）角色可供秘書、委員會主席或是意圖組織一個排球隊的程序員使用。然而另外一個角色是目錄管理員（Directory Administrator），可以供那些有機會可能向系統(tǒng)加入條目、對系統(tǒng)進行定義或?qū)M重新排列、更改電話號碼的人使用。不同的用例用于支持不同的用戶角色。例如，為了支持偶然用戶角色我們需要開發(fā)一個用于查找一個名字或方位不確定的人的電話號碼的用例。我們把這個用例稱為尋找她（GettingWhatsHerFace）： 



用戶目的 系統(tǒng)反應(yīng) 

這是我知道的 

顯示找到的信息 



『繼續(xù)直至滿意』 

離開 



“我知道的”可能包括姓的第一個字母加上部門名字，可能還是對姓的拼寫的猜測或是電話號碼的區(qū)號。 

這個用例可以被另一個可選用例撥號（DialingNumber）擴展： 



用戶目的 系統(tǒng)反應(yīng) 

給我這個 

撥號碼 



將撥號作為一個擴展分離出來的好處是可以把它作為其它用例的擴展。當以目錄管理員角色創(chuàng)建新的條目時，撥打該號碼檢查是否有效，或者查找已知道確切名字的人時，這個用例都是有用的。 


在上下文中 



用戶角色和基本用戶案例幫助我們了解用戶想做什么以及系統(tǒng)需要為用戶做到什么，但是并不能告訴我們用戶界面上應(yīng)該有什么以及如何組織。我們可能經(jīng)常直接從用戶案例中獲得用戶界面原型，但是通常需要跨越一個很大的鴻溝。 

這有助于我們在不過多顧慮到外觀或者是UI小部件的準確形狀或選擇的情況下考慮為了支持特定用例而必須放置在用戶界面上的部件。我們需要一個抽象模型以便更容易探索幾條不同途徑來使得在不必詳細構(gòu)造及設(shè)計的情況下就可以組織用戶界面架構(gòu)，這就是內(nèi)容模型（content model）。（我們采用Contextual Inquiry中的工作環(huán)境模型的想法，Contextual Inquiry是由Karen Holtzblatt和Hugh Beyer開發(fā)的定義需求的方法） 

內(nèi)容模型是一種對工具和物品，控件和容器的抽象化表示，一個用戶界面需要根據(jù)不同的用戶角色來向用戶提供一種對一個或幾個用例的支持。我們需要一些簡單的形狀――長方形或橢圓形――來表示這些抽象工具。即時貼可以很好的滿足這個需要，因為它們易于移動并且有著普遍的外觀來使我們關(guān)注本質(zhì)而不是用戶界面小部件外觀或性能上的細節(jié)。 



例如，為了支持基本用例尋找她（GettingWhatsHerFace）和撥號（DialingNumber），我們可能在一開始就要定義一些我們認為用戶在實施以下這些相關(guān)用例時所需要的工具和物品。 

工具/控件 

數(shù)字選擇器 

撥號器 

組選擇器 

物品/容器 

名字容器 

找到的人信息的文件夾 



這些最終可能會象圖2那樣排列。注意我們已經(jīng)開始加入一些關(guān)于行為甚至是實現(xiàn)符號的想法。使用上下文模型有點象被我們說的低保真模型。它不怎么象真的屏幕布局或是對話框設(shè)計，但是它需要一些基本元素來支持基本用例。 



深入研究 



基本知識

如果你想要學習可以迎合你的用戶的基本需求的軟件工程知識，看一看這些資料，首先從學習Larry的文章：“基本建模：用于用戶界面的用戶案例”（Essential Modeling: Use Cases for User Interface）（ ACM Interaction April 1995）以及“圖形導航”（Graphical Navigation）（Windows Tech Journal ,August 1994）開始。很多關(guān)于可用性的期刊包括在Constantine on Peopleware（Prentice Hall, 1995）和Jacob Nielson的Usability Engineering (Academic Press, 1993)中。更多關(guān)于用例的書籍，可以查閱Ivar Jacobson 的基于對象的軟件工程（Object-Oriented Software Engineering）（Addison－Wesley，1992）和lane Graham的遷移至對象技術(shù)（Migrating to Object Technology）（Addison－Wesley，1994）。關(guān)于基本建模的經(jīng)典資料依舊是Steve McMenamin和John Palmer的基本系統(tǒng)分析（Essential System Analysis）（Prentice Hall，1984）。


在更復雜的設(shè)計中，當我們要實現(xiàn)不同的用例時，需要仔細地考慮在對話框之間、屏幕之間的用戶導航。為此我們需要一張導航圖來在上下文交互中鏈接用戶導航到交互序列當中。導航圖包括一些表示交互場景的標記符號，和連接他們的標記有轉(zhuǎn)換狀態(tài)的線條。例如，在線電話目錄需要支持由用戶維護的個人列表以及集中的整體列表。如果一個用戶需要編輯整體數(shù)據(jù)庫中某個列表中的一個域，那么授權(quán)機制將檢驗他的權(quán)限。這些我們可以在圖3的導航圖中看到。 

從用戶到用戶界面 


所有這些抽象建模的目的就是為了獲得密切接近用戶所試圖完成的工作的本質(zhì)的用戶界面架構(gòu)設(shè)計。詳細的模型和導航圖將作為用戶界面原型的粗略的向?qū)?。但是依然有很多工作要做，還有很大的空間留給有創(chuàng)意的圖形設(shè)計和明智的軟件工程。圖4給出了明顯未完工的在線電話目錄應(yīng)用的最初紙上原型。在這個版本中，通過微調(diào)基本用例來實現(xiàn)對FindingWhatherFace快速靈活的支持。隨著用戶的鍵入，系統(tǒng)的不斷進行搜索，在下面的帶有可編輯區(qū)域的行的數(shù)據(jù)表格不斷挖掘。一旦根據(jù)用戶填入搜索域的數(shù)據(jù)使得搜索范圍有效的縮小，只要簡單的雙擊所要的數(shù)字或者選擇了數(shù)字后再點擊撥號按鈕就可以進行撥號。 

焦點放在目標和本質(zhì)上，以整個流程的使用為中心。如果不用這種方法，最終的屏幕草圖或是紙上原型看上去可能是有據(jù)可依的，但結(jié)果常常是令人驚奇的難以使用。如同圖5中的設(shè)計，使用了常用的控件和重疊的對話框，這是一種典型的學生式解決方案，但甚至也出現(xiàn)在一些管理個人信息的商業(yè)產(chǎn)品當中，直到你真正使用它時才能發(fā)現(xiàn)毛病。 

盡管這些對于基本用例建模的概述使它看上去是象一個相當線性和嚴格的過程，實踐中我們常常發(fā)現(xiàn)自己可以從柱子跳到即時貼。整個過程在圖6中進行了描述。對于電話目錄應(yīng)用系統(tǒng)，我們始于一個單一視圖的想法，把數(shù)據(jù)庫分成兩部分，個人列表存放在每臺PC上，整體列表放在服務(wù)器上。這確實是一個內(nèi)部應(yīng)用軟件的設(shè)計決策。我們可能會有一個極具靈感的用于撥號按鈕的圖標的想法，一個真實的用戶界面原型的細節(jié)。在我們寫出支持DirectoryAdministrator的基本用例之前，我們也許嘗試了所有的方式來產(chǎn)生用于FindingHerFace的上下文。只有這時我們才開始完成導航圖。 

換句話說，這個策略確實是一個靈活的并行建模過程。所有的基本建模和用戶界面原型對于交付使用都是極其重要的，但是他們不需要一個很嚴格的開發(fā)順序。目標是跟隨工作流程，以任何一種可以方便地構(gòu)筑出簡明而有活力的用戶界面架構(gòu)的方式來工作。