是什麼讓產品或服務可用？

可用性是很多產品都擁有的品質，但更多的產品缺乏可用性。這是很多原因造成的，如歷史、文化、組織架構、金融以及其他原因，這不是本書的討論範圍。好在，仍然有一些通用並可靠的方法可以來評估哪些設計是可用的，哪些不是，並且評判怎樣最佳化設計可以讓一個產品具有良好的可用性，讓產品足以在市場立足甚至蓬勃發展。

看上去似乎很難知道是什麼造就了可用性，因為除非你有一個突破性的可用性範例，可以切實地推動銷售（很容易想起蘋果公司iPod的案例），否則缺乏或喪失可用性僅僅只是一個問題。想象一下顧客想要在你公司的電子商務網站上買東西。他們與網站的對話可能是這樣的：我找不到想要的東西啊。好吧，我找到了想要的東西，但是我不知道賣多少錢。還有現貨嗎？能運送到我想要的地方嗎？我花費這麼多可以免運費嗎？幾乎每一個嘗試在網上購物的人都遭遇過類似的問題。

網站的可用性問題非常容易指摘（畢竟網站那麼多），但是人們每天會遭遇無數其他的難以使用的產品或服務。你知道怎麼用你的鬧鐘的所有功能嗎？手機呢？數碼攝影機呢？當你使用自助販賣機時，根據他們的語音提示做選擇容易嗎？

1 “可用”究竟是什麼

大部分時候，產品使用時沒有挫敗感就具備可用性了。正如本書中所述可用性測試的操作過程和方法，我們需要依託於可用性的定義，即當產品或服務真正可用時，使用者可以用他們自己覺得可行的方式去做他們想做的事情，沒有阻礙、猶豫或疑問。

但在我們開始定義和探討可用性測試之前，先談一談可用性的概念及其特質。一個產品或服務想要具有可用性，它應該是有用的、高效的、有效的、令人滿意的、易學的以及可達的。

有用（usefulness）描述的是產品促成使用者達成目標的程度，以及使用者想使用產品的意願評價。沒有意願，其他衡量標準都沒有意義，因為產品都是擺在貨架上任人挑選的。如果一個產品容易使用，容易學習，甚至用起來也令人滿意，但是沒辦法讓一個使用者達成具體的目標，就算它是免費的也沒有用。有趣的是，有用這件事在實驗室的實驗和研究過程中是最容易被忽略的因素。

在產品研發的早期，通常是由市場團隊來明確哪些產品或系統功能是使用者想要和需要的，影響可用性的其他因素甚至完全沒有考慮。正是由於缺乏這樣的考慮，開發團隊想要站在使用者視角是非常困難的，他們可能只是簡單的猜測，更有甚者把自己作為使用者。這是系統導向的設計經常發生的事情。

高效（efficiency）是指準確完整地完成使用者目標的敏捷性，通常是一種時間上的衡量。舉個例子，你可能會設定一個可用性測試的基準是“95%的使用者可以在10分鐘內下載完軟體。”

有效性（effectiveness）是指一個產品在多大程度上能以使用者預期的那樣執行，以及使用者使用它來完成想要的事情的難易程度。這個通常以定量的出錯率來衡量。正如測量效率一樣，有效性的可用性測試也需要以一定百分比的使用者量來做依據。以高效的案例作延伸，測試基準的描述可能是“95%的使用者在第一次嘗試後就可以正確下載軟體”。

易學性（learnability）是有效性的一部分，和使用者作業系統的能力有關，這種能力水平的定義要經過一定量以及一段時間的訓練（也可能根本沒有時間）。易學性通常也指經過一段時間以後，不活躍的使用者重新學習使用系統的能力。

滿意度（satisfaction）是指使用者對產品的知覺、感受和想法，通常由書面及口頭的問卷來收集。當產品很好地滿足使用者需求，並提供更佳的滿意度時，使用者使用產品的表現可能會更好。一般情況下，要求使用者對試用產品進行評價和排名，進而暴露問題的本質。

