就這么簡單——Web開發中的可用性和用戶體驗

就這么簡單——Web開發中的可用性和用戶體驗

《就這么簡單——Web開發中的可用性和用戶體驗》是2008年出版的圖書,主要講述人機互動學(Human-ComputerInteraction,簡稱HCI)這一學科在Web界面設計領域中的套用。

基本介紹

  • 書名:就這么簡單——Web開發中的可用性和用戶體驗
  • ISBN:9787302169994
  • 定價:79元
  • 出版時間:2008-5-30
  • 裝幀:平裝
圖書簡介,書籍目錄,

圖書簡介

正如你所看到的,這是一本文字輕鬆,而且有很多好玩插圖的……技術理論書籍。
沒錯,技術理論。它將和你討論關於軟體(或網站)的界面與用戶之間的關係——界面是你做的,而使用它的是用戶——所以,別自信滿滿地說自己做的很牛,讓我們聽聽用戶的意見。這本書能告訴你這一套順序大概是怎樣的,你應該注意些什麼,最終水到渠成的是一個能經得起考驗的產品。
這本書可以說是一本針對廣泛大眾,以及那些沒有接受過人機互動和可用性專業培訓的用戶界面設計人員的輔導和幫助手冊。你不必背誦那些拗口的專業辭彙,你只需知道“我該如何去做”從而解決問題。這本身也是人機互動學科的一個重要原則——“易於學習,從而便於使用”。
你明白了。這不是本情節跌宕起伏的小說,也不是行文優美如詩的散文。但我仍然希望它能給人帶來快樂——學習不是一件枯燥的事,但很多人把它變得枯燥了。絕大多數技術理論書籍的作者們都正襟危坐就好像板著面孔的老師,不可否認,對待學術問題應當態度嚴謹,但是嚴謹不代表嚴肅,能在專業知識課堂上把大家逗笑的老師一定不簡單。
我不敢說我做到了,但我在努力。

書籍目錄

