開發流程中的可用性 (轉)[@more@] Corporation
2000年10月

摘要：本文討論反覆、週期性的設計過程，包括以為中心進行設計的四個原則、兩種型別的產品設計過程，以及可用性活動如何滲透產品開發的各個階段併為其帶來益處。

#uicycle_topic1">簡介

可用性測試為您帶來的好處

簡言之，如果將可用性測試從產品開發週期的一開始一直貫徹到專案的每一階段中，將使您在最後的處理過程中省去重新開發這一環節。

本文首先討論重複、週期性的設計過程。第一部分闡述了以使用者為中心進行設計時的四個原則，這是由 Gould、Boies 和 Lewis 提出的。接下來介紹了兩種型別的產品設計過程：“瀑布式”方法和“螺旋式”方法。本文的其餘部分將簡要介紹產品開發的各個階段，並討論可用性活動是如何滲透各個階段並帶來益處的。此處所述的開發階段包括：構思、規劃、開發、穩定化以及為下一版本做準備。

在您閱讀各小節時，請注意使用者將頻繁地參與到各個過程中。使用者對每個階段的介入將會在專案的收尾階段為您省去成本高昂的返工工作，而且這樣開發出來的產品將使使用者樂於使用、易於學習，並會長期使用。

反覆、週期性的設計過程為以使用者為中心進行的設計帶來了極大的便利。以使用者為中心的設計有四個重要原則，這些原則是由 Gould、Boies 和 Lewis 於 1991 年提出的：

及早以使用者為中心：設計人員應當在設計過程的早期就致力於瞭解使用者的需要。
綜合設計：設計的所有方面應當齊頭並進發展，而不是順次發展。使產品的內部設計與使用者介面的需要始終保持一致。
及早並持續性地進行測試：當前對測試的唯一可行的方法是根據總結出的方法，即若實際使用者認為設計是可行的，它就是可行的。透過在開發的全過程引入可用性測試，可以使使用者有機會在產品推出之前就設計提供反饋意見。
反覆式設計：大問題往往會掩蓋小問題的存在。設計人員和開發人員應當在整個測試過程中反覆對設計進行修改。

多年來，“瀑布式”的產品設計過程是軟體設計的標準。在這一方法中，專案開發透過分階段發展的、按順序的各個階段進行。這種方法使用重大事件作為轉變點和評估點，並認為在下一階段開始前，前面的每一階段均已結束。“瀑布式”的方法對於複雜的專案很有效。在複雜的專案中，多個供應商負責專案的各個方面（例如，一個供應商負責需求分析，另一個負責規範，等等）。但是，使用這種方法可能導致隨著專案的進展，對專案進行更改越來越難。

相形之下，“螺旋式”的產品設計過程卻是反覆、週期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。這一過程允許更大地發揮創造性，並且更易於隨著專案的進展而對專案進行修改。在進行螺旋式的設計過程時，您會發現可在各個階段對產品各方面的功能進行設計。這種方法可為以使用者為中心的產品開發過程帶來便利。

螺旋式的產品設計過程有六個階段：構思、規劃、建模、開發、穩定化以及為下一版本做準備。

產品開發的構思階段是確定專案的目標和範圍的階段。此階段要確立構思陳述、設計目標、風險評估以及專案構架。

在構思階段，通常進行下列可用性活動：

環境研究

基於 Beyer 和 Hotzblatt 於 1997 年出版的 Contextual Design 一書中所述的方法，此型別的研究包括觀察使用者的所做所為，使您更為直觀地瞭解使用者行為。如果您尚未決定究竟要開發何種軟體，但認為存在市場機會，就可使用環境研究來對活動進行研究。您可瞭解可為使用者做些什麼以及實現的難易程度。不是尋求具體的功能，而是尋求設計機會。

環境研究為專案提供工作的重心。如果專案是全新的專案，或是較全面的升級，這種方法最為適用。在進行較全面的升級或開展全新專案時，您無法全面瞭解使用者在做什麼、如何做、以及他們所面臨的問題或困擾。而進行較小的升級時，您有可能從產品支援部門、先前的研究等處獲得這些資訊。在這種情況下，您基本上是對現有的設計加以完善，所以環境研究並不是不可或缺的。

環境研究在以下情況最為適合：專案組進行跨學科的環境研究，小組由可用性工程師帶領。

競爭性測試

透過競爭性可用性測試，您可以為產品設定量化的可用性目標 — 任務完成的速度、每項任務出錯的數目，等等。這種方法可對專案的成功與否進行量化的度量，即使所進行的競爭只是人工過程，而您將對此過程進行自動化。競爭性測試經常用於市場開發。當市場開發代表對競爭對手進行評估時，他們只比較產品的功能。可用性測試則更側重於使用這些功能完成任務時的。