可用性的目標和宗旨就是將上述特性以可測量的方式來定義。然而要注意的是，讓產品足夠可用，絕不是單純地生成一串使用和滿意度的數字。當數字告訴我們一個產品是否“起作用”時，同樣也有一個獨特的定性的因素衡量產品可用性如何，這是難以用資料量化來做出判斷的。行為資料可以告訴你為什麼會有這樣的問題，定性因素則影響如何解釋行為資料才能夠解決問題。任何醫生都能夠測量病人的生命體徵，如血壓和脈搏。但解釋這些資料並給每一位特定的病人推薦合適的療程，才是醫生真正的價值所在。為了設計有效的療程，判斷可能引發問題的多個不同原因，並找出哪些有可能是特殊情況，這通常意味著要看得更遠，遠超單個個體資料。沒有經過訓練的雙眼可能會錯過這些細微的差別。

可達性（accessibitity）和可用性相伴而生。就最廣義的理解來說，人們會覺得可達性說的是可以透過產品來完成目標。但本書中談及可達性時，指的是對於身有殘疾的人來說，產品如何更加可用。為身有殘疾的使用者改善產品可用性，或為了某種處於特殊情況下的使用者改善，抑或是兩者都考慮，這種做法通常也會讓沒有殘疾的使用者獲益。為了殘障人士考慮可達性可以使設計清晰簡潔，對於那些遇到臨時的限制（如受傷）或情景的人也有益處（如注意力分散、糟糕的環境條件、光線太亮或是不夠亮）。有很多的工具以及指南可以幫你進行可達性設計（與本書同步的網站上有很多可達性資源連結（訪問www.wiley. com/go/usabilitytesting可以獲得更多資訊）。你應該更加熟悉可達性的最佳範例，以便在組織進行以使用者為中心的設計時，可以與可用性測試以及其他方法共同運用。

可用性和可達性是以使用者為中心設計（UCD）的眾多準則中的一部分，以使用者為中心的設計包含很多方法以及技巧，在本章後面的部分我們會談到。反過來，以使用者為中心的設計來源於更大更全面的概念，叫作體驗設計。顧客可能會在你的網站上完成購買過程，但是如何與之後的事情緊密配合，如商品的運輸、保養、售後服務，抑或是退貨？你的組織如何支援研究並決定購買的過程？所有這些都是體驗設計的重要環節。

這讓我們繼續回到可用性這個話題。

真正的可用性是看不見的。如果事情執行順利，你根本不會注意到它。就像如果房間裡面溫度適宜，那麼沒有人會抱怨。但產品的可用性通常是一個連續的過程。你的產品可用性如何？就算使用者可以完成目標，產品是否還能提升可用性？值得提升嗎？

大部分可用性專業人員花費大量的時間來研究如何排除設計問題，讓使用者的挫敗感最小化。這真的是一個值得稱頌的目標！但是你要知道，要讓使用產品的每一位使用者都達到這一點是非常困難的，對於使用者達成目標來說，這是使用者體驗中影響非常小的一部分，並且就算有定量的方法可以測試產品的可用性，有一些東西的可用性也是沒有辦法衡量的。只能衡量產品有多麼的不好用：使用者使用一件東西的時候會遇到多少問題，這些問題都是什麼，以及造成問題的原因。

在設計的迭代過程中，只有透過綜合評估的方法，如可用性測試，才有可能讓產品和服務更加有用、好用，甚至令人欣喜。

2 導致可用性低下的原因

究竟是什麼原因導致許多高科技產品如此難用？

接下來，我們將研究這個主題，討論這個現象存在的原因，並全面研究問題的對策。書中很多案例不僅僅涉及消費類硬體、軟體、網站，還包括使用者使用手冊和內嵌的電子幫助文件以及錯誤提示資訊。解決方法一併適用於樂器、移動手機、遊戲操控臺，等等，甚至類似超聲波影像操作平臺或數碼相機的使用者手冊都是本書涉及的範圍。

導致產品可用性低下的五大原因

