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

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

翻譯：陳嘯

摘自《用戶體驗與可用性測試》，人民郵電出版社，2015年4月

• 為什么不能指望用戶的意見？

• 所謂的頭腦風暴，真的有用嗎？

• 應該如何限定你的目標用戶群？

• 怎樣的用戶調查才是真正有效的？

如果你是設計師或程序員，學會了產品可用性的技術，就能以“更高的效率、更小的代價”來提高工作質量。

產品可用性≠產品易用性

第一部分

1、產品可用性可有可無嗎

Usability 經常會翻譯成易用性。在做市場調查時，易用性也經常會和 功能、性能、價格等一同被視為用戶購買產品時的重要考慮因素，可見其重要性毋庸置疑。

然而，如果把 Usability 理解為易用性，就很容易和為用戶著想、對用 戶友好這類比較感性的概念相混淆，進而導致設計團隊把它和對用戶而言 “有則更好，沒有也 OK”的開發需求混為一談。 在實際開發項目時，對成本、完工時間、產品質量等的要求是比較嚴格 的。為了滿足這些高要求，企劃、設計、安裝、質量監督、市場等部門如臨 大敵，奮戰在產品開發的第一線。而處于這種極端環境下的設計團隊如果只抱著“可用性＝易用性”的想法，就會越來越不重視產品的可用性。

但是，產品可用性卻包含非常重要的意義，即“可用”。如果產品出現 不能用的情況，相信設計團隊也一定會更加認真對待并解決產品可用性的問題。設計團隊中如果沒有產品可用性工程師，設計出的用戶界面往往會帶 有嚴重的產品可用性問題，這會直接造成不少項目在用戶界面完成之后的用戶測試階段，才發現設計出來的用戶界面根本不能用。

要想不屢次犯這種錯誤，就一定要認識到，Usability 不是易用性，而是可用性。

2、根本沒法用的產品

大家也許會認為，用戶界面可能多少有些不太好用，但完全不能用的狀況就屬于極端事例了吧。然而，實際上有很多項目在開始時都是以“好用”為目標開發的，但完成后的測試結果卻非常糟糕，最后只能將開發的 目標轉變為“能用”。

大家在上網時遇到過以下情況嗎？

▎亂七八糟的搜索引擎

登錄某家電廠商的官網搜索產品名稱時，搜索到的全是產品宣傳廣告。 另外，如果產品名稱里有英文字母，檢索時即使只是搞錯了一個字母的大小寫，也會“搜索不到您想要的產品”。

▎繁瑣的訂單頁面

某網店的訂單頁面里要客戶填寫的內容有 20 項，而且每一項的內容都 有嚴格的要求。比如，郵政編碼里請不要加“-”，姓與名中間請輸入全角的空格，電話號碼的區號后面請加“-”，日期必須要湊足兩位（例如 09/11） 等。更過分的是，要是輸入錯誤，在按下提交按鈕后，就會逐個彈出提示 每一個錯誤信息的對話框。

▎沒法后退的網站

使用某金融機構的網站搜索門店時，會彈出專用的小窗口。只不過， 在這個小窗口上沒有任何的返回鍵或返回鏈接。如果用戶在搜索過程中不小心弄錯了什么，是無法退回到上一步的，只能從頭再來。

用戶使用這種“亂七八糟的搜索引擎”，若得到的都不是自己想要的搜 索結果時，就會失去搜索的積極性，也不會再想了解產品信息了。

要是用戶碰到了“繁瑣的訂單頁面”或“沒法后退的網站”，雖然可以 在反復修改多次之后達到最終目的，但一旦操作結束，大家也許馬上就會表示出強烈的不滿：“這是什么破網站！我再也不用了！”

從產品制作人員的角度來看，上面的例子也許只是“稍有些不好用”， 但從用戶的實際體驗來看，就上升到了“這東西根本沒法用”。所以說，從產品制作人員的角度來判斷產品可用性是一件非常危險的事情。事實上，能代替你的產品的東西實在是太多了，只要你的界面讓用戶感覺到“沒法用 ”，他們馬上就會使用其他產品。正因如此，杰柯柏? 尼爾森（Jakob Nielsen）在他的著作中才會這樣說：“能左右互聯網經濟的正是產品可用性。”

