好設計，原來是這樣測出來的！
產品被吐槽，肯定是某些地方沒考慮周到！
為什麼不能指望用戶的意見？
所謂的頭腦風暴，真的有用嗎？
應該如何限定你的目標用戶群？
怎樣的用戶調查纔是真正有效的？

《用戶體驗與可用性測試》是用戶體驗與可用性測試的入門級讀物。作者基於多年的經驗，圍繞用戶調查、原型制作、產品可用性評價、用戶測試，結合具體案例，提供了極其實用的方法和實踐技巧，同時也介紹了敏捷用戶體驗開發的相關內容。

樽本徹也，產品可用性工程師、UCD咨詢師、敏捷UX培訓師。在用戶調查及產品可用性評價方面有豐富的經驗。

陳嘯，上海同濟大學計算機科學與技術專業畢業。後入職日本某株式會社上海子公司，從事車載導航器開發工作，其間赴日本總公司進修。回到上海後，作為項目經理參與Android手機和iPhone手機應用、車載導航器等眾多項目的管理，對產品可用性工程學興趣濃厚。

• 
• 
• 
• 
• 

第1章以用戶為中心的設計概論
1.1UX和UCD
1.1.1體驗的價值
1.1.2UX的構成
1.1.3UX的實現方法
1.1.4UCD的要點
流程的質量
螺旋上升的設計流程
用戶的參與
專欄 UX的國際標準
1.2產品可用性≠產品易用性
1.2.1產品可用性可有可無嗎
1.2.2根本沒法用的產品
亂七八糟的搜索引擎
繁瑣的訂單頁面
沒法後退的網站
1.2.3產品可用性的定義
有效性
效率
滿意度
1.3產品失敗的原因
1.3.1橡膠用戶
1.3.2產品使用背景
例1：轉接非常麻煩的公司分機
例2：銷聲匿跡的BP機
例3：不會用到的重置按鈕
1.3.3用戶體驗的點與線
1.4UCD的最新四原則
1.4.1不要盲從用戶意見
1.4.2隻為一人設計
1.4.3邊做邊想
1.4.4早期試錯
第2章用戶調查法
2.1老套的訪談方法
2.1.1用戶意見的局限性
為什麼不能指望用戶意見
擯棄意見，分析行為
2.1.2小組訪談的局限性
小組訪談以提意見為主
平均每人16分鐘
加以潤色的故事
2.1.3訪談的局限性
按計劃進行的訪談
歸納過的信息
2.2師徒式訪談
2.2.1背景調查法
背景式訪談
2.2.2徒弟的思想準備
基本技能
訪談案例
訪談的注意事項
不能被察覺出你是專家
不要去驗證你的假設
不要在無效的問題上糾纏
2.2.3選擇師父的方法
師父的條件
要找多少位師父
調查公司的樣本庫
人脈
2.3訪談實踐
2.3.1如何設計訪談
2.3.2訪談的地點、設備和人員
地點
設備
人員
2.3.3進行訪談
構建信賴關繫
把握用戶個人信息
把握使用情況
訪談結束
驗證假設型訪談
專欄 前輩和後輩
2.4情景劇本
2.4.1文檔化的必要性
2.4.2什麼是情景劇本
使用情景劇本的好處
2.5分析情景劇本
2.5.1情景劇本的寫法
創作單個故事
推敲情景劇本
2.5.2評測情景劇本
再次訪談
評測訪談的不足之處
2.5.3情景劇本的使用方法
貨真價實的任務
真正的用戶需求
2.5.4探索用戶需求
步驟一：分解
步驟二：分析
步驟三：思考
分析示例：與在線詞典服務的使用相關的情景劇本
2.5.5分析情景劇本的好處
專欄 角色
第3章原型
3.1什麼是原型
3.1.1原型的作用
實驗模型
試用品
3.1.2高保真和低保真
3.1.3T原型
3.1.4奧茲國的魔法師
3.2原型的制作方法
3.2.1制作工具
紙質界面
無形的原型
3.2.2制作的重點
不要忘記做假的頁面
需要具有高保素
保真度較低也素
3.2.3由誰來制作
是否一定要做出完美的原型
制作原型所需的技能
專欄 用PPT來制作原型
3.3卡片分類法
3.3.1層次結構的設計
3.3.2封閉式卡片分類法
封閉式卡片分類法的步驟
也可以在線調查
3.3.3開放式卡片分類法
聚類分析
分類合並
3.3.4Delphi卡片分類法
什麼是Delphi法
Delphi卡片分類法的優點
第4章產品可用性評價方法
4.1什麼是評價
4.1.1總結性評價和形成性評價
期末測驗和小測驗
形成性評價更重要
4.1.2分析法和實驗法
分析法的優點
分析法的缺點
4.2產品可用性檢驗
4.2.1啟發式評估法
4.2.2啟發式評估十原則
繫統狀態的可視性
繫統和現實的協調
用戶操控與自由程度
一貫性和標準化
防止錯誤
識別好過回憶
靈活性和效率
簡潔美觀的設計
幫助用戶認知、判斷及修復錯誤
幫助文檔及用戶手冊
專欄 用戶界面設計的鐵則
4.2.3啟發式評估法的實施步驟
STEP 1：招募評價人員
STEP 2：制定評價計劃
STEP 3：實施評價
STEP 4：召開評價人員會議
STEP 5：總結評價結果
4.2.4啟發式評估法的局限性
查出的問題過多
實施成本
專欄 認知過程走查法
4.3什麼是用戶測試
4.3.1用戶測試體驗記
4.3.2用戶測試的概要
4.4具有代表性的測試方法
4.4.1發聲思考法
觀察的重點
4.4.2回顧法
回顧法的缺點
4.4.3性能測試
測試項目
測試方法
性能測試的缺點
性能測試適用的場景
專欄 產品可用性問卷調查法
4.5用戶測試的基礎理論
4.5.1產品可用性的理論基礎
什麼是反證
測試前的準備
4.5.2用戶測試的參與人數
尼爾森公式的漏洞
5人參與測試的真正用意
專欄 比較調查是失敗的根源
4.6用戶測試的實踐基礎
4.6.1招募
4.6.2設計測試
4.6.3實際操作
4.6.4分析與報告
4.6.5時間與費用
4.7推薦DIY用戶測試
4.7.1輕量化趨勢
4.7.2Do-It-Yourself
4.7.3二八定律
4.7.4DIY的基本原理
充分利用人脈
有效利用日常用品
原始的分析方法
重視對話
4.7.5用戶測試的失敗案例
專欄 低成本用戶測試的發展
第5章用戶測試實踐篇
5.1招募
5.1.1招募前的準備
5.1.2通過人脈招募
5.1.3抓住一切機會
5.1.4招募的竅門
性別年齡不限
按參與者的喜好定時間
逐漸展開
專欄 報酬的行情
5.2設計DIY測試
鬧劇.用戶測試劇場
5.2.1設計任務
5.2.2準備實際檢查工具
準備
信息提示卡
初始化操作指南
5.2.3制作訪談指南
測試大綱
訪談指南示例
網站的相關訪談
5.2.4進行試點測試
專欄 其他與任務有關的內容
5.3簡易實驗室
5.3.1測試地點
5.3.2測試設備
計算機
智能手機/平板計算機
家電、車載導航儀、辦公自動化設備
紙質原型
專欄 DIY投影儀
5.3.3錄像方法
計算機
其他
專欄 PinP
5.4訪談
5.4.1不提問、不回答
5.4.2實況轉播
5.4.3事後詢問
5.5觀察
5.5.1增加"目擊者"
5.5.2觀察的禮儀
5.5.3觀察的技術
專欄 用戶真的喜歡優惠嗎
專欄 發聲思考的理想與現實
5.6分析
5.6.1張貼
5.6.2映射
5.6.3影響度分析
專欄 任務完成狀況一覽表
5.7再設計
5.7.1交談比文檔更值得重視
5.7.2解決問題
5.7.3反復設計
專欄 小變更帶來大成果
專欄 推薦使用頭腦風暴法
5.8隱私與倫理
5.8.1個人信息保護
5.8.2倫理上的責任
事前的說明和同意
精神上、身體上的安全
規避具有利害關繫的人
專欄 不要輕易測試
第6章超越UCD，走向敏捷UX開發
6.1推薦非瀑布型UCD
6.1.1流程的差異
6.1.2溝通方式的差異
6.1.3"慢慢地"的差異
6.1.4敏捷開發 vs UCD
6.2敏捷開發的潮流
6.2.1敏捷UX簡史
貝克對庫珀
6.2.2敏捷UX的基本原則
由內至外
平行推動
輕裝上陣
6.2.3敏捷UX的理論基礎
6.3使用敏捷UX開發
6.3.1產品概念
6.3.2計劃
6.3.3開發
6.3.4發布
專欄 RITE法
附錄敏捷UX的故事
後記