對於當前從事產品研發的工作者，如工程師、使用者介面設計師、技術協調員、培訓專員、管理者等而言，導致產品或系統可用性低下的原因是如此驚人地相似。

聚焦於裝置或系統的研發。目標受眾的擴充套件與適應。可用性產品本身存在設計難點。團隊內各專業人員缺乏協同。設計與技術實現的不匹配。原因一：聚焦於裝置或系統的研發

產品的設計和研發過程，只強調和關注裝置或系統，而非終端使用者。圖1清晰地展示了使用者行為的通用模型。

貝利使用者行為模型指出任何型別的使用者行為都由以下三大因素構成。

人群環境活動

圖1 貝利使用者行為模型

因為系統或產品的研發的目的是提升人類某個領域的表現，設計師應該在設計過程中納入對這三個因素的思考。三個因素都將最終影響人們最終的表現。可惜，設計師、工程師、程式設計師只習慣聚焦在活動這個因素上，而往往不夠重視人群和環境的因素。同時也忽略了三個因素相互之間的關係。出現這種不平衡的狀態可能有以下原因。

一種基本的假設是因為人類與生俱來的靈活性和適應性，所以人們更容易適應裝置，而反過來讓裝置適應人是行不通的。開發工程師歷來更適應看上去“非黑即白”絕對化的、科學化的、抽象聯絡的系統工作。而人類的問題是灰色的、混亂而模糊的。開發工程師被任用和獎勵的原因歷來不是因為他們通曉人性，而是他們具備解決技術問題的能力。人的需求成為忽略因素最重要的原因是，設計師以往設計的產品面向的終端使用者與他們自己非常相近。這自然沒有理由去研究一個跟自己相近的人群。讓我們接下來看第二個原因。原因二：目標受眾的擴充套件與適應

隨著技術滲透了主流消費市場，目標受眾不斷壯大並持續演變。開發團隊無法快速順應這種進化。

早期數字化產品的使用者（早期的嚐鮮者）熱衷於計算機專業知識，熱愛科技、沉醉於修修補補，為自己能搞定任何問題而驕傲。這些數字化產品的開發者有著相似的特質。本質上，使用者和開發者是一體的。正因為這種相似性，開發者只需要為“鄰座”設計，其實就是為你身邊的人做設計。毫無疑問，這種方法相對成功，使用者也幾乎不曾抱怨過使用障礙。

這些使用者怎麼可能抱怨呢？很多使用者享受使用產品過程中需要付出的修補和調整。狂熱的使用者會因為他們能搞定複雜的產品功能而無比自豪。因此，“裝置導向”或“系統導向”的方式自然而然地成為了研發標準。

而今，一切都發生了改變。使用者往往對計算機和機械裝置知之甚少，對購買的產品缺乏調教的耐心，已經完全與產品設計師的設想脫節。更重要的是，現在的使用者遠遠無法毗及設計師，包括技能、資質、期望或伴隨設計過程需要的任何特質。在過去，公司可能需要聘請化學博士操作他們的產品，現在他們會找高中畢業生來完成同樣的操作。顯然，“鄰座”設計方法在面臨使用者和設計師之間巨大差距時蕩然失效。一些忽略趨勢的公司繼續秉承這一策略，將持續生產出可用性低下的產品。

設計師也不再是愛好驅動的狂熱份子。大多數設計師接受過專業的人機互動、工業設計、人因工程學、計算機科學或混合型學科的教育。那些曾經讓不諳技術的人望而卻步的電子化或數字化裝置，而今卻不可避免地被普通使用者在工作或生活中接觸和使用。那些無論是在工作，還是生活中舉足輕重的大眾化產品，如手機、數碼錄影機、網站或精密的測試儀器，他們的使用者都不具備技術素養。當今的使用者需要的是一個工具而非一種愛好。

原因三：可用性產品本身存在設計難點

儘管很多組織將設計可用的系統視為“常識”，但它的困難卻難以預測。

