（是的！這只是一個讀書摘錄，里面沒有一句話是我自己的！）

第一部分? 研究

第一章 ?用戶研究

問題：如何才能發現人們想要實現的目標？如何幫助用戶實現這些目標？

概念：

焦點小組：一種用戶研究方法。研究人員把某一品牌的產品，一項服務，一個新設計方案，一臺設備或一個相似的產品展示給一群人然后記錄下來這些人的主觀反應和意見，以此來預測普通公眾對產品的反應。

難題：用戶也不知道自己想要的真正是什么。

第二章 工作觀察和情境訪問

概念：

工作觀察和情境訪問這兩種方法用于觀察人們的行為，發現他們需要幫助的地方，并查明產品該如何給用戶提供幫助。

流程：

觀察目標人群

工作觀察：直接觀察用戶的行為，在目標人群使用我們產品的場所內觀察用戶，目的是為了找出產品應該如何幫助用戶實現目標。提出以下問題：用戶是否在某項任務上花費了大量時間？用戶是否在重復做某件事情？用戶是否在用權宜之計完成某件事情？用戶在做的某些事情是否很無聊，或者讓他感到很厭煩？用戶是否被迫記住某項任務的操作步驟，技術事項或其他可以用電腦來完成的事情？用戶使用電腦時是否使用其他工具？

情境訪談：工作觀察之后，就用戶所做的事情詢問一些問題。包括以下幾個方面：除了我今天看到的之外，你是否還經常要做別的什么任務？你最常解決什么樣的問題？你為什么用這種方式做這件事情？如果完成任務還需要一些別的信息你會怎么做？你經常打交道的人都有誰？你們是如何做的？如果你需要的某個人沒有上班或者發生了其他問題，你需要做些什么？

遠處觀察

情境訪問的局限性：用戶可以想象自己處于某種假想狀態。

第三章 用戶模型

概念：

用戶模型：用戶模型是虛構的人，代表了特定的目標用戶群體。創建用戶模型之前必須進行用戶研究。用戶模型提供了一種方法，把從用戶研究中獲取的信息，合成為有限數量的假想人群。

用戶模型的優點：

迫使你聚焦產品所要解決的問題。通過創建少量用戶模型，你就可以清晰的定義出產品的用戶。

使得對用戶的討論更加容易，通過深入考慮目標用戶，能幫助你改善設計流程。

用戶模型的缺陷：

用戶模型的彈性太大。用戶模型實際上是假想的人，不能為自己進行辯護。因此它有時會強化預先定下的結論。

用戶模型使設計師免于所有艱辛的工作，比如和實際用戶接觸，測試設計決策的有效性等，從而走向“以人為中心“的反面。

創建用戶模型是一件非常耗時的事情。

討論假想的人會讓人感覺不自在。

對于比較小的設計團隊來說，用戶模型益處不大。

創建用戶模型

情境訪談：創建簡化的用戶模型，覆蓋大部分目標用戶群體的使用目標。

每個用戶模型都必須有明確的目標。為什么這類人會使用你的產品？他們想通過產品實現什么樣的目標？

為用戶加入一些相關設計細節。如每個用戶模型技能水平如何？年齡，性別？是否比其他用戶重要一些？是否要首先滿足他的目標即使會對其他用戶造成負面影響？用戶使用什么樣的設備？

加入一些設計之外的用戶模型的個人信息。

為用戶模型設定一副肖像，取個名字。

注意：用戶模型無法代替用戶研究

第四章 以行動為中心的設計

根據所設計產品的不同，把行動作為設計的焦點可能更有意義。

進行用戶研究，找出你所要支撐的用戶行為，但不要為了特定人群而制造出使用行為。

嚴格評估用戶反饋。有時，某些因素可能會讓產品在某個特定用戶群體受歡迎，但也會讓其他人不喜歡你的產品。

以行動為中心的設計考慮的是用戶行為，針對這些行為設計產品，而不考慮特定的用戶或用戶模型。它不是讓產品去適應用戶，而是以用戶能夠適應的方式設計產品。

第五章 文檔編制

概念：

文檔編制：使用手冊 ? ? 博文 ? ? ?截屏視頻 ? 新聞稿等，在開發之初就制作這些東西，被稱作“逆向作業”。

使用手冊：編制使用手冊可以迫使設計師思考設計的細節，如果某些東西很難解釋清楚，那么它可能會很難用需要重新考慮它的設計。把使用手冊當成是產品的一部分，像對待產品的其他功能一樣對待產品手冊。

博文：博文是另一種介紹產品功能的重要工具。幫助人們了解產品，幫助設計師發現產品潛在的問題。你能毫不費力的解釋清楚人們關注改功能的原因嗎？你能描述出該功能有多簡便嗎？如果沒有，改變設計方案。

截屏視頻：可用來介紹新產品或現有產品的新功能。

新聞稿：在發布產品之前就發布新聞，這樣能弄清楚公眾對產品的態度，而不是我們自己內部的觀點。

討論產品的任務

第六章 ?文字的可用性

如果可以，不要使用文字

如果無法避免，使用精煉含義明確且可以略讀的文字

使用短小精悍的段落，每段文字闡述一個主題