作為產品可用性工程師和用戶界面設計師，如果把對產品可用性的理 解停留在“可用”上，實在是有辱自己的頭銜。因為同領域的設計專家們早已把目標定為“產品設計就是為了實現在確保安全性和正常可用的前提 下，讓產品更具魅力”。

交互系統的用戶界面設計確實是一件非常復雜的工作。當務之急，是先 把我們的水平提升到“至少保證用戶界面已經達到了正常可用”的高度上。

3、產品可用性的定義

國際標準 ISO 9241 把產品可用性定義為“特定的用戶在特定的使用場 景下，為了達到特定的目標而使用某產品時，所感受到的有效性、效率及滿意度”。

該定義的前半部分，出現了好幾次“特定”這個關鍵詞。實際上，對 于某些產品或網站而言，無法簡單地判斷其是否有用。只有在確定了用戶、使用情況和目標這些前提之后，才能使用有效性、效率、滿意度這些標準 來對其進行評價。

▍有效性

有效性（Effectiveness）指的是用戶能夠達成自己的目標。比如在網上 書店購書，有效性就是指用戶能夠買到自己想買的書。如果買不到，這個網上書店也就沒有存在的價值了。因此，有效性問題是無論如何都必須要 解決的一大問題。

▍效率

效率（Efficiency）就是用戶不必做無用功，就能以最短路徑達成目的。 仍以網上書店為例，如果購物車的操作很麻煩，用戶反復操作很多次才買到自己想買的書，那這個網站就存在效率問題了。而且，嚴重的效率問題實際上就是有效性問題，因為這樣的產品，用戶用了一次之后，再也不會使用第二次。

▍滿意度

滿意度（Satisfaction）就是即使有效性和效率兩方面都沒有大問題，也要從更深層面來考慮，即有沒有給用戶帶來不愉快的體驗。比如，注冊會員時要求用戶提供過多的個人信息，或者要求用戶同意單方面制定的使用條約，或者系統的反應速度非常遲鈍等。一旦發生這樣的情況，馬上就會招致用戶的抱怨，嚴重的話，可能導致用戶不會使用第二次。

只有符合 ISO 9241 的定義，滿足以上三個要素，才稱得上實現了產品可用性。然而，實際操作時并沒有這么容易。比較現實的一個做法是，在權衡問題嚴重性的同時，首先解決有效性問題，然后在時間和成本允許的情況下，盡量解決效率和滿意度的問題。

產品失敗的原因

第二部分

我認識的一些用戶界面設計人員和軟件程序員，他們無一例外都盡心盡力在為用戶考慮。而且，他們也確實做到了不單純注重市場和技術，想方設法做出了舒適好用的用戶界面。然而，無論他們多么為用戶考慮，結果總是不盡人意。很遺憾地講，他們大半的精力都浪費在了不切實際的討論和活動上。

1、橡膠用戶

導致產品不能用的常見原因之一就是“用戶定義失敗”。如果大家聽到有一款車是“敞篷越野面包車”的話，會做何感想呢？如果想讓一個產品滿足所有人的需求，最終設計出來的恐怕就是類似“敞篷越野面包車”這樣的東西。當然，世上肯定不存在這樣的車，即使存在，應該也不會有人買。在設計用戶界面時，如果把所有用戶都當作對象用戶，就犯了類似的錯誤。

那么，只決定假想用戶就足夠了嗎？比如說，現在把用戶群假設為“關注時尚、注重自我的成年人”。但是，這樣的假設是不嚴謹的，和不定義對象用戶沒什么區別。阿蘭? 庫珀（Alan Cooper）把類似這樣的假定用戶群戲稱為橡膠用戶（Elastic User）A，意思就是這樣的定義可以根據設計人 員的想象而隨心所欲地變化。我們經常會遇到這樣的團隊：在項目啟動后的第一次會議上提到產品 的假定用戶群時，大家先是短暫地不知所措，然后鄭重其事地提出我們的 假定用戶群就是所有的顧客。像這種沒有任何條件限制的假定用戶群，范圍也太大了。