雖然有很多著作提及可用性的方法論，但對於不具有行為學和社會學背景的人而言，卻是難以參透的概念。可用性定義以及如何獲得可用性，既是藝術問題，也是科學問題。似乎每個人對於可用性都有一個概念和實施方法。直到可用性可被衡量，才跳出了概念的範疇（這需要可執行的定義和精確的測量）。

比起拋棄可用性原則的設計師而言，輕視可用性原則更加危險，因為這會招至更壞的結果。正如Will Rogers所說：“產生問題的原因不是你無知的部分，而是你以為自己知道的部分。”很多組織已然將可用性工程漠視為“常識”。

原因四：團隊內專業人員缺乏協同

組織招聘專業化團隊完成產品和系統的研發，卻忽視了成員間的相互協同。

出於提升效率的目的，很多組織將生產流程拆分成相互獨立運作的系統元素。例如，軟體開發的組成要素包括使用者介面、幫助系統和書面文件。誠然，這些要素由獨立的個人或團隊研發。專業化分工本身沒有問題。問題在於獨立要素之間缺乏協同融合，不同研發團隊間溝通不足。

通常產品研發在獨立拆分的部門之間推進。在外界看來，研發的結果會被感知成圖2所示的結果。

圖2 缺乏協同的產品研發

每個研發組像地窖一般獨立運作，最終的產品也反映了這個過程。幫助中心不能給到使用者介面這一層足夠的支援，甚至與使用者介面設計背道而馳。使用者幫助文件因為缺乏交叉索引而出奇地冗長。亦或文件呈現的內容已與最新版使用者介面脫節。這些都可想而知。

產品釋出後問題產生了。終端使用者面對新產品時，期望它作為一個整體工作。如圖3所示。使用者不會刻意區分這三個部分。使用者預期產品的每個部分都應該緊密配合在一起。即便產品有諸多專業化的優勢，也會因為無法滿足使用者預期而失敗。

有意思的是，組織在不經意間加劇了割裂的狀態。他們將產品的各個要素獨立進行可用性測試。使用者文件獨立於使用者介面作測試，使用者介面也獨立於幫助測試。這個方法最終將無濟於事，因為自身可用並不意味什麼。只有產品的各要素配合良好，才能真正滿足使用者需求。

圖3協同式的產品研發

所幸，近年研發方法體系有了長足的進步，開始不斷強調設計迭代和團隊跨學科構成。此外，大量以可用性理念指導下產生的無邊界的產品和服務案例，在市場上獲得了巨大的成功，如Netflix、eBay、Yahoo！、iPod及iPhone、Whirlpool（惠而浦）家用電器最新產品線。它們成功的最大因素是協同研發。

原因五：團隊內專業人員缺乏協同

使用者頁面的設計和技術實現是兩種不同的活動，需要截然不同的技能。現今人們更強調和需要設計技能，而技術實現需要另一種思維模式和技術模式為主導。

設計關注產品溝通方式，技術實現則關注產品運作方式。早期設計和開發的分歧還罕為人知。早期，工程師和設計師被僱傭都是因為他們的技術專長（程式設計和機器導向的思維）而非設計專長（資訊溝通和使用者導向的思維）。這是因為早期利用計算機程式語言完成產品設計是項很大的挑戰，所以情有可原。當然，優雅溝通可以帶來更好的效果，但它不是當時的最高指導原則。

隨著新一代程式語言的發展以及自動化程式設計工具的產生，技術實現的挑戰驟然減小。而為了滿足日益增長的使用者規模，適應他們經驗不足、對可用性期待較高的特質，設計的挑戰陡然增加。就拿計算機做類比，工作的焦點已經從裝置內部（機器如何執行）轉移至外圍的終端使用者（如何與產品互動）。

工作焦點的轉移也趨使設計師技能的變化。設計將逐漸從技術實現中脫離出來。或許有一天，在設計使用者介面時將完全不需要編寫程式碼。

上述 5 個原因只不過初略地闡釋了缺乏可用性的產品和系統不斷出現的原因。更重要的是，這些問題和誤區背後有著共同的主題：過於強調產品本身而忽視了產品本身應該實現的預期效果。尤其當開發週期變得愈發短促而忙亂，對使用者的關注和理解就更愈發少了。