競爭性測試對僅用於公司內部的產品來說，似乎不大適用。但是，如果仔細考慮，從理論上而言，您也是在與產品的先前版本或前一個流程競爭。內部產品可能與人工過程進行競爭 — 產品必須比現有的程式更有效、更好。

進行競爭性測試的方法之一是開展研究，比較與其相競爭的產品的效能。例如，對其他人員的產品進行效能研究。在選擇要測試的競爭產品時，要考慮到之外的產品：如果產品涉及線上交易，則競爭性產品就可以是電子貨幣。從研究結果中您可以確定使用最頻繁的、最重要的功能。

使用者/受眾分析

瞭解您的使用者！儘可能採取各種方法來了解您的使用者的特點。考慮一下如果您基於產品終端使用者的特點來開發軟體，可減少多少技術支援電話的數量。設想一下使用者是否認為產品易於使用並且包含了他們所需的功能。問自己“對於我要建立的產品，哪些使用者特點是與之相關的？”，例如：

計算機使用經驗
年齡
接受培訓的程度
使用者群之間的社會關係
特殊要求（可訪問性）

您可以透過環境研究來獲得一些此類資訊。例如，您可對一些使用者進行觀察以得出一些假設，然後透過調研或取樣來驗證這些假設。您的人力資源部門或培訓部門可能會具有一些相關的資訊；例如每個新僱員要接受多少培訓。市場研究人員也可能有此類資訊。對於公司內部使用的應用而言，收集這些資訊有時會比對外出售的應用程式簡便，因為您的使用者是具體的群體而不是普通大眾。

規劃階段是進行首次實際設計的階段。在此階段中，有關使用者介面的早期設想將初步成形，並著重於先前階段未涉及的知識。原始模型可以是任何形式，如描述概念或功能的卡片、螢幕的簡單描繪圖紙、列印在紙上的螢幕點陣圖圖形，用 Macromedia Director 之類的程式建立的帶有有限互動功能（也稱為“點閱”）的聯機版本，或是用 HTML 或 Microsoft ® 建立的帶有大量互動功能的聯機版本。在大多數情況下，您會發現原型具有的模擬度越高，使用者建議進行重大修改的可能性就越低。所以，用寫在紙上的原型來開始著手測試是非常值得采取的做法。

根據您所設計的產品種類，您可能需要進行下述的一些或所有活動。如果您在規劃階段花時間來完成這些任務並使用原型，則在開發階段碰到的可用性問題將會大為減少。

使用者情況

建立您自己的使用者情況概要，列出產品的典型使用者能做什麼，不能做什麼。透過早期的環境研究和使用者/受眾分析，您做出一些較高階別的決策，基於這些決策進行軟體設計。使用使用者情節，您可建立一個有關使用者使用您所設計的軟體的“故事”。這些情況可以是情節串聯圖板、聯機 Macromedia Director 電影、簡單的流程圖、或簡單的敘述性文字。一種比較精緻的使用者情節是“日常生活”錄影。這種錄影把演員作為“使用者”顯示，這些使用者在日常活動中與模擬的進行互動。透過使用者情節可得出您在任務分析時要尋找的具體細節。

任務分析

任務分析決定了在新產品中任務的方式。在撰寫規範之前，必須首先進行任務分析。用任務分析來確定您所規劃的支援的任務是否確實能夠反映現實，這一點是很重要的。對任務的逼真度進行分析。就產品的特性而言，任務的完整性如何？分析逼真度意味著觀察使用者完成一項任務所必須執行的所有操作；或進行表象的觀察，瞭解使用者完成所有任務或功能所需執行的所有操作。無需擔心過於詳盡 — 把重點放在實質內容上。

一些要考慮的問題和活動：

此環境中的任務是什麼？環境研究應能幫助您找出並描述使用者所執行的任務。
建立順序圖，描述使用者執行的任務之間、使用者和產品之間的相互作用。
在構思階段確定功能的作用領域。提出問題：“我們要支援的具體任務是什麼？”
與產品設計者一起建立情節串聯圖板或順序簡圖。

啟發式評估

啟發式評估涉及評估人員小組，這些評估人員檢視介面並基於基本可用性原則來對其做出判斷。啟發式評估允許您在整個反覆式設計過程中查詢並更正可用性問題。如果您在工作進展的同時糾正問題，您將在收尾階段節省大量工作。因為在收尾階段，更改真實程式碼將更加困難而且成本更高。