在項目開始階段，設計團隊無論是時間還是精力都十分充沛。為了能夠提供更好的用戶體驗，在新功能和如何改進用戶界面方面，團隊成員會提出各種各樣的創意。然而，無論是多么優秀的創意，只要其他人能夠想出哪怕一個不喜歡的用戶，該創意也極有可能被擱置。如此反復，原本的創造熱情會慢慢消退，也可能會出現團隊成員感情用事、互相揭短的情況。

隨著這種沒有結果的爭論持續升溫，危機在不知不覺間就到來了，因 為“交貨”的時間快到了。危機面前，馬上就變成由“聲勢大”的成員主導，假想出一些勉強可以使用現有用戶界面的用戶形象。對于其他團隊成 員而言，一是團隊目前已身處懸崖邊緣，再者自己對這種沒有結果的爭論也頗感無奈，于是也不會再反對，只好稍微改變一下自己一直以來主張的 用戶形象（因為是“橡膠制品”，簡單可變），投了贊成票。就這樣， 沒法 用的用戶界面誕生了。

2、產品使用背景

在瀏覽產品可用性的相關圖書和網站時，我們經常可以看到產品使用 背景（Context）這個術語。這個單詞經常會被翻譯成“上下文”，在英語文章里，常見的意思也是事物的“前后關系”或“狀況”。

其實，產品使用背景就是類似舞臺劇里場景設置那樣的概念。舉個例 子，雖然是使用同一個旅游信息網站，但是“女大學生 A 在大學的電腦教室里計劃和朋友的畢業旅行”這個場景，和“商務公司的業務員 B 使用辦 公室里的電腦安排下周的出差計劃”這個場景就完全不一樣。因此，不難想象用戶在使用網站時用的功能和信息也是大不相同的。

可以說產品使用背景是“產品可用性的關鍵因素”。產品使用背景不 同，即使是同一個系統或產品，也可能會出現不能用或非常好用這兩種截 然相反的結果。

例 1：轉接非常麻煩的公司分機

我經常會因為接待訪客、開會或者去做用戶測試而不在辦公室，因此使用固定電話是非常不方便的，所以公司把小靈通作為內部分機使用。無論在會議室還是在實際調查現場都可以使用小靈通接聽電話。

但是，這種小靈通電話也存在很嚴重的問題，那就是轉接功能不太好 用。因為是公司內部分機，所以經常有打給同事的電話打到了我這里，然 后由我轉接的情況。當然，如果嚴格按照正常步驟來操作，肯定是可以轉 接的，但是一旦搞錯了中間的一個步驟，電話馬上就會掛斷。大家都知道 ，無端掛斷客戶的電話是一件非常不禮貌的行為，也是絕不應該發生的。那么，發生這種情況，真的是小靈通設計上的問題嗎？

話說，大家有在自己的手機上使用轉接功能的經歷嗎？估計大多數人一次都沒用過吧。實際上，上面提到的小靈通，其設計初衷和其他手機是一樣的，就算不能轉接電話也很好用。所以說，犯錯的并不是小靈通的設計師，而是我們這些把小靈通當成辦公室分機使用的人。

例 2：銷聲匿跡的 BP 機

20 世紀 90 年代前期到中期，高中生之間曾出現過一陣 BP 機熱潮。 1996 年，NHK 曾熱播過一部紀錄片，名為《BP 機友? 12 字的青春》。然 而，這股熱潮并未持續多久，20 世紀 90 年代后期便逐漸銷聲匿跡了。