設計師容易對產品設計的本質失察，同時更容易忘記他們正在建立一種產品與人的關係。此外，為了設計這種關係，設計師必須允許使用者專注於手頭的任務，幫助他們達成目標而不是讓使用者關注完成任務的方法。設計師同時需要設計各個產品相互配合的關係。這意味著設計的實體之間可以無間地溝通，同時需要擴大體驗維度，捲入產品的整個使用週期或工作場景。曾經的工作模式已經無法適應當今的使用者和技術了。

我們需要新的方法和技術，幫助設計師轉變視角和方法。這種由外及內的，適應終端使用者的需求和能力的工作方法，就是以使用者為中心的設計方法。基於以使用者為中心的前提，可用性測試才體現價值並得以發展。後面會更詳盡地探討關於以使用者為中心的理念。

3 產品可用性的成因

以使用者為中心的設計（UCD）在過去數十年中被冠以不同的定義描述，如人因工程學、人機工程學和可用性工程（其中人因工程學和人機工程學幾乎可以相互取代，與其區分兩者在方法和實現方式上的差異，不如理解為地域因素導致了兩者的差異。在美國，人因工程學傳播廣泛，而在其他國家尤其在歐洲，人機工程學則更為普及）。以使用者為中心的設計意味著設計可用的產品和系統的各種技術、過程控制、方法和步驟。不過同樣重要的是它是過程中將使用者置於核心地位的哲學理念。

儘管設計團隊必須首先考慮產品技術（如何實現我們的設想）以及功能特性（產品是否完成特定功能），團隊必須同時考慮使用者在使用產品時的體驗問題。以使用者為中心的設計，應以聚焦使用者為起點，同時顧及底層技術的能力和邊界，以及公司設想中希望提供的功能特性。

在設計過程中，UCD會遵循目標使用者實際使用方式，而不是強勢地改變使用者使用產品的方式。國際標準組織（ISO）第13407條規範這樣定義UCD：“捲入使用者並清晰理解使用者和任務目標；恰當地配置使用者因素和技術因素於產品功能中；迭代式的設計解決方案；多學科融合的設計活動。”

超越以使用者為中心設計一個產品，應該關注使用者對一個產品的擁有權的整個閉環體驗。在理想情況下，整個過程包括與潛在消費者的互動、從最初的銷售和營銷觸點貫穿到被使用者購買其他產品或換代當前產品的全過程，都是以使用者為中心應涉及的問題。在這樣的情景下，公司應該進一步關注包括所有售前售後與使用者的接觸點和互動內容。不過，讓我們先邁進一步，聚焦設計過程的探討。

現在有很多文章或書籍關於以使用者為中心的設計（UCD）（在隨書的網站www.wiley.com/go/usabilitytesting上列舉了一些我們喜歡的文章和書單）。然而重要的是，讀者應該理解UCD的基本原則，以便理解可用性測試操作實況。可用性測試並不是UCD本身，它僅僅是幫助實現一個優秀的以使用者為中心的設計的諸多方法中的一種。

我們希望著重強調以使用者為中心的設計有以下幾點基本原則。

及早聚焦使用者和使用者任務。評估和測量產品使用方法。迭代式設計。及早聚焦使用者和使用者任務

僅僅辨識和分類使用者還不足夠，我們建議貫穿整個研發週期，設計團隊和使用者直接接觸。當然，你的團隊需要接受訓練和指導，以便更好地管理接觸使用者的過程。你自己也有必要承擔起更多的學習和練習。

使用者接觸過程需要一個目標來指導，要警惕只是簡單地在使用者行為滿意度表格上打滿勾勾。真正需要的是系統化和結構化地收集使用者資訊。設計師需要專業採訪以及組織資料蒐集等工作技能的訓練。此外，結果應該確保不產生誤導。

評估和測量產品使用方法

這裡，我非常強調在設計過程早期就應該針對真實使用者，透過開發和原型測試，開展易學性和易用性的行為測量。