保證文字具有吸引力和個性，而不是枯燥無味或過于專業

用插圖闡明要點，讓文字更加平易近人

使用大號字和易于辨識的字體

第七章 用戶界面設計中的層級結構

考慮如何布局產品元素的層級結構。

使用層級結構向用戶提示產品的工作方式，產品的各個界面應該向用戶顯示隱性或顯性的層級結構。

第八章 卡片分類

概念：

卡片分類：人們認為產品的某些部分應該出現在某些特定的位置，卡片分類可以幫助我們搜集這些信息。如果產品比較復雜需要對其內容進行分類，如果你正在設計一個網站，需要決定如何組織各個頁面或者正在開發具有多種功能的應用程序要用用戶可以理解的方式對其功能進行組織分類，可以考慮使用卡片分類技術。

卡片分類的方法：

準備工作：準備一些帶有編號的卡片，在卡片上寫下要進行分類的內容。不要把相差很遠的層級內的東西混在一起，可以為不同層級的信息進行多次卡片分類。卡片上詞語的含義要顯而易見易于理解。卡片總數要控制在20~80張，還有準備一些空白卡片。

參與人員：可以讓一個參與者進行也可以讓多個參與者同時進行。多個參與者的情況比較難以協調進度，一個人的話不存在這種情況。但多個參與者可以互相交流，激發出很多有價值的見解。每次執行卡片分類的參與者不能超過3~4人。每次用戶研究最好進行15次。

執行卡片分類：用戶把想在同一屏幕看到的功能放在一起，有些詞語無法理解是可以刪去自行填寫。確保參與者能理解每個卡片的含義。記錄參與者提出的想法和問題，如果參與者提出了一些新詞匯，可以為其制作額外的卡片。如果參與者分出的組中只有很少的卡片，鼓勵他們把相似的組合并到一起，如果分出的組內有很多卡片，鼓勵他們進行更細的劃分。也可以進行“封閉式”卡片分類：事先定義好分組。讓參與者把他們認為放在哪里都不合適的卡片放棄。分完組后為每個卡片組進行命名。分組夠多時，對分組進行排列把認為有聯系的組放在一起。最后，收集數據。

遠程卡片分類：

評估結果：如果在卡片分類之前已經預先定了一些分組 ，那么計算出某個卡片在每個組內出現的頻率，就能得到大部分人希望這個卡片所表示的內容出現在什么地方。如果分組是由參與者定義，那么首先要重新定義這些分組，有時不同的人會用不同詞匯描述同一分組，要把這些分組合并起來。確定好分組后，再次計算每個卡片在所有組內出現的頻率。然后可以構建出產品界面的層級結構，應用到產品的視覺布局和信息架構上。

可用層級結構的創建準則：

允許同一內容在多處出現：創建一個寬松的層級結構

深和淺的問題（點擊次數的多少）必須控制呈現給用戶的選擇數量，不要超過七個。

關于分組：良好的分組便于用戶瀏覽大量可用的選項。

第九章 心理模型

1.用戶的心理模型不一定必須正確，只要和產品的行為方式一致就行了。

2.三種不同的模型：

用戶大腦中的產品工作原理，也就是用戶關于產品的心理模型

產品在用戶界面中呈現的方式，稱之為“UI模型”

產品實現功能的過程，稱之為實現模型

在理想產品中，這三種模型應該是一致的

3.隱藏產品功能的實現細節

在 UI模型應該向用戶隱藏實現模型的復雜性 和 UI模型應該與實現模型保持一致 之間權衡。簡化用戶界面才能使大部分用戶擁有美好的體驗過程，但這意味著UI模型可能無法與實現模型完全一致。

4.抽象漏洞

當出現抽象漏洞時，即隱藏的實現細節被泄露給用戶時，用戶會發現自己的心理模型無法與產品的行為方式相匹配

5.為心理模型而設計

首先，需要找出人們對事物工作原理的認知：通過與用戶進行交談找出他們大腦中預先存在的心理模型。然后進行卡片分類，找出用戶對相匹配事物的認知。再利用紙質原型進行可用性測試。向用戶展示你的設計方案，描述一個交互過程，詢問他們有何期待。

隨后，設計出與之相匹配的用戶界面，一定要保證用戶需要學習的東西少而簡單。如果你發現用戶在使用產品時的心理模型總是錯的，那么可以嘗試改變產品的外在表現。

幫助用戶形成有效心理模型的七個用戶界面設計原則（《心理模型與可用性》）：

原則一 ?簡單

原則二 ?熟悉 ：你的產品應與相似產品保持一致，與現實世界中產品的工作原理保持一致，這樣，用戶才有可能形成正確的心理模型。

原則三 ?易于識別 ：不要讓用戶回憶如何做某些事情，而是要為他們提供一些有助于理解當前選項的提示或顯而易見的選擇。

原則四 ?靈活 ：如果可以，允許用戶以任意的順序使用不同的技術執行操作。

原則五 ?反饋 ：要經常為用戶的交互動作提供即時有效的反饋。但如果加入的反饋機制過度或不清晰，會讓人們更加迷惑。