如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，啟發式評估包括以下步驟：

每個評估人員都瀏覽數遍介面，檢查各種對話方塊元素，然後將其與一些已知的可用性原則相比較。
評估人員相互合作，將結果合併到列表中，列出使用者介面中的可用性問題，並註明設計方案中違反的相關可用性原則。
一旦每個評估人員都分別執行了啟發式評估後，他們就集中起來將其評估結果合併在一起。

在開發的早期階段，啟發式評估可能是發現可用性問題的非常有效的方法。

認知性遍歷

認知性遍歷的意思是，仔細檢查介面要求使用者執行多少步驟以及何種步驟後，才能完成某項任務，其中包含使用者必須經過思考才能完成的那些步驟。您需要關注的是使用者必須什麼或使用者必須進行的計算 — 認知性任務決定學習和使用您的產品的難易程度。認知性遍歷可幫助您找出潛在的可用性問題，以及找出您制訂的規範中的破綻！

根據 Gregory Abowd 的 Perfong a Cognitive Walkthrough，要進行認知性遍歷活動，需要以下四個條件：

對系統原型的詳盡描述，例如初級規範可提供什麼樣的系統。這種描述不一定是完整的，但要相當詳盡。諸如選單的位置或措辭這樣的細節也可能導致相當大的差異。
對使用者在系統中要完成的任務的描述。該任務應當是大多數使用者將要執行的有代表性的任務。
一個完整的、書面的操作清單，列出使用給定原型完成任務所需執行的操作。
指出使用者的身份，以及評估人員能夠假定這些使用者已具有哪一類別的知識和經驗。

有了這些資訊，評估人員可執行一遍上文第三項所列的操作，從而確定使用者是否能夠按預期要求合理執行這些步驟。

GOMS

GOMS 是描述任務和使用者執行該任務所需知識的方法，它是透過目標 (Goal)、運算子 (Operator)、方法 (Method) 以及選擇規則 (ion rule) 四個方面進行描述的。

Card、Moran 和 Newell 提出了原始的 GOMS 模式。他們還建立了一個簡化的版本，即擊鍵級別模型 (KLM)。BonnE. John 開發了並行活動版本 CPM-GOMS，而 David Kieras 則開發出定義更為嚴謹的版本：自然 GOMS 語言 (NGOMSL)。所有這些技術都基於同一 GOMS 概念。

不言自明，目標就是指使用者的目標。使用者使用軟體要達到什麼目的？在下一天、下幾分鐘、下幾秒鐘？
運算子是指軟體允許使用者採取的操作。
方法是子目標和運算子經仔細設計後得出的序列，可用來實現諸如剪下和貼上等目標。
選擇規則是使用者要遵守的判定規則，以確定在特定環境下要使用的方法。

GOMS 模型由對方法的描述組成，這些方法是達到目標所必需的。方法是一些步驟，這些步驟包括使用者為達到目標所需執行的運算子。如果有一種以上的方法可以達到目標，則需使用選擇規則來確定在此情況下哪種方法更為適用。

卡片排序

卡片排序是一種可用性技術，用於此階段的早期，以瞭解使用者關於資訊的總體模型。卡片排序的基本任務是要讓參與者按卡片上的說明對卡片進行組織，將屬於同一類的專案堆放在一起。在建立好堆後，參與者還可為所建立的堆建立名稱、標籤或說明。

卡片排序用於：

展示使用者對於任務範圍的總體模型。
展示使用者如何對專案進行分組或分類的。
展示使用者對專案之間的關係和相似性的看法。
將使用者的概念模型轉換為設計。

反覆可用性測試

對原型設計的反覆可用性測試是另一種很有價值的方法，用於在產品週期的早期階段確定介面是否易於使用者使用。在此階段進行更改比等到開發階段開始後再進行更改要更容易些，並且成本更低。

您從可用性實驗室可以收集的資料量取決於原型的強健性。對於紙上原型測試，可用性工程師就是計算機，並且在測試的過程中與使用者在一起。

在許多種情況下，嚴謹的可用性測試是過猶不及的。在建模階段，您仍可使用簡化的方法進行有效的可用性測試，這些方法通常稱為“打折扣的”可用性測試。

如 Jakob Nielsen 所述，反覆的可用性測試包括：

使用者和任務觀察 — 觀察使用者，保持安靜，讓使用者做一切通常情況下會做的操作。
情況 — 使用一種可以減少功能數量、降低功能級別的建模方法。
簡化的對談式測試 — 一次安排一個使用者完成一組任務，並要求使用者“發現問題就直接告知測試人員”。
啟發式評估 — 基於基本可用性原則來評價介面。