迭代式設計和測試

我們一再重申迭代式設計的重要性。不過，在整個開發閉環中並沒有真正執行到位。真正的迭代式設計鼓勵透過測試早期概念原型和設計創意徹底檢查和反思設計。如果設計師不準備投入這麼重要的步驟，就將導致迭代式設計影響極少，流於表面。本質上，真正的迭代式設計鼓勵產品形成的過程經歷設計、測試、再設計和再測試的迴圈。

實踐UCD的組織的特性

以使用者為中心的設計要求大部分公司反思自身的商業舉措、產品研發和目標消費人群。儘管，目前沒有現成的保證成功的公式，不過能實踐UCD的公司具備一些共性特質，如下所示。

強調卷入使用者資訊。多學科背景團隊。參與式的開明的管理。“隨時隨地習得”的洞察力。明確的可用性目的和目標。1．強調卷入使用者資訊

與傳統開發方法論中強調內容不同的是，一個以使用者為中心的方法是在進入下一研發階段前，在本階段回收使用者反饋或輸入資訊。這會捲入各種技術和可用性測試手段。

如今，最主流的以技術驅動的產品或系統開發的公司，會在產品研發週期內捲入若干可用性工程或人因學工作過程。在過程中，會產生一些問題。問題和一些針對性的改進建議請見圖4。

圖4 問題和對應的解決方法

每個階段的可用性工程事項是不同的。注意，儘管特定的研發週期的人因學活動是出自專業人員的判斷，但仍然有多處工作需要跨團隊協作。所以下文就是我要道出的UCD團隊特性。

2．多學科背景的團隊

設計不再是一個人甚至一個專業人員能獨立掌控的。雖然一個設計師可以主導產品設計的多重職責，但依然沒法瞭解所有的環節。為非技術背景的終端使用者設計一個非常複雜的產品需要考慮太多的因素。以使用者為中心的設計要求多樣化的技能、知識，以及最重要的目標使用者特徵和使用方式。如今，團隊由多領域的專家構成逐漸成為一種標準配備，如工程學、市場、培訓、使用者介面設計、人因學和多媒體等領域。多個領域的專家轉而在互補的領域得到培訓，因此交叉原則的工作較以往更容易展開，也更有活力。

3．參與式的開明的管理

將可用性納入運作體系，通常與公司管理層是否順應公司階段性發展需要，利用條例保證設計團隊獲得充分話語權有緊密關聯。管理者知道可用性將帶來經濟價值並贏得市場份額。

4．“隨時隨地習得”的洞察力

UCD是一個伴隨產品最終成形的進化過程。它要求設計師具備一種觀念，最佳設計是在試錯、發現和最佳化的過程中產生的。關於推進過程的假設，如果不能被實物化並經歷終端使用者的評估，終究還只是一個假設。終端使用者的表現和偏好將決定設計決策。

5．明確的可用性的目的和目標

設計一個可用的產品必須基於一個結構化和系統化的過程，同時在啟動初期設定了高標準的目的和具體的目標。模糊和錯誤的構想無法實現包括可用性在內的各種目標。你的團隊甚至需要明確定義“可用性”本身。讓你的產品具備可用性的可操作定義可以包括以下幾種。

有用高效有效性滿意度可達性

這幾項從本質上全面定義瞭如何生產可用的產品。我們現在來回顧下一名可用性專家在完成以使用者為中心的設計時常用的技術和方法。

4 實現可用性的技術

UCD是在產品開發週期的不同節點中應用不同的技術、方法和實踐工作。回顧常用方法可以提供可用性測試一些場景。可用性測試本身就是諸多方法中的一種。請注意下文描述的技術被提及的順序從一定程度上代表了它們應用到一個產品開發週期中的順序。

4.1 人機工程學研究