原則六 ?安全 ：用戶的操作應該是無害的。如在關閉一個未保存更改的文檔時，在損壞已更改的內容之前應該給用戶提供反悔的機會。

原則七 ?功能可見性 ：用戶界面元素的設計應該向用戶提示界面元素的交互方式。傳達可行交互方式的設計細節稱為功能可見性。好的設計師會讓用戶看到適當的操作，隱藏不適當的操作。

第二部分 ?設計

第十章 草繪與原型

在清楚想要設計的產品后，進入詳細設計階段。首先草繪出產品的結構，然后設計出各個屏內所要顯示的內容。前提是，你需要對產品的最終模樣有明確的想法。

產品結構設計 ：流程圖和故事板只關注產品的整體結構，與細節無關。

流程圖：解決以下問題：用戶要如何操作才能得到自己想要的東西？要按什么樣的流程執行操作？選擇最為重要的用戶目標，然后考慮這些目標所需的步驟。

故事版 :通過繪制故事版把用戶路徑分解成一系列的快照圖片。故事版通常會忽略分支，而僅關注交互細節。用戶究竟在每一屏內看到了些什么東西？你想讓用戶做什么？你需要在什么地方使用動畫或圖像來幫助用戶理解他將要做的事情？

草繪 :完成產品的結構設計之后，就要開始設計各個屏幕顯示的內容。通過流程圖和故事板已經明確了設計的產品需要哪些界面，每個界面需要提供什么樣的功能。現在要確定各個屏幕中要顯示的內容。用簡單的草繪圖說明各個屏幕顯示內容的基本效果。

線框圖 :用來展示屏幕所顯內容的結構，但沒有任何修飾。考慮線框圖中應該包括哪些文本，這些文本應該放在哪些地方。

實體模型：在線框圖的基礎上加入修飾或是視覺細節，實現“功能可見性”。制作產品原型的目的是探索最終系統的具體特征。

工具：Balsamiq和Mockingbird用來創建并分享自己繪制的用戶界面草圖。Google Drawings繪圖模塊支持多人協同設計。

第十一章 紙質原型測試

概念：

紙質原型測試：在繪制了產品草圖的情況下進行可用性測試

打游擊式紙質原型測試：在這個階段你已經有了產品的靜態原型。要展開紙質原型測試，需要準備產品某個界面的草圖，線框圖或實體模型，并且要足夠詳細。然后找個愿意花5分鐘測試的人，向他們展示這些產品界面，問他們一些常規問題或一些簡單的與任務有關的問題。這種測試能讓你大概了解用戶是否理解你的設計，以及哪部分用戶不能理解。

完整的可用性測試：典型的產品原型展示的只是最終產品的一小部分，一般無法包括最終產品的所有界面內容。因此，產品原型的可用性測試總是基于某些特定任務進行的。進行完整可用性測試的流程：首先，確定測試任務。選擇那些對產品來說非常重要，你覺得可能會比較難用或者可能會存在問題的功能進行測試。然后，制定出使用產品這些功能的任務。如果需要的話，你還可以利用早期進行用戶研究得到的信息來制定測試任務。記住測試的目的是觀察測試者與設計方案進行交互的過程，從而找出交互設計存在的缺陷，所以一定要選一些能夠讓測試者真正使用產品的任務。其次，創建紙質原型。準備用戶將在測試任務中遇到的所有屏幕顯示內容，不能太過粗糙。在需要的地方添加一些產品運行環境的用戶界面元素（如為網頁界面設計草圖加上瀏覽器）。創建測試所需的彈出元素。為測試者準備一些在產品原型上修改數據的方法。在獨立的紙張上打印出測試任務。對每個任務進行測試運行，確保你已經準備好了所有可能用到的屏幕顯示內容和彈出元素。

測試的準備工作：還需要一個執行測試任務的人。一般來說，用自己公司之外的人來進行測試。最好的做法是邀請3~4個人，每個人進行兩三小時的測試，這樣你就有時間在測試中仔細檢查已發現的問題，相應的對紙質原型做出一些改變。設立一名“協助者”向測試者介紹測試流程，給出任務，回答測試者提出的問題。讓測試者簽署一份同意錄像的表格。

準備測試者:

執行測試：協助者一定不能影響測試者。產品原型中一定要杜絕出現術語，提問測試者的用詞越常規越好。協助者要避免做出任何讓測試者感到不安的舉動。“電腦”的任務是根據測試者的輸入更新產品原型。在測試者完成第一項任務后，協助者和“電腦”可以花幾分鐘詢問那些不能在測試中問的問題。詢問測試者對整個測試過程的感受。

分析測試結果：不要對測試結果做任何統計學或形式化的評估。可用性測試提供的是定性數據，不是定量數據，對這類測試的結果進行形式化分析會產生誤導作用。

何時停止測試？測試是不會停止的。它是開發過程中一個持續不斷的部分。

第十二章 ?寫實主義

賦予應用程序或網站一種實物的外觀和行為是一種非常好的做法。這種一致性有助于人們理解產品的工作原理還能幫助人們理解用戶界面所能提供的交互方式。

