目錄 6
序言 13
第一部分 為共識而談判 17
1 方法論是不夠的 18
1.1 case，cad和滅蟑儀 18
1.2 方法作用於問題 19
1.3 映射及其符號係統 20
1.4 確保每個人都能讀懂映射圖 21
1.5 需求的映射圖並不是需求 21
1.6 提示和變化 22
1.7 小結 24
2 在陳述需求中的含混性 24
2.1 含混性的例子 24
2.1.1 缺少的需求 25
2.1.2 含混的詞語 25
2.1.3 無意中引入的假設 25
2.2 含混性的成本 26
2.3 為消除含混性而探索 27
2.3.1 需求的圖片 27
2.3.2 需求的模型 28
.2.4 提示和變化 28
2.5 小結 28
3 含混性的來源 29
3.1 實例：收斂設計過程演講 29
3.2 注意力的測試 30
3.3 聚類啓發 31
3.3.1 觀察和迴憶錯誤 31
3.3.2 解釋錯誤 32
3.3.3 錯誤來源的混閤 32
3.3.4 人們交互的作用 32
3.4 問題陳述的含混性 33
3.5 提示和變化 35
3.6 小結 35
4 可靠但不真實的直接問題的用法 36
4.1 決策樹 36
4.1.1 問題的次序 37
4.1.2 穿越決策樹：一個實例 37
4.2 含混性投票的結果 38
4.3 可能會是什麼錯瞭？ 39
4.4 現實生活比我們想象的要現實 40
4.5 提示和變化 40
4.6 小結 41
第二部分 開始之路 42
5 切入點 43
5.1 一個通用的切入點 43
5.2 不同切入點的通用化 43
5.2.1 來自解決方案的想法 43
5.2.2 來自技術的想法 44
5.2.3 比喻 45
5.2.4 標準 45
5.2.5 實體模型 46
5.2.6 名稱 46
5.3 存在性假設 46
5.4 一個升降機的例子 47
5.4.1 命名我們的項目 47
5.5提示和變化 48
5.6 小結 48
6 自由問題 49
6.1 過程的自由問題 49
6.2 自由提問的潛在影響 50
6.3 産品的自由問題 50
6.4 連環問題 51
6.5 自由提問的好處 52
6.6 提示和變化 53
6.7 小結 54
7 找到正確的相關人員 55
7.1 辨彆正確的人員 55
7.1.1 客戶和使用者 55
7.1.2 為什麼要包括使用者？ 56
7.1.3 鐵路的矛盾 56
7.1.4 産品能夠創造用戶群 56
7.1.5 失敗者是使用者嗎？ 57
7.2 啓發式包含使用者 57
7.2.1 列齣可能的用戶群 57
7.2.2 修葺使用者清單 59
7.3 參與者 59
7.3.1 誰參與？ 60
7.3.2 他們什麼時候參與？ 61
7.3.3 我們如何得到他們的判斷？ 61
7.4 為抓獲使用者而計劃 61
7.5提示和變化 62
7.6 小結 62
8 為每個人準備會議工作 63
8.1 會議：離不開又無法忍受的工具 63
8.1.1 一個可怕而典型的會議 63
8.1.2 為度量而開會 65
8.2 參與和安全 65
8.2.1 建立一個打斷機製 66
8.2.2 設置時間限製 66
8.2.3 反對人身攻擊和貶低 66
8.2.4 緩解壓力 66
8.2.5 承認結束時間，並且按時結束 66
8.2.6 處理相關問題 67
8.2.7 改進規則 67
8.3 不齣席會議也感到安全 67
8.3.1 公布一個議程並且堅持它 68
8.3.2 不插手突發模式 68
8.3.3 處理好不相關的人員 68
8.3.4 包含正確的人員 68
8.4 設計你需要的會議 69
8.5 提示和變化 69
8.6 小結 70
9 自始至終降低含混性 70
9.1 利用記憶啓發 70
9.2 延伸含混性投票 71
9.3 "瑪麗從前有一隻小羔羊"啓發 71
9.4 詳述"瑪麗欺騙商人"啓發 73
9.5 在星星問題上應用啓發 75
9.6 提示和變化 78
9.7 小結 78
第三部分 探索機會 79
10 産生想法的會議 81
10.1 典型的頭腦暴風雪 81
10.2 頭腦風暴的第一部分 82
10.2.1 不允許批評和責備 82
10.2.2 讓你的想象自由飛翔 83
10.2.3 為數量而努力 83
10.2.4 改變和閤成想法 83
10.3 頭腦風暴的第二部分 83
10.3.1 門限投票法 83
10.3.2 競選演講投票法 84
10.3.3 閤成想法 84
10.3.4 應用判據 85
10.3.5 打分或者排名係統 85
10.4 有益的提示和變化 85
10.5 總結 85
11 右腦方法 87
11.1 地圖工具 87
11.1.1 草圖 87
11.1.2 畫麯綫圖 87
11.2 頭腦作圖 88
11.3 右腦運動 88
11.4 有益的提示和變化 89
11.5 總結 89
12 項目的名稱 91
12.1 工作名稱，綽號和正式名稱 91
12.2 名稱的影響 91
12.2.1 一個命名的證明 92
12.2.2 命名完成瞭什麼？ 92
12.3 啓發式命名方法 93
12.4 有益的提示和變化 94
12.5 總結 94
13 麵臨衝突時推動進程 95
13.1 處理無關緊要的衝突 95
13.1.1錯誤的時間，錯誤的項目 95
13.1.2 個性衝突 96
13.1.3 必不可少的人 96
13.1.4 組內的偏見 96
13.1.5 級彆不一樣 97
13.2 注意力完全集中的技巧 97
13.3 處理本質的衝突 98
13.3.1 重塑個性差異 98
13.3.2 協商 99
13.3.3 處理政治衝突 99
13.4 有益的提示和變化 100
13.5 總結 100
第四部分 明確期望 102
14 功能 103
14.1 定義功能 103
14.1.1 存在功能 103
14.1.2 測試功能 103
14.2 記錄所有且唯一的功能 104
14.2.1 記錄所有潛在的功能 104
14.2.2 理解明顯的、隱藏的以及裝飾性的功能 105
14.2.3 識彆未注意到的功能 106
14.2.4 避免隱含的解決方案 107
14.2.5 "如果你能夠就實現它"列錶 107
14.3 有益的提示和變化 108
14.4 總結 108
15 屬性 110
15.1 屬性的願望列錶 110
15.2 改變願望列錶 111
15.2.1 區分屬性和屬性細節 111
15.2.2 揭示屬性的含混性 111
15.2.3 組織列錶 112
15.2.4 從改變後的列錶揭示內幕 112
15.3 為功能分配屬性 113
15.3.1 屬性如何修改功能 113
15.3.2 從新格式中獲取內幕 113
15.4 去掉屬性 113
15.4.1 將屬性分類為必須，需要和忽略 113
15.4.2 隱式和顯式地排除屬性 114
15.5 有益的提示和變化 114
15.6 總結 115
16 約束條件 116
16.1 定義約束 116
16.2 考慮作為邊界的約束 116
16.3 測試約束 118
16.3.1 過於嚴格？ 118
16.3.2 不夠嚴格？ 118
16.3.3 不清楚嗎？ 119
16.3.4 産生新的想法 119
16.4 相互關聯的約束 119
16.5過度約束 120
16.6 心理約束 120
16.6.1 傾斜觀念 121
16.6.2 打破約束 121
16.6.3 自負與糟糕設計的循環 122
16.7 約束産生自由 122
16.7.1 標準 122
16.7.2 語言和其他工具 122
16.8 有益的提示和改變 123
16.9 總結 124
17 優先級 125
17.1定義優先級 125
17.1.1一個例子 126
17.1.2 優先級的來源 126
17.2 讓優先級可量化 126
17.2.1 針對度量的閤理方法 126
17.2.2讓優先級可量化 127
17.3 區彆約束和優先級 127
17.3.1 滿足進度是約束嗎？ 127
17.4 受到約束的優先級 128
17.4.1 它值什麼圖（what's-it-worth?graphs） 129
17.4.2 什麼時候你需要它圖（when-do-you-need-it?graph） 129
17.5 重新將約束定製為優先級 130
17.5.1 在優先級之間交易 130
17.5.2 産品開發的決定律 131
17.6 有益的提示和變化 132
17.7 總結 132
18 期望 134
18.1 限製期望的原因 134
18.1.1 人們不是完美的 134
18.1.2 人們並不都是有邏輯的 134
18.1.3 人們對事情的感受不一樣 135
18.1.4 設計者也是人 135
18.2 采用期望限製過程 136
18.2.1 産生專門的期望列錶 136
18.2.2 電梯的例子 136
18.2.3 産生期望列錶 137
18.2.4 限製期望 138
18.3 限製條件不必被限製 138
18.3.1 輪椅的例子 138
18.3.2 讓可能性保持公開 139
18.3.3 包括限製的來源 139
18.4 有益的提示和變化 139
18.5 總結 140
第四部分 極大地增加成功的可能 141
19 含混性度量 142
19.1 測量含混性 142
19.1.1 使用含混性投票 142
19.1.2 使用投票方法 143
19.1.3 在不同的基礎上投票 143
19.2 將度量作為測試 143
19.2.1 度量三類含混性 143
19.2.2 解釋結果 144
19.2.3 通過聚類得來信息 144
19.2.4 選擇被投票的人群 144
19.3 有益的提示和變化 145
19.4 總結 145
20 技術評論 146
20.1 一個走過場的例子 146
20.2 技術評論的角色 148
20.2.1 正式和非正式的評論 148
20.2.2 技術評論與項目評論 148
20.3 評論報告 149
20.3.1 評論報告所需的東西 149
20.3.2 創造問題列錶 150
20.3.3 技術評論總結報告 150
20.4 評論的主要類型 151
20.4.1 香草評論 151
20.4.2 檢查 152
20.4.3 預演 152
20.4.4 聯名聲明評論 152
20.5 真實與理想的評論 152
20.6有益的變化和提示 153
20.7 總結 153
21 衡量滿意度 154
21.1 創建用戶滿意度測試 154
21.1.1 測試屬性 154
21.1.2 為每個項目采取的客戶測試 154
21.2 使用測試 155
21.2.1 好處 155
21.2.2 繪製改變和趨勢 156
21.2.3 解釋評論 156
21.2.4 感覺就是事實 156
21.3 測試的其他用處 157
21.3.1 交流工具 157
21.3.2 貫穿項目的持續作用 158
21.3.3 對設計者的用處 158
21.4 其他測試 158
21.4.1 原型作為滿意度測試 158
21.5 有益的提示和變化 159
21.6 總結 160
22 測試用例 160
22.1 黑箱測試 160
22.1.1 外部與內部的知識 160
22.1.2 構建黑箱測試用例 161
22.1.3 測試這些測試用例 162
22.2 應用測試用例 162
22.2.1 示例 162
22.2.2 反復測試和迴答 163
22.2.3 清晰地指明含混性 164
22.3 以測試用例為證 164
22.4 有益的提示和變化 165
22.5 總結 166
23 學習已存在的産品 166
23.1 把現存産品當作標準來使用 166
23.2 訪談 167
23.2.1 新産品中有什麼不見瞭？ 167
23.2.2 為什麼不見瞭？ 167
23.2.3 在舊産品中遺漏瞭什麼？ 168
23.2.4 在舊需求中遺漏瞭什麼？ 168
23.3 用特徵代替功能 169
23.4 有用的提示和變化 170
23.5 小結 170
24 達成協議 171
24.1 決策從哪裏來 171
24.1.1 選擇，假設和強迫接受 171
24.1.2 電梯設計決策的例子 171
24.1.3 撰寫可追溯的需求 172
24.2 錯誤假設從哪裏來 173
24.2.1 有效信息的缺乏 173
24.2.2 超時失效 173
24.2.3 收費公路效應 173
24.2.4 需求滲漏 174
24.3 把決策轉化為協議 174
24.4 有用的提示和變化 174
24.5 小結 175
25 結束 175
25.1 對結束的害怕 176
25.2 結束一切的勇氣 176
25.2.1 自動化設計和開發 176
25.2.2 堆土窯方式 176
25.2.3 凍結需求 177
25.2.4 重新談判過程 177
25.2.5 對做齣清晰假設的害怕 177
25.3 不夠格的勇氣 178
25.4 有用的提示和變化 178
25.5 小結 179
參考文獻 179
索引錶 179
· · · · · · (收起)