人機工程學研究借鑑於人類學學科體系。它在實際使用場所中觀察使用者（如工作場所、家、咖啡吧等），收集目標使用者是誰，他們需要完成的與產品相關的任務和目標是什麼，以及他們要完成目標的場景。透過這一定性研究，就可以構建使用者輪廓、人物畫像（典型使用者）、情景和任務描述。基於此，你和設計團隊可以在整個開發週期中獲得設計決策的依據。

4.2 參與式設計

UCD與其說是一門技術，不如說是具象化的過程。參與式設計是邀請一位或多位使用者代表參與到設計團隊。這個方法通常用於家用系統的研發專案。在專案一開始就捲入終端使用者參與設計的核心環節，以便標記使用者的知識、技能，甚至對設計的情緒反應。使用者代表過於融入設計團隊是一種潛在的風險。他們不再以自己原本的方式反應和思考，相反他們更傾向於避免訓誡團隊工作人員，隱瞞重要的顧慮或評論。

參與式設計可以有一些技術調整，安排短暫的獨立式的工作坊，讓使用者、設計師和開發就一個具體的設計問題工作在一起。例如，使用者、設計師和工程師用一個可工作的原型，一起完成產品最佳尺寸和外形的推敲打磨。

4.3 焦點小組研究

使用者焦點小組研究是在專案非常早期讓使用者代表參與評估初步概念的過程。焦點小組研究可以理解為概念可行性的檢驗。某些時候，可以同時區分和確認代表使用者的型別。所有的焦點小組研究會把多個被試者安排在一起，這是該技術有別於其他技術的重要因素。

小組共同參與評估的概念可以用非常雛形方式呈現，比如手繪鉛筆稿、故事版、螢幕上詳細描繪的原型或塑膠手板模型。目標是探明概念的可接受程度，使用者在哪些地方無法接受或感到不滿意，哪些改進可以使設計更被接受和更有用。焦點小組研究的美妙之處在於可以深度研究小部分人的評判和感受，同時學習到終端使用者是如何思考和感受的。這樣，焦點小組對比可用性測試，是截然不同且無可替代的。焦點小組適合收集大體的定性的資訊，不適合研究表現和真實行為。記住，焦點小組裡的人表達的是主觀感受，往往會跟他們的真實行為相左。可用性測試適合觀察行為和測量表現，順便結合部分定性資訊的收集。

4.4 調研

在執行調研時，可以開始從較大基數範圍理解使用者對現有產品或潛在產品的偏好。儘管調研無法覆蓋焦點小組研究縱深地研究反饋和設計依據，但可以從全量人群中收集大量的樣本。比如，尼爾森量表，現行最流行的調研量表，曾基於1 500人的偏好研究全國數百萬美金的商業決策。調研可以用於產品週期的任意時段，其中大多數時候用於早期研究潛在使用者。調研至關重要的一點是必須保證語言描述清晰，所有閱讀者都不會產生歧義。調研如果沒有多輪測試和充足的準備時間，就不能保證好的效果。此外，再重申一遍，詢問使用者會怎麼做或做了什麼永遠無法替代在可用性測試中直接觀察他們的行為。

4.5 走查

一旦明確了誰是你的目標使用者以及任務目的，走查就可以在概念早期或產品原型階段，以使用者視角研究一個使用者將如何對待一個產品。通常，設計師需要引導他的同事走查真實使用者的任務（有時甚至要扮演使用者的），同時另一個組員記錄使用障礙或對團隊的顧慮。結構化的走查由IBM在程式碼檢查的工作中被首次開創使用。執行被試者設定一個具體的角色（如主持人、記錄員），並且在清晰的指引下完成任務，確保操作效用（走查過程不應超過2小時）。與其讓設計師扮演使用者的角色，不如邀請真實使用者特別是領袖型使用者進來。

4.6 封閉式和開放式卡片分類法

卡片分類法用於研究內容或功能的“可查詢性”。這個方法可以有效地獲得使用者關於內容組織、文案措辭和使用者介面標籤等方面的反饋。你既可以向被試者展示沒有標題的內容或分類，讓使用者自己命名（開放式卡片分類），也可以向被試者告知初步的或已有的分類並請他們往裡面自主分組內容或功能（封閉式卡片分類）。