符號：當前用戶界面中的大部分視覺元素都代表某些概念或行為。如“小鉛筆”代表“編輯”，“停止”標志代表“發出警告”。為圖像加入細節會減少其普適性，而缺乏細節的按鈕設計只是一個原型。

實物的虛擬版本：視覺寫實--復制現實世界中的某個物體，創建其虛擬版本--能幫助用戶形成與產品進行交互的心理模型。然而，讓用戶迅速形成固定的心理模型并不總是件好事，這會讓用戶在使用產品前就對產品的工作方式產生某種特定的預期。即，采用的寫實主義的視覺元素設計，那么交互方式的設計也應該寫實。

模擬自然約束：找到現實世界的復制品和產品可用性之間的平衡點。在很多情況下，不要試圖在電腦屏幕上模擬現實世界的物體及其約束條件，而是最好找一個利用電腦技術優勢創建的用戶界面。

第十三章 ?自然用戶界面

CLI（命令行界面） ?：預先定義的一系列文本命令的交互==》GUI（圖形化用戶界面）：基于隱喻的交互，用圖標表示數據和命令==》NUI（自然用戶界面）：基于對真實物體進行直接自然的操作的交互

盡可能允許用戶直接操作產品

對所以的用戶操作給出即時生動的回饋

把那些并不操作對象，而是激發命令的用戶手勢僅僅作為快捷方式，而非主要的交互方式

確保用戶不需要學習復雜的手勢

確保用戶不需要做出精確的手勢，給予用戶輸入的自由，但要允許他們撤銷錯誤的輸入

運行自然用戶界面的硬件特別容易把用戶的無意操作理解為信息輸入。盡可能阻止偶發性輸入；如果發生偶發性輸入，提供應變方案

如果可能，復制現實生活中的行為。讓電腦以用戶能夠識別能夠理解的方式立即做出響應。

參考流行軟件的做法

定期讓實際用戶對用戶界面的交互原型進行測試

第十四章 菲次定律

菲次定律：在桌面系統中，用戶能快速點擊到那些較大或比較接近于鼠標指針的目標。動作的方向也是影響因素之一，目標的形狀應該與動作方向一致。

任務的難度系數（ID）=log2（目標距設備指針的距離/目標在運動方向上的寬度 ?+1）

屏幕邊緣具有無限大的尺寸：屏幕的角落位置很容易點擊，因為那里有兩條邊界。

放射式環境菜單會減小平均移動距離：如果鼠標指針所在位置處有菜單彈出，在指針周圍布局各個菜單可以有效減小到達每個選項的平均距離。

較小的目標需要設置外邊界

有時，屏幕元素越小越好。如破壞性元素設計的小一些能有效降低用戶在無意之中點擊到的概率。

在不同的可點擊元素間保留一點間距

第十五章 動畫

解釋狀態的變化：模擬兩種狀態之間變化過程的動畫能讓狀態的改變和兩種狀態的關系顯而易見。

引導用戶的注意力：制作動畫的目的是夸大狀態的改變，讓用戶無法忽略正在發生的事情。最有效的提醒應該是映入視野內，消失，然后每隔一段時間再次出現的事物。

避免使用不重要的動畫：只有當你真正想打斷用戶，強迫他們關注某些東西，用動畫來傳遞相關信息時，才使用動畫！

幫助用戶形成恰當的心理模型：動畫所傳遞的信息應該與用戶界面的其他部分保持一致

向卡通漫畫學習：實體感：在動畫中重現物體的實際形態更有利于讓用戶明白當前正在發生的事情。讓用戶與動畫中的物體進行交互，而不要呈現給他們物體的輪廓或其他占位符。

夸張：沒有先兆的動作會顯得突然，僵硬而且不自然。你可以利用所有現實中可能有的效果，讓屏幕上發生的事情變得更加明顯。

加速與減速：模擬實物的緩入緩出。

用戶界面并非卡通漫畫：動畫會分散人的注意力。為了增加產品的趣味性而犧牲可用性是得不償失的。

第十六章 一致性

人們擅長于識別用戶界面元素，所以界面元素沒有必要都一模一樣

同類界面元素一定要有相似的外觀，相同的行為方式，因為人們會嘗試把已有的心理模型應用于相似的界面元素

如果你必須創建出與常用界面元素行為不一樣的設計，一定要確保視覺上存在差異，這樣人們才不會形成錯誤的預期。

第十七章 可發現性

“可發現性”是指用戶是否能夠發現并使用產品的某些功能。

哪些功能要易于發現？

首先，要確定的是應該使哪些功能更易于讓用戶發現，哪些功能不易于被用戶發現。有時，甚至可以隱藏某些功能，但前提是要知道那些需要該功能的人能夠發現如何使用該功能。

然后，確定重要功能的重要程度，不能把所有功能都設計的同樣明顯。

在以下情況，可以讓某個常用功能不那么容易被發現：

雖然人們不知道產品的功能，但這毫無影響。

雖然該功能沒有直接顯示在用戶面前，但用戶自己能找到它。

該功能十分誘人簡單且經常被使用，人們知道之后就會記住它。

何時讓用戶發現？

做法一，使用環境化或模態化用戶界面

做法二，只有用戶選擇了支持這些屬性的對象時才將其顯示出來