BP 機本來是商務上用來有效傳遞信息的工具。比如，它很適合用于上 司給正在出差的業務員新的指示，或者在醫院或工廠內部傳遞信息。但是 用于高中生們閑聊的話，它還欠缺一個很重要的功能，那就是發送消息。 大家都知道，BP 機是專門用來接收消息的。這種只能用來接收消息的BP 機根本稱不上是交流工具。

那么，那個時候的高中生是怎么發送消息的呢？答案就是固定電話。他們使用家里的電話，或者特意跑到有公用電話的地方發送消息。因為在當時，手機的價格非常昂貴，這樣做也是無奈之舉。雖說固定電話不太方便， 但是只能接收消息的 BP 機再配上發送消息的電話，也勉強能達到目的。

后來，當高中生也買得起手機時，BP 機也就退出了歷史舞臺。

例 3：不會用到的重置按鈕

卓別林的《摩登時代》用諷刺手法描述了“人類被機器耍得團團轉” 的情景，用戶界面的設計原則之一就是必須具有可以讓用戶隨時取消操作的“緊急出口”。

比如，Windows 里的程序，所有的對話框窗口上都設置了取消按鈕， 用戶可以隨時取消之前所做的操作。只要沒有按下 OK 按鈕，無論在對話 框里做過怎樣的操作都不會執行，因此用戶可以安心使用。可以說，像這 樣在用戶界面上設計了 OK 按鈕和取消按鈕的做法是非常好的。

但是，這只是窗口的情況。如果是網頁，取消按鈕就不是必備的了。 在訂單或注冊頁面里，如果并排放置發送按鈕和清空按鈕（也叫重置按鈕），用戶就很容易按錯按鈕，本來想發送，結果卻清除了之前辛辛苦苦填 寫好的內容。

如果是紙張，與其用修正液修正或直接劃掉，不如把寫錯的那張紙扔掉，重寫一張反而更快。但是在網頁上輸入的時候，有誰會清空所有已經填好的內容重頭再來呢？顯然只修改輸錯的地方更快一些。再者，如果確實想放棄此次填寫的所有內容，點擊瀏覽器的按鈕退回到上一步就行了。

不管你熟知多少設計原則，一旦理解錯了產品使用背景，就不僅僅是沒有意義這么簡單了，反而給用戶添了麻煩。

3、用戶體驗的點與線

改進用戶界面時，有不少人會使用常用的市場調查方法。比如，通過 問卷調查或者對用戶訪談的方式，詢問用戶他們認為使用該產品（或該網站）最麻煩的地方是什么。

當然，這種方法也能發現問題，只要調查人數足夠多，也可以找出用戶界面存在的大多數問題。然而，即使通過這樣的方法修改了所有發現的問題，用戶體驗也不會得到很大改善，因為在“重要路線”上還存在著不少問題。

用戶界面的作用就是引導用戶達成自己的目標，而用戶在達成目標的 過程中肯定存在著一條路線，在這條路線上但凡存在一個不能通過的關卡， 就會使用戶達不成目標。而且，即使只存在一個比較麻煩的關卡，也會使 用戶耗費不少精力。

即使已經優先解決了用戶界面上存在的重大問題，但只要用戶經常通 過的那條路線上還有殘留問題，用戶體驗就得不到很大改進。換句話說，必須要有一種能夠清除所有問題的方法。

UCD的最新四原則

第三部分

UCD 的流程本身就比較簡單，再加上從用戶角度考慮問題的理念早已 潛移默化地植入大家腦中，因此乍一看可能不會有什么新鮮感。然而，它的背后卻隱藏著一些非常獨特的原則。

1、不要盲從用戶意見

“你們的產品如果有這樣的功能（特色）就好了”——很多產品正是在 開發時聽從了這樣的用戶意見，導致最后的結果都不太理想。即使找借口說“用戶的需求反復無常”來推卸責任，也不能從根本上解決問題，因為以“滿足用戶要求”為前提進行開發本來就是錯的。

用戶的意見肯定是基于自身體驗提出的，因為大多數用戶在反饋時經常提到“我用了 ×× 但不太好用”“花費了太多時間”“讓我很煩躁”等。