前言 1
序章關於這本書 3
0.1誰該看這本書? 4
0.2這是本什麼樣的書? 6
0.3怎么用這本書? 8
0.4感謝這些夥計 9
第一章你首先要知道的一些事情 10
1.1我聽說過這些詞……不過它們到底是什麼? 10
1.1.1什麼是UI設計 11
1.1.2什麼是互動設計 13
1.1.3什麼是好的用戶界面設計 15
視覺表達不清 15
非常繁瑣 16
提示混亂 17
難以使用 18
強迫用戶 18
1.1.4那么該怎么做? 19
什麼人會使用產品?用在什麼地方? 19
用戶會有些什麼樣的行為? 19
1.2我幹嘛得學這些玩意……還要買本書?! 20
1.2.1用戶界面不是次要的工作 21
1.2.2用戶界面設計不是界面程式設計,也不是界面圖形設計 23
對於軟體設計師來說 23
對於美術設計師來說 24
真正的用戶界面設計人員 24
1.2.3互動設計是一門跨學科領域 25
1.2.4不用成為專家,理解方式即可 26
1.3OK,那我該怎么做? 28
1.3.1互動設計的4個內容 28
理解用戶需要,建立用戶需求 29
開發一些候選設計方案 29
製作設計方案的原型 29
用戶測試和評估 29
1.3.2互動設計的3個特徵 30
以用戶為中心 30
建立明確具體的可用性標準 31
反覆疊代 31
1.3.3互動設計的2個目標 31
可用性目標 32
用戶體驗目標 34
1.3.4摩西的十誡 36
讓用戶隨時了解系統的狀態 36
系統應與真實世界相符合 36
給予用戶控制權和自主權 37
提倡一致性和標準化 38
幫助用戶識別、診斷和修復錯誤 38
預防錯誤 38
依賴識別而不是記憶 39
強調使用的靈活性及有效性 40
最小化設計 40
提供幫助及文檔 40
1.3.5如何粗略地評估可用性 40
第二章了解用戶,了解需求 43
2.1誰是用戶? 43
2.1.1普遍而又特殊的用戶 44
用戶的普遍性 44
用戶的特殊性 44
兩者兼顧 44
2.1.2用戶可不是越多越好 45
2.1.3“阿童木”的誕生 46
2.2什麼是需求? 47
2.2.1“需要”產生需求 48
2.2.2點了牛扒,端上來的卻是意大利麵 52
2.2.3各種類型的需求 54
功能需求 54
用戶需求 54
數據需求 54
環境需求 55
可用性需求 55
2.3如何確定需求 57
2.3.1介紹一些數據蒐集的方法 58
問卷調查 58
用戶訪談 59
觀察和提問 60
集體討論 61
2.3.2筷子、刀叉和勺,哪種餐具最好? 62
2.3.3一些要注意的地方 64
一切的重點都是為了搞清楚用戶需要什麼 64
要考慮所有的用戶類別 64
每個用戶類別只派一位代表參與是不充分的 64
打“組合拳”,不要單一套路 64
在可能的情況下,先小規模試驗 65
如果得到的需求信息太多 65
記錄數據同樣很重要 65
2.3.4解釋與分析數據——一道填空題 65
2.4歸根結底,我們要了解任務 67
2.4.1用講故事來描述任務 69
2.4.2用流程圖描述任務 71
2.4.3理想和現實的差距 74
守舊的用戶 74
過分的用戶 74
妥協還是抗爭? 75
2.5環境?什麼是環境? 75
2.6做個小結 77
第三章設計方案和製作原型 79
3.1為什麼,以及怎么做 79
3.2初級原型和高級原型 81
3.2.1初級原型很重要 81
草圖,或者說塗鴉 82
連環畫 83
製作卡片 84
模擬界面 84
3.2.2高級原型同樣重要 85
3.2.3嗯,不過原型僅僅只是原型 87
3.3概念設計,或者說初步設計 88
3.3.1夥計們,讓我們先考慮功能 88
3.3.2概念模型是個什麼玩意? 89
開放思路,同時考慮用戶和套用環境 90
保持簡單,但也不要過於簡單 90
使用初級原型來快速獲取反饋 90
反覆疊代進行設計 90
3.3.3開發概念模型的幾個問題 90
採用什麼樣的互動方式? 90
是更“智慧型”還是更“服帖”? 92
是否存在合適的熟悉概念進行映射比擬? 92
3.3.4在概念設計中使用原型 93
3.4物理設計,或者說具體設計 95
3.4.1一些具體的設計指南 96
力求一致性 96
允許頻繁使用系統的用戶使用快捷鍵 97
提供明確的反饋 98
設計對話,告訴用戶任務已完成 100
提供錯誤預防和簡單的糾錯功能 101
應該方便用戶取消某個操作 101
用戶應掌握控制權 102
減輕用戶的記憶負擔 103
3.4.2界面元素和界面風格 104
3.4.3選單(或者導航欄)的設計 106
3.4.4圖示的設計 110
不要“辭不達意” 112
小而簡單 113
3.4.5螢幕布局的設計 113
大的方針 114
同時也要考慮細節 115
還要很多地方需要注意 117
3.4.6別理那些複雜的工具,我們做的是Web 118
第四章以用戶為中心的開發 120
4.1為什麼要讓用戶?艉徒?矗?120
告訴他們別太天真 121
另一方面……他們才是真正的主人 121
4.2支持用戶,而不是限制他們 121
排第一位的永遠是用戶,不是技術 121
給他們最習慣的環境 122
要支持用戶,就得考慮周全 122
經常向他們諮詢意見 122
4.3如何讓用戶參與? 125
4.3.1用戶參與的不同形式 125
極端之一:讓用戶作為設計組成員 125
極端之二:用戶遠距離參與設計 126
4.3.2用戶參與的是與非 126
4.4別用望遠鏡,要現場研究 127
4.4.1關於現場研究 128
4.4.2你是師傅,我是徒弟 130
不是在會客室 130
建立正確的關係 130
該問就大膽問 131
不要離題太遠 131
4.4.3這不是你的地盤,別太不拘小節 131
4.4.4我們能得到什麼? 132
第五章文化的差異 135
5.1什麼是文化的差異? 136
5.2對於Web和Web-based產品來說 137
5.2.1一次要做幾件事? 137
5.2.2高度認知和低度認知 138
5.2.3功能還是關係? 139
5.2.4網頁和界面的視覺反映 140
5.2.5誰的錯? 144
5.3國際化和本土化 145
注意適配解析度的大小 145
儘量多用被廣泛接受的圖示 146
繪製圖示時注意地域性 147
翻譯時使用用戶習慣的表達方式 147
注意不同地區使用的單位和格式 147
注意文字的輸入 148
避免?魷侄閱承┑厙?皇視玫男畔?148
其它方面 148
第六章網頁的可用性 150
6.1人們是如何使用網頁的? 150
6.1.1他們很會節省時間 151
6.1.2他們也不會仔細考慮 153
6.2好感度計量器 154
6.2.1我經歷過好幾次這種情況…… 154
6.2.2這些都會降低好感度! 156
讓我感到鬱悶 156
總是誤導我 159
總是讓我猜 160
總是要我找 161
總是說我錯 162
耽誤我的時間 163
甚至還讓我抓狂 164
6.3因此,為掃描而設計 164
6.3.1更清楚的布局和視覺層次 165
越重要的內容越醒目 165
相關的內容看上去也得相關 165
包含的內容要顯示從屬關係 166
別顯示太多無關的信息 166
6.3.2清晰地劃分頁面區域 167
6.3.3適套用戶的習慣 169
6.3.4提供目光的“落腳點” 170
6.4同時,減少用戶的思考 171
6.4.1減少不確定因素 172
6.4.2保證網頁的一致性 174
一致的網站標誌和導航欄 174
一致的頁面布局 174
一致平衡的信息結構 175
一致的重複性元素 175
一致和諧的字型和色彩 175
一致,但不一樣 175
6.4.3明顯標識可以點擊的地方 176
有時候下劃線可有可無 177
有時候最好有下劃線 178
超連結和按鈕 178
6.4.4清晰、簡單的網頁內容 179
使用用戶的語言,而不是技術語言 179
使用通俗的語言,而不是故作高深 180
減去不必要的詞句,讓頁面更簡短 180
不要誇誇其談,或者讓人摸不著頭腦 180
6.5告訴用戶他們在哪裡 181
6.5.1導航欄存在的意義 182
6.5.2導航欄所需要的元素 183
網站logo標識 183
網站的欄目 184
“回到首頁” 184
附加功能 184
搜尋工具 185
6.5.3導航指示、頁面標題和“麵包屑” 185
導航指示 186
頁面標題 188
“麵包屑” 188
第七章Web-based產品 192
7.1Web或者不是Web? 192
有一些比較偏向於軟體 193
有一些則更偏向於網頁 193
有些產品比較單純 194
有些產品的用戶群比較廣大 195
最後……它們還是網頁 196
7.2我為什麼說要考慮用戶的感受 197
7.3首先看看選單和對話框 199
7.3.1我需要選單,但必須是好選單 199
時隱時現的選單項 199
探頭探腦的選單項 201
7.3.2讓我陷入困境的對話框 202
讓我沒有選擇 202
讓我不知道該怎么選擇 203
沒有第三種選擇 204
7.4你真明白那些控制項的作用嗎? 204
7.4.1單選按鈕和複選框 205
把複選框當作單選按鈕 205
把單選按鈕當作複選框 205
是必須要我選,還是不需要我選? 206
7.4.2標籤雖好,問題多多 206
標籤只能用來導航,不能選擇數據 207
到處都是的標籤 208
太小和太大的標籤 211
7.4.3簡單而又不簡單的文本框 212
在不該用的地方使用文本框 212
該用文本框的地方卻又很隨意 213
7.5每一個元素都要有合適的位置 214
7.5.1控制項的擺放位置 214
胡亂放置的按鈕 215
距離產生美? 216
7.5.2你無法逃避的對齊方式 218
是左對齊還是右對齊 219
不要只注意一邊 221
如果有時候左右都不能對齊 222
上下也要對齊 223
第八章測試可用性 224
8.1為什麼要測試? 224
8.1.1美國到底民主還是不民主? 224
我喜歡的,別人也應該喜歡 225
角色的不同導致看法不同 226
8.1.2這不是簡單的是非題 226
8.2幾個要注意的事實 228
8.2.1一些需要記住的事實 228
可用性測試不是軟體測試 228
哪怕只測試一個用戶,也比不做測試要好 229
早點測試一個用戶,好過最後測試100個用戶 229
“疊代”的測試和頻繁的測試 230
測試後馬上回顧測試結果 231
8.2.2一些需要避免的認識 232
不要認為可用性測試很難 232
不要認為可用性測試總是非常昂貴 232
不要認為可用性測試是表層問題 233
不要認為測試是要去“證明”什麼 233
不要僅僅測試,卻不糾正發現的問題 234
8.3測試的前期準備 234
8.3.1測試的地點和設備 235
最正式和最精良的裝備 235
你也可以最佳化和精簡 236
8.3.2測試用戶的招募 237
測試用戶的選擇 238
究竟每次應該測試多少用戶? 239
如何招募用戶? 242
8.3.3主持人和觀眾 243
誰適合當測試的引導人? 244
誰適合當測試的觀察者? 245
8.3.4道德問題 245
8.4測試的過程 247
8.4.1設計好考題 247
8.4.2介紹階段 248
8.4.3正式測試 248
觀察用戶 249
讓用戶進行有聲思考 249
提出問題 250
尊重測試用戶 250
一個實例你就能明白 251
8.4.4馬上回顧和總結 257
8.5讓專家來評估(別忘了,你也是專家) 259
8.5.1現成的原則——啟發式評估 259
8.5.2你也可以看看這些具體的評估角度 260
關於一致性的評估 260
關於界面簡潔性的評估 261
關於信息反饋的評估 262
關於用戶動作性的評估 262
關於產品特色的評估 263
8.6測試需要修正 264
有些問題可以忽略 264
有些要求也可以忽略 264
別顧此失彼! 265
第九章了解滿意度 266
9.1詢問用戶:問卷調查 267
9.2詢問用戶:訪談 268
終章回到開始:什麼是好的用戶界面設計 269

相關詞條

熱門詞條

聯絡我們