如何讓用戶發現？

空間屬性：可以利用諸如大小，位置，形狀和顏色之類的屬性，讓程序中的某些元素更容易或更不容易被發現。

用戶期望：界面設計要保持一致，每一屏采用相同的布局方式。如果用戶已經建立了產品工作原型的心理模型，通常你可以利用這種預期來讓某些內容更容易或更不容易被發現。

搜索：提供搜索功能；保證用戶能很容易的找到搜索功能；確保搜索功能可以返回有用的結果。

動畫：謹慎巧妙的使用。對于長時間顯示的內容堅決不要使用動畫。

第十八章 ?不要打擾用戶

不要打擾用戶。打擾用戶會讓他們不高興，降低其工作效率，其本身也是不禮貌的行為。

幫助用戶做決定而不是向他們提問題。

如果不能幫助用戶做決定，一次問完所有需要的問題，而不是每次遇到新問題時都打擾用戶。

如果你必須告訴用戶某些事情，保證盡量不打擾用戶，這樣他們才能按照自己的時間安排處理這些事情。

第十九章 用“撤銷”取代對用戶的干擾

在用戶做出某些具有潛在威脅的事情之前提出警告并不會奏效，因為用戶會忽略這些警告信息。

允許用戶撤銷他們的操作，這樣才能避免發生意外。

如果“技術”不支持撤銷操作，至少要延遲具有潛在危險的操作，這樣即便用戶發出了命令，也仍然能夠阻止事故的發生。

第二十章 模式

模式是應用程序中用戶必須正規的進入或退出的一部分，在起作用時，它限定了可執行的操作行為。--卡羅琳羅斯

人們在現實生活中通常不以模式的方式工作，因而面對計算機軟件中的模式問題時，這更強化了他們對電腦非自然不友好的印象。--卡羅琳羅斯

隱性模式

模式是界面中引發錯誤迷惑不必要的約束和復雜性的重要根源所在。

讓模式顯性化的一種方法是提供視覺反饋，暗示某一模式處于激活狀態。若靜態視覺反饋無效也可以使用動畫。還可以使用動覺反饋或音頻提示。最好嘗試解決這一問題的各種方法，然后進行可用性測試，看哪一種方法更有效。

意外模式

對話框是一種特殊的模式。對話框常常出乎用戶意料之外，因此它會引發與隱性模式一樣的問題：用戶界面沒有實現用戶想要的結果，因為它不在用戶期望的模式之下。而且對話框還會讓用戶的輸入誤以為是針對模式化對話框的，而不是針對先前處于激活狀態的窗口的，這種情況被稱為“偷換焦點”，這樣會導致一些不希望出現的操作。

難以退出的模式

用戶通常不能明顯看到該如何退出被激活的模式，這就會引發可用性問題。如果要使用模式，一定要讓用戶明確知道如何退出模式。

模式并非一無是處

在需要的時候，模式可以用來表面產品的功能，而非模式化的界面在任何時候都必須提供大量無能的用戶操作。只有那些隱性的意外的難以退出的模式才是不好的設計。

準模式

“準模式”是指那些只要用戶明確的保持激活就能存在的短暫模式。如shift鍵，按住鼠標拖動等。如果要使用模式，考慮一下準模式能否解決。

第二十一章 用你的觀點代替偏好設置

產品的設定方式：

設置：用戶對你的產品功能或行為所能做出的全局性更改。

配置：產品正常工作所需的設定，比如屏幕分辨率或網絡設定。

偏好設定：改變產品行為的設定，通常不是嚴格必須的，但某些人或許會比較喜歡這些選項。

個性化設定：純粹實現某種視覺效果的設定，不會改變產品的實際行為，比如桌面背景。

為什么偏好設定不好？

偏好設定會以各種方式給你的產品帶來完全沒有必要的復雜度。

現實中總有一種對大多數人都有效的方案，你要做的就是找出這個解決方案。

給出隱性的偏好設定：不要讓用戶專門設定產品行為，而是要記住用戶上一次的操作。如：不要讓用戶設定窗口的默認尺寸，而是使用用戶上一次縮放后的尺寸作為默認窗口尺寸。

第二十二章 ?層級結構，空間，時間以及我們對世界的看法

層級結構

有時，層級結構很有效，但結構一定要清晰，能被大眾用戶所接受。

如果每個人都要自己設定層級結構，那么它的作用會降低，尤其是多個人共用一個層級結構時。

空間

如果你的產品能利用人類這種對空間的感知能力，能讓用戶對他們的數據在空間中進行布局，那就去做吧。

用戶期望在自己設定的位置找到某個東西，一定不能背著用戶改變某些東西的位置。

當用戶對大量內容進行管理時，空間系統顯得有些乏力。

時間

根據產品的不同，可以讓用戶以某種時態視圖來訪問數據可能會比較有效。

更好的層級結構

限制深度：如果只能讓用戶創建較淺的層級結構，他們不太可能會迷失其中。

空間中的層級結構：比如，只要一個文件夾里放置的應用程序不超過9個，就可以通過文件夾的圖標看到里面的程序。