4.7 紙面原型

在紙面原型的技術中，需要在紙面上向用戶展示產品的一個部分並詢問相關的問題或從另一個角度瞭解使用者的反應。也可以在草稿上用鉛筆手繪頁面稿、線框稿、幾個分屏介面、幾個頁面或由不同狀態的面板組成的框架稿，在逐一展示給使用者的過程中發現使用者的預期與預設的匹配程度。例如，在一個電子商務網站關於購物車的原型中，可以展示一個有待購商品的購物車的頁面，接下來裡面的商品發生了一些變化，接著運費和稅費增加了（或者，在進展到下一部分時，直接跟使用者再設定出有待購商品的購物車）。

如果需要研究標籤對使用者預判下一步的作用或預設的分組是否符合使用者對任務的思考和表述，可以向用戶展示一級導航。使用者給出一級導航的選擇時，可以展示下一級相應的導航內容。這個過程可以持續到你設計或準備的導航深度。

當然，也可以直接就原型詢問使用者。問題比較寬泛，可以針對組織形式和佈局的具體表現，也可以關於使用者對特定選擇或資訊型別的預期。

紙面原型的價值在於透過快速而便捷的方式獲取關鍵性資訊。在沒有寫一行程式碼之前，設計師就可以確認哪些功能和特性是符合預期的，哪些不是。此外，技術文件撰寫人也可以利用紙面原型的技術在撰寫之前先行評估內容列表。這項技術可以以最小資源投入反覆應用。

4.8 專家啟發式評估

專家啟發式評估是捲入一個不瞭解專案的可用性專家或人因工程學專家對產品或系統進行檢查。專家們會根據符合研究主體的可用性原則（啟發性的）、人因學文獻以及已有的專家級經驗來完成評估。得出的觀點將針對使用產品的目標細分人群。

雙重專家既深諳可用性原則或人因工程學，又對某個領域（如健康、金融服務等）或產品運用的專項技術很在行。雙重專家可以讓啟發式評估更加有效。

4.9 可用性測試

可用性測試，本書的核心是觀察具有代表性的終端使用者完成真實任務，並憑藉經驗採集資料。測試可以簡單地分為兩大類別。一類測試比較正式，要求執行真實的實驗來證明或證偽某些假設。第二類測試則不那麼正式但依然嚴格，要求以迭代式的測試來發掘可用性缺陷，並逐漸完善問題產品的形態。

4.10 追蹤調查

追蹤調查應用於正式產品釋出之後。目的是透過調研、採訪和觀察為下一次產品釋出收集資料。結構化的追蹤調查或許是最可信和最準確的可用性評估技術了。因為能保證真實的使用者、產品和環境作用在一起。不幸的是追蹤調查的方法很少採用，因為設計師可能需要耗費兩年的時間研究產品才有可觀的收穫。銷售資料的好壞固然有一定價值，但也無法幫我們認識到產品的優勢和劣勢。

上述這些無論如何都不是不可更改的方法集合。這裡也不太可能為讀者評估出執行UCD所需的各種技術資金投入程度和複雜程度。很少有組織會實施所有的技術，也不太會以原始單純的形式實施技術。通常情況下，這些技術會根據具體需求和專案限制作出調整和融合。

本文節選自《可用性測試手冊（第2版）》

內容提要

可用性測試是讓一群具有代表性的使用者對產品進行典型操作，同時觀察員和開發人員在一旁觀察、聆聽、做記錄的測試方法。

本書針對可用性及其測試方法進行了全面的介紹。全書內容分為14章，分別介紹了可用性、可用性測試、測試內容、測試主持人的技巧、制定測試計劃、測試環境的建立、確定被試者、準備測試材料、執行測試環節、與被試者和觀察者回述、分析資料和觀察、彙報研究結果及建議、基礎方法的變化、從可用性測試到使用者體驗設計等內容。

本書適合一切從事可用性測試行業的讀者以及其他類似互動設計師、產品經理、系統架構師等職業的讀者參考閱讀。