開發階段是將產品用實際的程式碼來實現的階段。在此階段中，您可以對實際產品的早期版次進行可用性測試。您仍有可能不時要用到原型，但隨著時間的推移產品將逐漸完善。不是所有的功能都將在開發階段同時完成，所以您有可能在原型和實際程式碼之間往復轉換。

在理想條件下，您將可以把大部分時間用來進行推敲，在建模階段就能夠找出主要問題。

真實程式碼測試

讓使用者測試真實程式碼版本可能會有助於針對在計算機上使用產品發現問題。這些問題更有可能是設計問題而非概念問題。它們通常涉及相當低階的互動作用問題，如在螢幕上選擇專案、拖放，以及僅在實際產品中才有的動態圖形。對於產品的大多方面，真實程式碼不一定比設計上的原型或其它模型的真實度更高，所以不要拖延到有真實程式碼後再進行可用性測試。

可用性實驗室測試

在開發階段，您可進行可用性實驗室測試，該測試類似於規劃階段的反覆可用性測試。但是，由於產品的更多部分已趨於完善，您可測試更多工。您仍可在 Director 中使用模型，或將稍做修改的版次用在可用性測試中。隨著時間的推移，產品會越來越完善，原型就越來越不象一個模型了。但是，用“已完成”產品進行測試的問題在於，由於已進行了如此之多的工作，剩下的時間如此之少，您就不能指望對發現的問題做太多的修改了。

注意： 作為此任務的一部分，您還可能進行焦點組分析或群集分析，以對產品進行可用性測試。

當開發結束、錯誤已修正後，就進入了穩定化階段。在此階段中，要建立一個可發售的穩定的產品。在此階段對可用性進行測試的重點是進行微調。新的功能以及代價高昂的可用性增強功能應被記錄下來，以備下一版本使用。

基準測試

對可用性進行基準測試類似於“質量保證”中的綜合測試。基準測試的目的是透過測試使用者想要完成的所有頂級任務，就產品的可用性提供可靠的量化資料。這些測試的目標與其說是要找出問題（雖然找出問題是大多數可用性測試的目的），不如說是要評估產品可用性的狀態。

要進行基準測試，請首先觀察產品的功能，然後將這些功能按任務細分。在穩定化階段，特別是對於複雜的產品，您將不能對使用者介面進行可提高每個任務效能的修改。理想情況下，您可以確定哪些是頂級任務，並且確保大多數頂級任務都是可用的。低優先順序的任務的可用性可以較低，可記錄下來在將來的版本中再作改進。

將此階段視為開始對過程進行回顧的階段。您將全面考慮在構思階段和規劃階段所進行的許多相同任務。例如，您將進行：

競爭性測試 — 在穩定化階段，這種測試是對自己的產品進行測試，以將其與先前收集的有關競爭產品的資料作比較。
現場研究 — 類似於環境研究（該研究是要了解“我們要做什麼軟體？”），使用您已構建的軟體來找出存在哪些問題，可在下一版本加以解決。
關於事件的工具化版本研究 — 軟體的工具化版本基本上用來觀測軟體自身並在發生事件時記錄資料。您在大量會話和使用者的基礎上對產品進行測量以找到使用趨勢。

文獻和書籍

Boehm、Barry W.Software Engineering Economics. NY: Prentice Hall, 1981.(ISBN: 0138221227)
Dumas、Joseph S. and Janice C. Redish.A Practical Gu to Usability Testing. London: lect Books, 1999. (ISBN: 1841500208)
Helander、Martin、Thomas K. Landauer and Prasad V. Prabhu, eds.Hanook of Human-Computer Interaction. North-Holland, 1997. (ISBN: 0444818766)
John, B. E. "Why GOMS?" ACM Interactions, vol. 2, no. 4 (1995): 80-89.
/Sitesrv/Technote/ss3depl.asp">Microsoft Site Server Development Guide
Nielsen, Jakob. Usability Engineering. Boston: AP Professional, 1994。(ISBN: 0125184069)

組織

（英文）：UI 從業者的最大的組織。
（英文）。有關合約資源請參見顧問目錄。
（英文）。
（英文）：參見其顧問目錄以獲得合約資源。

其它聯機資源

認知性遍歷（英文）
（英文）
/?RLD=262">Microsoft 解決方案（英文）

請以 IE4.0 以上版本 800 * 600 瀏覽本站

開發流程中的可用性 (轉)

相關文章