允許用戶在多個地方放置內容：通常各個項目并沒有十分明確的歸屬，層級化的文件系統應該允許用戶把相同的文件放在多個地方。

支持標記和其他元數據：允許用戶在層級結構中對各個項目的元數據進行操作，這樣他們就可以組織管理那些無法通過層級結構表達的數據。

支持以其他方式訪問數據：要允許用戶以非層級結構的方式訪問數據。比如，允許用戶搜索數據。你要考慮用戶可能會用何種方式搜索或瀏覽數據。

第二十三章 ?速度

速度比功能更重要，速度不僅僅是一項功能，也是一項用戶需求。而可用性測試無法暴露出產品在速度或是反應度方面的不足。

響應度：在可能的情況下，最好能保證操作能在0.1秒內完成。

進度反饋：如果某個操作的完成時間超過0.1秒，你就要提供一些反饋信息，明確的告知用戶，電腦已經接收到他們發出的信息，正在處理。

對速度的感知：改進速度感知的一種方法是先盡快顯示結果，只要找到結果就馬上顯示出來。另一種方法是，確保持續時間較長的操作不會卡住產品的用戶界面，使用戶可以在此過程中做其他事情。最后一種方法是，在進度條上顯示一條與進度成反方向運動的條紋，這樣會讓進度看上去快一些。

慢一點：非常快的產品也惹人討厭。如滾動操作。如word軟件手動保存按鈕，保存太快沒有給用戶明顯的反饋

第二十四章 ?避免不斷加入新功能

謹記用戶的目標：人們并不關心你提供什么樣的工具，只關心工具能做什么。

五個為什么：在收到用戶反饋信息時，多問為什么來找出他們真正想要實現什么。通常，不必要為產品加入新功能就能找到用戶問題的解決方案。用戶真正想要的是什么？他們想用添加的新功能解決什么樣的實際問題？

提升已有功能的可用性：如果大量新要求都能通過產品當前的功能集滿足，那么你應該花些時間改進產品已有的功能。只有當雖然新功能與現有功能相同或相似，但其使用方法更好更易用時，可以考慮用新功能代替就功能。

一舉多得：不要單獨地加入新功能，把相似的功能當做一類問題解決更有意義。

成本：除了考慮新功能所能帶來的收益之外，還要考慮實施該功能所要付出的代價。

隱形的功能：增加一項有用的功能的同時不加重用戶的“認知負擔”。如改進文本渲染功能，使產品創建的文檔更好看。為網絡應用程序增加支持HTTPS訪問功能。

提供API和插件架構：讓其他開發者介入進來，就可以避免實施那些僅對部分用戶有用的功能，而將這一工作留給其他開發者。

傾聽用戶的心聲：在加入新功能前要進行適當的用戶研究，找出用戶真正想要的功能以及使用該功能的目的。

不能太聽信用戶：如果你滿足了所有“我只需要這一個功能”之類的請求，最終的產品會充斥著大量不常用的功能。

不必讓所有人都成為用戶：“少即是多”。

第二十五章 ?去掉某些功能

問以下問題：

如果只有一部分用戶使用這項功能，是因為產品的設計目的就是如此嗎？還是說這項功能非常重要，使用率不高是因為功能本身就有問題？

究竟是因為用戶界面難以理解，還是功能被隱藏了起來，或是名字沒有取好導致只有很少人使用這項功能？如果用戶知道如何使用，該功能的使用頻率會不會增加？

這項功能被忽略的原因是不是僅僅因為它毫無必要？

使用率低只是產品可能存在問題的指標之一，不一定說明你應該去掉某項功能。如備份程序的大部分用戶很少使用恢復功能，但不能去掉。

如果決定要去掉某項功能，告知用戶，在執行決策之前從用戶處取得一些反饋信息。

提供一些備選方案，如為要去掉的功能獨立開發一款較小的附加產品，將產品的舊版本維持一段時間等。

第二十六章 ?向電子游戲學習

樂趣是什么？面臨富有意義的挑戰和任務；有一種方法來衡量自己是否更接近于完成挑戰；擁有克服挑戰的能力。

產品與游戲的區別：

游戲要提供任務，而產品不需要。你的產品不是游戲，用戶會自己找任務，如創建一個演示文檔或找到某個特定的信息片段。

游戲要控制難度而產品不需要。把挑戰設計的看上去很難，同時保證人們能夠完成它。

我們能從游戲中學到什么？

進度：度量某件事情的進度并提供反饋信息，能讓一項活動更加有趣。

技能成長：游戲會隨著玩家技能的成長變得更難。如果能做到的話，產品的用戶會向更難的問題發出挑戰。把用戶保持在“流暢區域”內，挑戰的難度應該與用戶的技能相匹配，產品需要隨著用戶技能的成長而成長。

探索與獎勵：用戶發現了產品的新功能或作出了某些正確的操作，系統給予用戶獎勵。

競爭：用比賽和成績來吸引用戶更多的使用它們的產品。

搜集物品：

一致性規則：規則應該是完整且非常明確的。如果主宰產品的規則是模擬兩可或不可重復的，那么用戶將無法形成關于產品工作原理的正確心理模型。

趣味性和可用性