產品可用性工程師這個職業在日本可能沒多少人聽說過，但在歐美國 家已經有了專門的職位。微軟、IBM、SAP 等大公司自不待言，大量軟件公司和互聯網企業也已設立了相關部門，同時也成立了不少相關咨詢公司。在網站可用性領域享有盛名的雅可布? 尼爾森博士，也曾作為 Sun 公司的產品可用性工程師（他被稱為“特別工程師”）活躍在業界中。
最近幾年，產品可用性這個詞越來越為大眾所知，作為產品可用性工 程師的我，自然也接到了很多業務委托。
舉一個例子，下面是來自某服裝公司網站負責人 A 先生的委托。
“最近，我們公司正著手進行網站升級。此次升級的目的之一就是讓網站變得更加好用，因此我們專門聘請了設計人員和了解產品可用性的業界人士。現在網站的設計已經基本完成，預計下個月就可以開放使用了。在網站開放之前，我們想請產品可用性工程師用他們的專業知識評測一下我們的網站，進而提供一些能使網站使用起來更加方便的寶貴意見。此外，我們也聽說有一種叫作產品可用性測試的調查方法，麻煩您給我們的網站做一下這個測試，我們想收集來自用戶的第一手資料，反饋到這次的網站升級裡。麻煩您了。”
當然，有業務找上門來我肯定是十分歡迎的。但老實講，對於這種情 況，我能做的實在有限。很抱歉地說，這個項目現在纔來咨詢恐怕為時已 晚。其實不止開發網站，在計算機軟件、手機、數字家電等項目中，類似 A 先生這樣的委托也經常發生。
無法解決問題難道是因為我們產品可用性工程師無能嗎？我不敢苟同。事實上，解決此類問題我是胸有成竹的，這個方法就是——早點來咨詢我們。那樣，我們也一定可以用產品可用性工程學的專業知識提供更有效的解決方法。
然而，在日本，產品可用性工程師實在是太少了，一般的設計團隊幾乎沒有機會接觸這方面的技術，因此經常會出現這樣的問題，即難得項目負責人關心起了產品可用性問題，卻因為不知道操作方法而導致資源浪費。
本書主要介紹利用產品可用性工程學進行的設計流程及相關方法。如果你是產品經理，通過閱讀本書就能了解，在項目的哪個階段分配什麼樣的任務給產品可用性工程師，纔會帶來最好的效果。如果你是設計人員或程序員，學會了產品可用性的技術，（與把工作托付給那些數量少得可憐的產品可用性工程師相比）就能以“更高的效率、更小的代價”來提高工作質量。
如果剛纔提到的那位網站負責人在網站升級開始之前就讀到這本書，也許結果就大為不同了吧。因此大家一定要在著手進行下一個項目之前讀一下本書，那麼我相信，下一個項目一定會帶給你截然不同的體驗。