用戶所說的不過是對自己的親身體驗做了分析后的結果，并不會向你保證分析結果的正確性，因此即使反復分析這些意見，也不會有新的發現。

而用戶體驗卻是未經分析的第一手數據，如果能對此進行謹慎細致的 分析，反而能發現一些甚至連用戶自己都未發覺的潛在要求。也就是說， 我們需要關注的并不是用戶的意見，而是用戶的體驗。

2、只為一人設計

用戶肯定是為了處理某項事情才使用我們的產品。其潛在的含義就是， 如果不事先琢磨清楚“是哪些人為了什么目的而使用我們的產品”，就不能設計出符合用戶要求的產品。但是，我們也經常會遇到這樣的團隊，他們 在提及產品的用戶群時，大家先是短暫地不知所措，然后鄭重其事地提出 我們的用戶群就是所有的用戶。

然而不幸的是，如果你想滿足所有用戶的需求，那么最終開發出來的產品（如敞篷越野面包車）一定是誰的需求也滿足不了的。

那么，我們大膽地設想一下“不要為所有用戶設計，而只為一個人設計產品”。拋棄那些沒用的功能，確保產品的簡潔性。那些具備了所有功能的產品，不是經常被人指責“常用功能只有 20%，將近 45% 的功能基本上用不到”嗎？

3、邊做邊想

一個人絞盡腦汁地想，或者一群人在會議室里無休止地討論，這樣是 不會得到好的創意的。相比之下，邊做邊想（繪制一些簡單的圖，用身邊的工具先做起來）反而更能發散思維。

也許大家會認為，能夠快速且高質量地作圖是設計師才具備的專業技能，但是“是設計師”和“像設計師一樣（邊動手邊）思考”完全是兩碼事，這和畫功的好壞也沒有關系。比起口頭說明，你畫出來的圖即使簡單到只有線和圈，也更具有說服力。

無論是設計師、技術人員還是管理人員，如今我們都應該做到“像設計師一樣思考”。

來吧，把會議室的桌子和投影儀搬到角落，大家都到白板前畫出自己的創意吧。

4、早期試錯

雖說世界發明大王愛迪生曾經說過“失敗乃成功之母”，但一味地失敗 是肯定不會帶來成功的，愚蠢的失敗只會帶來損失。事實上，失敗也是有 “竅門”的。

Fast： 趁早試錯。

Small： 重大失敗會帶來致命的結果。因此，要把失敗的影響盡量控制到最小。

Often： 不可失敗一次就氣餒，要多失敗幾次。

Smart： 絕不可反復犯同一個錯誤。要徹底查明上一次失敗的原因，再“聰明”地失敗。

紙制軟件也是可以測試的。不要把不會編寫程序、沒有預算、沒有時間這些借口作為不去做的理由 ，只要是在力所能及的范圍內進行嘗試就可以。在設計的最初階段就應該反復進行試作和測試，而且要“善于”失敗。

---

更多推薦

回復“61”——馬化騰內部分享：三個問題說透如何做產品

回復“62”——鳥哥筆記VS知乎劉錘：一個運營牛人的進化論

回復“63”——前蘋果副總裁：20-40-60法則

回復“64”——鵝廠頂級產品課程：產品細節中的情感化設計

回復“65”——如何用互聯網思維賣辣條

回復“66”——馬化騰親身分享：騰訊兵法教你做一款高口碑的產品

回復“67”——去哪兒產品總監：先解構，再設計，把握產品經理的核心競爭力

回復“68”——一份優秀的競品分析報告的撰寫方法

回復“69”——阿里收購驚人內幕，支付寶出大招顛覆式創新-人人都是ATM

回復“70”——你的微信朋友圈讓你焦慮了嗎？

原創或推薦文章請發送至郵箱：xiaoxi@pmcaff.com

PMcaff合作媒體：Chinaz

總結

以上是生活随笔為你收集整理的干货 ▏为什么你的产品或界面总被吐槽？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。