雖然不是所有可用的產品都能讓用戶獲得樂趣，但所有有趣的產品必須具備可用性--否則，它只能讓用戶覺得沮喪。

讓產品充滿樂趣是非常不錯的目標，但永遠不能以失去可用性為代價。

第三部分 ? ? 實施

第二十七章 游擊隊式的可用性測試

概念：

游擊隊式可用性測試：可用性測試通常都需要邀請別人到你跟前，這會帶來很多問題。因此，到用戶那里去，而不是讓他們到你這里來。

在可用性測試之前，你應該已經開始編寫代碼，至少有一部分用戶界面已經可以工作了。且產品能在便捷設備上運行。

測試頻率：不需要做任何準備，隨時可以展開。

測試的準備工作包括：把產品安裝到便捷設備上，保證產品可以運行，設計出一些簡單的測試方案。

到附近的咖啡館找一些人，或者在你所工作的辦公大樓里找那些有空閑的人，詢問他們有沒有時間花5分鐘做測試。

如果找到測試者，向他解釋測試過程和產品的前期知識，并給他一項簡單的任務。

不要打擾測試者，除非你覺得測試者正在變得沮喪或卡住了。做測試記錄。

在進行數次測試之后，你會找到用戶界面仍然存在的問題。修正這些問題，再次進行測試。

第二十八章 ?可用性測試

可用性測試的成本并不一定很高。以盡可能低的測試成本獲得好的測試結果，即便是差勁的可用性測試也能得出一些有用的結果。

測試頻率：每周抽出半天來進行測試。盡早看到新設計方案的效果能讓你更興奮，無論它能否解決問題，是否會引發新的問題。

測試者的數量：觀點--僅僅五個用戶基本上就能找出一個較大團隊所能發現的所有可用性問題。只邀請一個用戶進行測試是有缺陷的。如，沒有其他任何東西與所得測試結果對比。費勁準備的測試只產生了一個結果。但也有一些明顯的優點，如，可以很容易的找到人測試；不需要調整多個人的日程安排；可以很容易的自己開展整個測試，不需要額外的人來接待照顧那些等待的人。

產品測試對象：不要浪費太多的時間在某個特定群體中招募測試者。大部分時候，無論背景如何，人們總能發現相同的可用性問題。

不同類型的測試：

有主持的任務測試：由協助者主持測試，并向測試者介紹不同的產品行為或測試任務。主持人在測試者執行任務時觀察其行為。在測試過程中，協助者和測試者呆在一起，并與他們進行交流。

無主持的任務測試：協助者向用戶介紹可用性測試，并解釋所有界面元素的工作原理。協助者在紙張上寫下一系列工作原理，交由用戶完成，然后離開測試房間。在這種測試中，測試者和協助者之間沒有交流，排除了協助者可能會對測試者產生的影響。

自由測試：協助者不給測試者分配任務額，而是鼓勵測試者自己探索產品，做自己想做的事情。如果你找到的測試者已經對產品產生了興趣，這種做法獲益最大。

如果正在開展基于任務的測試，你要先準備好測試任務。任務不能有固定的完成方式，描述出任務場景，讓用戶自己思考解決方案。

第二十九章 ? 現場測試

現場測試是指你邀請一些用戶，觀察他們使用產品時的情形，并利用所得信息改進產品的過程。

有主持的任務測試：

1.測試者是否能識別出產品是什么？如果測試者識別不出，你就發現了第一個可用性問題。

2.要知道測試者是否知道如何使用產品?準備一些測試任務，把每一項任務單獨列在紙上。遞給測試者寫有任務的紙張，保持沉默，觀察測試者行為。

3.問完所有問題后，請測試者對測試過程進行評價。

無主持的任務測試：

離開測試現場。事先說明當測試者遇到某類困難時應該怎么辦。

自由測試：沒有測試任務，目標是觀察測試者在不知道下一步應該做什么的情況下的反映。只要向測試者介紹一下測試，然后讓他自由擺弄產品。

以樂觀的態度對測試做出總結。

用常規方法對測試結果進行評估。找出最緊迫的問題并修正它，然后再次測試。

如果不確定某個問題是否廣泛存在于用戶之中，不要急著解決它，如果該問題比較嚴重，它會再次出現于后續執行的測試中。

第三十章 ? 遠程測試

有主持的遠程測試：可以利用諸如skype，iChat或copilot之類的屏幕共享軟件來完成測試。

無主持的遠程測試：完全不與測試者進行交流的情況下開展遠程測試。可以讓測試者在使用產品時或者執行某項預先設定的任務時自己錄制屏幕錄像。

如果還沒有執行任何可用性測試，你首先應該開展幾次傳統的現場可用性測試，你可以先邀請朋友擔當測試者，直到熟悉了測試流程。

只有熟悉了可用性測試的流程，你就可以開始執行遠程測試了。

每周至少執行一次遠程測試。

除了其他渠道（比如，郵件列表，討論小組甚至報紙），你也可以利用網站招募測試者。利用網站招募測試者極其方便，也不需要任何費用，但如果只通過這種方式進行招募，測試結果可能會向那些有產品使用經歷的人傾斜，因為他們很可能訪問過你的網站。

剔除那些純粹奔著獎品來的測試者。

在聯系潛在的測試者時，一定要讓他知道你在測試中能看到他的屏幕，并征求他的同意對測試進行錄像。

在執行遠程測試時，你通常無法看到測試者的面部表情和他們所關注的東西。注意測試者變得沮喪或不安的情況，如果發生了此類情況，請停止測試。

在測試的最后，感謝測試者為此付出的時間，向他說明你再也看不到他的屏幕了，并贈送獎品。用樂觀的態度結束測試過程。

第三十一章 ?如何避免測試中的常見錯誤

不要使用用戶界面中的詞：在設計測試任務和與測試者交談時，一定不能使用應用程序中的術語。任務描述時不要描述任務本身，而是描述任務目標。

不要影響測試者：如果測試者尋求你的指導，一定要小心，這表明產品出現了可用性問題。

避免營造緊張的氛圍：

不要經常要求測試者大聲說出自己的想法。

如果測試者看上去焦慮不安或是感到厭煩，就停止測試。

第三十二章 ?用戶錯誤即使設計錯誤

用戶沒有出錯。出錯的是你的產品，因為它不能正確的解讀用戶的操作行為。

不要在錯誤信息中責備用戶：不要責備用戶，我們應該因為問題向用戶道歉。這才是良好的可用性，因為它能讓用戶冷靜下來，處理問題。為用戶提供“情感支持”。主動識別并處理用戶的情感狀況，能緩解挫敗帶來的強烈的負面情緒和刺激。

沒有錯誤就沒有責備：在錯誤信息中給出幫助用戶解決問題的方法。但最好的做法還是根本就不讓錯誤出現。

只需改變用戶界面，你就可以防止很多常見錯誤出現：

模式錯誤：歸咎于產品沒有明確顯示出當前所處的狀態，或沒有明確告訴用戶該執行什么樣的操作。

輸入錯誤：產品沒有明顯提示的數據有效格式。應用程序或網站應該清晰地表明期待用戶做什么或者允許用戶以自由的格式輸入內容。 ?另一種解決方法是不要讓用戶決定該在界面中輸入什么樣格式的數據。比如不要讓用戶在文本字段內輸入日期數據，而是提供一個日歷供用戶選擇。

第三十三章 ?A/B測試

A/B測試能用來對比兩個不同的設計方案，而且還可以對比一個設計方案的數個不同版本。

A/B測試可以讓你用精確的數據改進設計，沒有任何推斷和猜測的成分。

使用A/B測試的前提條件是：你應該準備好能運行的產品版本，還需要早足夠多的人來使用它。

何時執行A/B測試？

通常來說，使用于以下兩種情況：你已重新設計或重新撰寫了某些東西，想知道新方案或新內容是否比舊方案更有效；某一問題有數個可行的解決方法，你想找出哪個方法最有效。

什么是“成功地使用產品”？

定義“成功”的一種方法是回到設計過程的最初階段，考慮用戶的目標是什么。如果更多的用戶能實現他們的目標，那么產品就更有效。

測試的準備工作工作：

執行測試：在執行A/B測試時，要確保用戶不會在兩個不同的設計方案間來回轉換。應該把用戶分成不同的組，確保他們能持續關注某個方案；在執行測試的過程中，你要有搜集測試結果的方法；你還要告知用戶，你正在收集產品使用數據，并具體說明你要收集些什么。

解釋測試結果：要記住一點--統計顯著性，你需要知道正在關注的測試結果出現的隨機概率有多大。如果A/B測試中有兩個以上的設計方案，你可以對比各個設計方案，看看差異性是否明顯。

需要記住的要點：

如果你用A/B測試來對比設計方案較小的，遞增式的變化，一定要記住，A/B測試只能為你帶來局部的最大可用性。

在對比高度優化的舊有方案和新方案時一定要知道，即便新設計方案在直接對比中稍差一些，但如果你能像對待舊方案一樣傾注同樣多的心血，新方案最終會有更好的表現。

第三十四章 ?收集產品使用數據

產品發布后，用戶會以你沒有想過的方式使用它。你要知道用戶在做什么，這樣才知道該如何改進產品。

速度：速度是一項很重要的性能，因為你一般很難知道產品在用戶手中的實際性能，直到產品為用戶所用。

退出產品：任務執行過程中的退出行為是產品存在可用性問題的指標。為了找到產品潛在的問題，就要追蹤這些行為。

定義“失敗”：估計產品的失敗表現，如已損壞的鏈接，空的搜索結果，或是網絡沖突之類的現象。從這些地方可以很容易收集到一些改進產品的有效數據。

用戶行為：觀察用戶行為，抓住改進產品的最佳時機，需要增加哪些功能，應該去掉哪些功能；用戶已經開始使用產品，但這并不是設計的終點。現在正是個大好機會，你需要觀察用戶實際使用產品的行為，并利用相關信息改進產品。

第三十五章 ?處理用戶反饋

用戶可能會以你沒有預料到的方式使用產品。這可能是把產品設計導向新方向的大好時機。

不要因為負面反饋而心灰意冷。應該利用這些反饋把憤怒的顧客變成產品的粉絲。