用戶體驗樂趣多：寫給開發者的用戶體驗與交互設計課 ( 簡體 字) |
| 作者：[美] 大衛·普拉特（David Platt） 著 | 類別：1. -> 程式設計 -> UI/UX |
| 譯者： |
| 出版社：機械工業出版社 |  3dWoo書號： 48271
詢問書籍請說出此書號！【有庫存】
NT售價： 295 元 |
| 出版日：12/1/2017 |
| 頁數：189 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787111586937 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：用戶體驗支配一切
今天，用戶體驗（UX）是軟件產品建立競爭優勢的核心驅動力。體驗不好的軟件根本就賣不出去，硬件產品或者服務也一樣。
打造良好的用戶體驗并不難，但是需要你建立起新的思考方式。本書將通過案例一步步來告訴你該怎么做。
你最強的優勢
在如今的軟件行業里，用戶體驗已經是建立競爭優勢的核心驅動力。實際上無論你是設計并銷售軟件產品（如微軟），還是提供硬件（Apple）或服務（UPS快遞），用戶體驗的重要性都毋庸置疑。
就像“在公共場所吸煙”曾經是大家司空見慣的行為一樣，以前的軟件也總是把用戶塞進一個五維扭曲空間里，把自己搞得暈頭轉向才能掌握它—用以前的話講，就是要先成為“電腦達人”。UX大師 Alan Cooper 曾說過，這些“電腦達人”們“被軟件虐了千百遍，傷疤都厚到感覺不到痛了”。用戶也一度接受了這樣的事實：這就是用電腦工作的代價。而現在，一切都改變了。
還記得1997年 Apple 瀕臨倒閉時的事情嗎？最后它通過接受一筆來自微軟（后者是為了避免壟斷嫌疑）的現金注資才勉強維持了下來。而今天的 Apple 又如何成了這個星球上市值最高的公司？答案是超棒的用戶體驗，消費者愿意為了它付出更高的溢價。這就可以看出如今UX是多么重要。
對于企業用戶，UX同樣很關鍵。2014年12月，雅芳（Avon）公司不得不放棄了新版的訂單管理軟件。據《華爾街日報》報道，當時這家公司的獨立銷售代表們抱怨用新系統來處理日常銷售工作太麻煩，太容易搞混了，以致最后紛紛離開了雅芳。
即使是 IBM，這家曾被認為又乏味又笨重的大公司，近日也宣布會投入1億美元在用戶體驗咨詢業務方面，在全球范圍內建立設計實驗室，招募超過1000名新員工。
無論你在做什么，在為誰提供服務，你都需要提供杰出的用戶體驗。它不再是備選，而是必需。
UX不是選擇字體和配色
有超多的開發者和管理人員都認為，用戶體驗設計就是在選擇字體、配色方案，還有給按鈕加上圓角什么的。大錯特錯！那些彈窗的圓角，還有可愛的動畫，都是處于設計流程最后期的部分，也是最不重要的部分。我的同事—軟件傳奇人物Billy Hollis說它們“是裝飾，而不是設計”。
那么，用戶體驗（UX）和用戶界面（UI）之間的差異點到底在哪兒呢？就像所有那些在不同場景中會有不同解讀的詞匯一樣，不同的作者對此也總有不同意見。在本書范圍內，我用UI這個詞特指在打造軟件的過程中最后添加的裝飾部分。而UX這個詞，借用 Jakob Nielsen 和 Donald Norman 發表過的說法：“用戶體驗包含終端用戶和一個公司，以及公司所提供的服務和軟件打交道時的方方面面。”這就意味著任何可以被用戶聽到、看到、觸摸到以及想到的都是 UX：一個程序的工作流程，它提供的一套特性，它需要用戶提供的輸入，以及展示給用戶的內容及其表現形式等。
圖1描述了它們的區別。圖1a展示了一個產品，假設這代表著你要用程序去完成的一項工作。圖1b展示的是UI部分，你通過它來和這個產品做交互。圖1c描述的是完整的用戶體驗，它是你和這個產品打交道時的過程。
圖1 a）產品；b）用戶界面；c）用戶體驗（來自Ed Lea, 產品設計師）
通常，用戶體驗的競賽在遠未到達外觀裝飾階段的時候就已經分出勝負了。把你的程序看作一件家具—比如說一張桌子。裝飾就是它表層的漆面。當然，把桌子的漆面做得精細平整是很好的一件事情，你的軟件也一樣，但如果這個桌子選錯了材料，不能滿足用戶的需要，那么它的漆面再精致也沒用。如果你的用戶想在家中采用了自然風格裝修的客廳里擺放一個小桌，那么選用木質的桌子很可能合他的心意。而另一個用戶，如果他需要給餐廳選購餐桌，每天都要頻繁地清潔，那么金屬材質會好得多。再退后一步看，你的用戶真的需要一張桌子嗎？是不是一把椅子就能更好地解決問題？
基礎案例
我們通過一個實例來看看一些基礎的開發決策是怎樣成就或是搞砸 UX 的。之前我在瑞典教書時，當我用主域名“www.google.com”來打開 Google 首頁時，它的服務器會檢測位置來判斷我所處的國家，并自動跳轉到 Google 的瑞典版首頁去（見圖2）。對于大多數用戶的大多數時間來說，這都是一個正確的選擇，如果這不是你想要的，也只需一次點擊（頁面下方中間的鏈接）就能（通過保存Cookie）一勞永逸地搞定。
圖2 在瑞典打開的 Google 首頁
我們再來看看UPS.com—那家快遞公司的首頁（見圖3）。UPS 的首頁需要用戶自己先選擇他們所處的國家和語言，要不然就什么事也做不了。如果你是瑞典人，那么大概需要30次點擊才能搞定，讀者可以感受一下。同時，你得明確地告訴網站記住你的偏好（看那個復選框），要不然下次還得再這么折騰一遍。它怎么能這樣對待顧客呢？
圖3 在瑞典打開的UPS首頁
這里面發生了什么？難道是因為 Google 的程序員比 UPS 的更聰明，才能檢測出用戶所處的國家嗎？
當然不是。2014年，UPS.com 最高峰時每天要處理超過一億次的快遞查詢請求，他們的程序員必須足夠優秀才能應對如此巨大的流量。這些天才程序員不可能不懂得如何檢測每次訪問的 IP 地址，然后推斷出可能的位置和所處國家（這真的不難：一次簡單的靜態表查詢，為了加速可以將結果加入緩存中，每天更新一次，搞定）。然而UPS最后卻選擇了讓用戶自己選擇他們所處的國家，而不是自動檢測。
在我看來，UPS 在用戶體驗方面犯下大錯：完全沒有從用戶的角度思考。做出這個決定的技術專家，表現得像一個典型的（包括我，還有你這樣的）極客。我們被訓練成了習慣數字化、邏輯化思考問題的人。從中學代數課開始就有了某種根深蒂固的想法：99%情況下準確，1%情況下不準確，那就不能稱為定理。UPS 不會去猜測你的位置，因為它有可能是錯的。
對于一條數學定理，這樣做沒問題，但是對于活生生的用戶這就不對了。和定理不同，如果你的應用能讓99%的用戶開心，那你就可以偷著笑了。同時，明天繼續讓這99%的用戶開心可能比想辦法迎合剩下的1%用戶更重要，尤其是當后者的要求會給其他99%的人添麻煩的時候。當然這種理念在某個情景下不夠理想，比如生活中的交通管制。但是對于大部分的商業和個人消費者場景來說，讓主流情景無縫流暢，當特殊情景實際出現時再去處理都是更好的做法，而不是麻煩所有用戶去做網站自己有能力并且應該去做的事情。
Google 的語言檢測算法也不是總能猜對。也許某個訪問并不是真的來自瑞典；也許某個用戶身在瑞典卻不講瑞典語（我）；又或者這個人就在瑞典，也會講瑞典語，但是此刻他并不想使用這種語言（比如，一個瑞典的大學生正在練習英語）。但是做出最好的猜測，并允許用戶修正錯誤，已經讓主流用戶群體大大獲益。哪個公司的理念讓你覺得它更尊重你的時間和精力？實際上，Google 為用戶想得更長遠，以至于找到了識別 UPS 快遞單號的方法。如果直接在 Google 的地址欄里面輸入單號，Google 就會直接給出這個包裹的配送追蹤信息（圖 4），點擊其中的鏈接，它會直接帶你來到 UPS 網站上這個訂單的詳情頁面，連語言都已經設定為正確的了。這就是我為什么總是用Google來查詢 UPS 快遞，而不是到 UPS 官網去自找麻煩，而我這樣做的時候，總是忍不住面帶微笑。
圖4 Google 自動識別出UPS的快遞單號，并提供詳情鏈接
如你所見，這不是視覺設計的問題，完全不是。兩個網站都有自己的logo、品牌配色和字體，以及獨特的一切。但是其中一個網站強迫全部用戶先要做無關的工作—讓人頭疼、分心，然后才能開始做他們來這里真正想做的事情—追蹤快遞進度。而另一個網站盡它最大的努力，直截了當地為大多數用戶帶來平滑流暢的體驗，并在必要時允許用戶修正錯誤。
兩個網站的區別屬于交互設計，有時候被稱為行為設計，偶爾也被稱為信息架構。這就是本書關注的。我們不會去探討圖形設計，也不會去討論如何編程實現這些設計，已經有很多書涵蓋這些主題了。我們將學習的是如何決定你要用代碼實現的東西。而且我們會一直站在用戶的這一邊。
圖5 用Google 打開UPS訂單詳情頁面時，自動匹配了用戶瀏覽器使用的語言—比直接訪問 UPS.com 更簡單
Platt（作者）的第一條、最后一條，也是唯一一條用戶體驗設計定律
《塔木德經》中講到，一個沒耐性的人走到著名的猶太大師希列（Hillel）面前說：“我現在單腳站在地上，在我支撐不住之前，把《妥拉》（希伯來圣經最初的五部經典）的精髓教給我，”希列答道，“己所不欲，勿施于人。其他的都是對這句話的注解，去學吧。”你想要了解學習用戶體驗的訣竅嗎？我的回答就一句話，它是我的第一條、最后一條，也是唯一一條用戶體驗設計定律：
去了解你的用戶，因為他不是你。
剩下的都是對這句話的注解，我的朋友。來跟我一起學習吧。
三條基本推論
我大學本科讀的是物理學專業，現在我內心還保留著的一點物理學家因子總是讓我堅持一件事，就是設定出基本原則，再從它們出發來判斷對錯。從Platt第一定律出發，我們可以引出下面三條推論。
推論一：你寫的軟件本身毫無價值。它唯一的價值，或可以有的價值，取決于在多大程度上可以讓它的用戶開心或更有效率。
推論二：軟件以兩種方式讓用戶開心或更有效率。首先，它能幫助用戶解決一個特定問題—寫一篇文章，支付一筆訂單，或是給汽車導航。或者，它將用戶帶入一種愉悅的狀態—欣賞音樂、玩游戲，或是和孫子孫女視頻聊天。這就是可能存在的兩種情形了，盡管有時候兩種其實是摻雜在一起的。
推論三：上面的情形里用戶并不愿去思考你的程序本身，完全不會。在第一種情形里，他們思考的是自己面對的問題：正在撰寫的文檔該選怎樣的詞匯，還有沒有足夠的錢來支付賬單，哪個人的錢要是還不上結果會很慘。而后面的情形，用戶只想盡快地進入狀態，待在里面越久越好。任何耽誤了他們解決問題，或是讓他們在享受狀態時分心的事情，都不會受歡迎，比在工作時被人打擾更甚。
讓我們來總結一下三條推論：用戶不關心你的程序，也不關心你本人。現在不會，以后也不會。你親媽可能會，因為這程序是你寫的而她很愛你，但也可能并不會。用戶只關注他自己的效率或是感受。每個應用的每個用戶都想要一臺 Donald Norman 所說的 “看不見的電腦”，就像同名書籍中描述的一樣。
你可以看到，在前面的例子中，Google 就在盡可能地隱藏自己，不像 UPS 那樣。在心里記著 Platt 第一定律，還有它的三條推論，讓我們一起看看另一個案例吧。
示例：要保存嗎？
這是你每天都會遇到的狀況。這簡直可以說成了肌肉記憶，你都不會去想它。但是今天，讓我們一起來思考一下。
在微軟的 Word 軟件里打開一個文檔。敲上一些字或者修改一下，然后點關閉按鈕。Word 是怎么做的呢？它彈出一個對話框問道，“你想要保存修改嗎？”（見圖6）一位時尚的視覺設計師可以給“保存修改”對話框換上漂亮的字體，微妙的漸變色，當然還有精致的圓角。但是他沒有也不能指出這個問題：這個程序應該像現在這樣在用戶退出時發出提問，還是應該像微軟的 OneNote 一樣在修改發生時就自動保存？哪一種方案會讓用戶更有效率、更開心？問題回到我們交互設計師這兒了，來做一個決定吧。應該如何選擇？
讓我們從一道算術題開始。Word在每次關閉的時候要求你做一個選擇，然后點一次鼠標。如果用戶做了100次修改，那他就要做100次選擇，點100次鼠標。如果我們采用了自動保存方案，需要在界面找一個其他地方加入某種版本回滾的功能—比如說在編輯菜單里加上一項“放棄當前文件本次所有修改”，可能會需要5次點擊來完成。如果99%的情況下用戶想要保存修改，自動保存就可以把100次點擊砍掉95次，大大減輕了用戶的負擔。如果只有50%的情況用戶想要保存修改，那么自動保存實際上會增加用戶的負擔—100次點擊驟增到了250次。你的程序又該如何選擇呢？
圖6 微軟的Word提示用戶保存改動。為什么它不像微軟OneNote一樣自動保存呢
和平時一樣，這要分情況。在 Word 中你想要保存修改的頻率有多高？或者換一種方式來看：把文件改得一團糟以至于想要點擊“不保存”放棄修改的頻率有多高？
你的用戶保存修改的頻率，相比他們放棄修改的頻率孰高孰低呢？這又是完全不一樣的問題了。我猜你想說：“好吧，我從來沒見過他們要放棄修改。”和之前一樣，這其實是你按自己的偏好說的話。你會發現很難不把自己帶入進去。在潛意識里你是抵觸“你的用戶和你自己不一樣”這種概念的。那么該怎么做呢？
你可以試著直接向真正的用戶提問，如果能找到他們的話。如果你在自己公司的開發團隊工作，打造一個面向內部使用的程序，這樣做完全沒問題。走上樓到用戶面前提問就是了。然而，這種做法總是會遇到阻礙。這些用戶想要和你談話嗎？他們能不能精確地回憶起細節？他們會不會怕別人笑話而不能敞開心扉？他們的老板是否同意占用他們的工作時間？和真實用戶交談是一個很好的開始。第1章和第3章會討論通過這種渠道提取信息的各種方法。但你不是總能獲得這種機會。
如果你在一個乙方公司的開發團隊，也就是說，你是為一個外部客戶開發軟件，問題就更復雜了。假設你在辦公室里找到一些人。你的同事，也就是那些每一天都在開發軟件來賣的人。他們和你的產品用戶群體類似嗎？除非你在做的產品是一個軟件開發工具。無論他們怎么說，都可能會誤導你。微軟在這個地方已經摔倒好多次了。
那么怎樣才能知道有多大比例的用戶想要保存修改呢？這可不是透過水晶球用神秘的讀心術而是用遠程數據監測技術收集大量用戶的數據。第5章會解釋遠程數據監測的更多細節。你也可以邀請用戶在早期來實驗室做一些可用性測試，如第4章所述。
考慮用戶體驗，從第一刻開始
我見過許多公司總在犯同一個錯誤，就是沒有從項目的初始階段就開始考慮和計劃用戶體驗。“我們要先盡快推出產品，然后再考慮它長什么樣。”這簡直是瘋了。這就好像建筑師在建造房子的時候說：“我們得先把供暖和管道系統安裝到位，再去想誰會住在這里。”你是在為一對老年夫婦蓋房子嗎？那應該在底層設置一個帶浴缸的衛生間，有寬寬的門，還可能要安裝幾個扶欄。如果是有兩個孩子的一對年輕夫婦，他們可能還計劃著再生4個寶寶呢！問題就完全不一樣了。對于將要去建造的房子，你不會在還沒搞清楚最基本的細節之前就花掉開發預算開始施工。用戶體驗就是用來搞清楚這些的。
在之前的例子里，你會看到用戶體驗設計決定著你應該寫怎樣的代碼，不只是表層的用戶交互，而是深入到底層實現。再次以 Word 為例，整個撤銷特性的實現機制取決于用戶體驗設計對于什么時機保存、如何保存文件這些命題做出了怎樣的決定。在前面 Google 對比 UPS 的例子里，網站首頁的開發者需要明確在他們寫的代碼運行的時候，是否已經獲取到用戶所在國家的信息（Google），或是他們需要從用戶那里獲取這些信息，然后傳遞到其他代碼部分來使用（UPS）。
好的用戶體驗設計是從項目啟動的那一刻就開始了。它不僅僅存在于表層，而是滲透在程序的每一個層面上，就像一個人的性格和榮譽感一樣。而且在程序開發的每一個階段你都需要注意它，不對，是在程序的整個生命周期里，就像是在一個人的一生中，性格和榮譽感都需要被關注一樣。
客戶有時在產品發布的最后時刻找到我，讓我對用戶體驗做出評價。這時已經太晚而無濟于事了。架構已經設定，預算已經花完，心態已經固化。讀者要以此為戒。
為什么開發者總是不大考慮用戶體驗
當用戶面對一臺電腦不知道該怎么用，或是需要參加高價培訓后才能學會，又或是被它上面的軟件誤導做錯了事情、付出了昂貴的代價時，那么這臺電腦對這個用戶來說就只是一個昂貴的鎮紙（廢物）了。仍然有很多程序員和架構師覺得他們不用去操心用戶體驗。下面我們來看看他們為什么會這樣說，以及為什么他們都錯了。
1.我們的項目是比較底層的，所以用戶體驗無所謂
無稽之談。每個項目都和人有著種種聯系。就算是一個面向開發場景的 Web 服務，也需要錯誤報告、安裝和配置、狀態和性能監控的報表頁（dashboard）等。如果一個項目只有很少量的用戶體驗工作，那就更應該去把這些部分做好。在20年前，你可能看到過這樣的一個對話框跳出來說，“網絡服務錯誤，錯誤代碼20。查看文檔獲得更多信息。”今天如果你看到誰發布了這樣的產品，你一定會笑出聲來。
2.市場部決定著我們的用戶體驗
跟市場部搞好關系是很明智的。他們當然會感知到用戶的痛點，并反饋到你這里。但同時，這些做市場營銷的人并不是交互設計師。關于怎樣才能讓用戶更開心、更高效，他們也許能給出一點線索—“客戶在抱怨只要我們的程序一崩潰，他們編輯到一半的工作內容就全丟了。”—但是后面該怎么做是由你決定的。這樣的事情多久發生一次？你該如何檢測和記錄它？解決這個問題的方案是：自動保存？提供回滾？用怎樣的頻率？允許用戶自己配置嗎？把這些問題拋給市場營銷團隊，你覺得他們真的能驅動用戶體驗嗎？他們不行，你可以。即使是他們先拉響了警報。
同時你也應該和技術支持部門的人聊聊。比起市場部的人，用戶把不滿更早也更不留情面地先告訴了他們。
3.我們有用戶體驗小組去管那些事
有些大公司里會有一個用戶體驗小組來處理每一項用戶交互。如果你們那里有，你可能已經發現了，他們的時間總是排得很緊，就像那些眼科醫生一樣。你可能求了他們6個月，才能約到一次15分鐘的會面。他們沒法幫你去追蹤和迭代。你得自己去消化理解他們在這有限的交流里闡述的原則，并在每天的日常工作中去實踐。
同時，他們的時間（非常客觀地講）總是貢獻給你們公司最重要的對外產品的。他們沒有時間去管那些內部使用的或是第二梯隊的應用。擁有這種小組的公司重視良好的用戶體驗，你在參與的應用也被寄予厚望，然而你的老板并不會給你們提供對應的技能棧或資源來實現這種期望，不是嗎？你得從項目團隊層面準備好自己來做這些工作。
4.用戶體驗設計是藝術家做的事情
那些被稱為視覺設計師的人，其實更準確的說法是裝潢工。我們已經知道，用戶體驗的游戲在到達這一步之前就已經分出勝負了。對他們保持友好，但主戰場不是他們的，是我們自己的。
從哪里獲得這些技能
準確地說，因為貫穿項目的整個開發流程都需要關注用戶體驗，你的團隊中需要有一個具備體驗設計技能的人。這個人知道在文檔保存的例子中如果要做出正確的決定，不能依賴個人的品味或是哲學理念，而是源自實際的用戶數據—了解有多大比例的文檔會被用戶丟棄而不是保存。并且，她應該知道如何獲取這些數據，理想狀況下是從程序直接獲取，如果不能實現就通過專業的訪談或觀察進行。我們從哪里能找到這樣的人呢？又該怎么管理他們？
普通的程序員、極客不知道該怎么做，他們錯誤地認為用戶跟他們差不多，他們做出來的用戶體驗設計會和 Visual Studio 差不多。有時候市場部門的人想插手來做，認為自己和用戶經常打交道所以了解用戶的需求。這就好比你因為自己長了牙，就認為自己可以去補牙了。視覺設計師也想加入，但你知道，這種交互設計問題跟圖形沒什么關系。怎樣才能找到我們需要的人？
讓我們看一下美軍，特別是它的最小單位—步兵排。一個排通常由一名少尉、一名經驗豐富的第一中士，以及大概30名戰士組成。另外每個排還會有一名醫護兵。醫護兵并不是具備完整資質的醫生，盡管戰士們習慣叫他“醫生”。軍隊沒辦法給每個排都安插一名醫生。醫護兵經過訓練，可以初步為傷員干預和穩定傷情—止血、注射、恢復呼吸等。在今天的戰場上，能夠在第一時間提供干預措施，是保證傷員存活的重要鏈條上的第一個環節。
我們在用戶體驗這件事上需要的角色就類似于醫護兵。一個人了解基本的用戶體驗設計概念，以及常見的實踐—比如知道數據是大多數用戶體驗問題的關鍵，知道如何獲取這些數據。有些人還知道怎么快速、準確地生成用戶畫像，以便設計小組能夠快速地抓住誰才是（容易被曲解的）“用戶”。有些人也知道如何又快又低成本地做可用性測試，以確保項目不會因此暫停下來，或是應該直接跳過這些測試。關鍵點就是快速地給出用戶體驗問題的答案。就像醫護兵一樣，關鍵在于黃金時間施救。
有時候在一個重視用戶體驗并擁有一個想要控制一切細節的體驗設計小組的公司里，這種關于醫護兵的概念并不被買賬。回到軍隊的場景里，這些人就是待在后方醫院里的職業外科醫生。如果你的方式正確，這些人其實是在團隊里安插 UX 醫護兵這件事中最大的受益者，比如，當他們被叫來評估那些謎之數據的時候，第一輪的可用性測試結果已經擺在他們面前。
你做得到
我的讀者和學生跟我講，實踐優秀的用戶體驗，最難的部分就是不知道從哪里入手。人們總是經不起誘惑想要直接動手去做開發—OK，我們接下了這個項目，項目排期很緊（總是很緊的），我們開始做吧。No，別浪費時間搞什么用戶畫像了，我們得保持進度。用戶故事？那是什么？別管了，打開Visual Studio就開始做。直接拿來控件擺放拖弄一番，要不要在這里放一個復選框或者是單選按鈕？用一組tab標簽怎么樣？
回想我打開《The Joy of Cooking》那本書時的情形（本書英文版命名為《The Joy of UX》的靈感就是從這里來的），那本書是寫給那些完全沒有做飯經驗的讀者的，它的前言部分名為“站在爐子面前”—這也是我寫這本書的方法，為了讓你能從零開始。
在這篇前言之后，會有7章分別用來介紹打造優秀用戶體驗的7個步驟。每一章會介紹用戶體驗設計的一個特定技能。我是按照自己的實踐經驗來安排順序的，你將看到，其中還會有一些回溯和迭代。如果你跟著這些步驟循序漸進地走下去，最終一定會有很好的收獲，至少比隨意翻開一章然后跳著翻看要好得多。按我一貫的謙虛做法，我把這稱作 Platt UX協議。
第8章和第9章會分別展示一個學習案例，從頭到尾地實踐7個步驟。我將介紹 用戶畫像、用戶故事、草圖繪制、用戶測試、遠程數據監測、安全和隱私，以及最后的簡化。我的學生告訴我，這種端到端的討論能將不同的碎片拼接在一起，是課程中他們最喜歡的部分。
下面是每章將要涵蓋的內容。
第1章：我們將學習并理解誰才是真正的用戶。用戶是男生還是女生，年輕人還是老人，高收入還是低收入？教育類型和級別？他們希望的是什么，又害怕什么？我們以用戶畫像的形式將這些問題記錄下來，形成一個虛構的人來代表我們的用戶群體。
第2章：我們將要了解用戶使用我們軟件的動機，以及他們實際是怎么使用的。他們想要解決什么問題，還是想要維持什么樣的良好狀態？好的解決方案或是感覺良好的狀態有什么特征？我們從用戶的視角，以用戶故事的形式來闡述這些信息。（如果你對于敏捷開發概念中的用戶故事很熟悉，會發現這里說的是另一個東西。）
第3章：我們了解了用戶是誰以及他們的需求，現在，開始繪制一些可能的解決方案。用一個低保真繪制工具（本書選擇了Balsamiq），我們可以快速地做出效果圖，然后就可以拿它來測試、優化，開始一系列迭代了。
第4章：我們用效果圖演示了可能的解決方案，現在就來測試它們。選擇真實用戶再理想不過，但是如果做不到的話用可以模擬和替代真實用戶的測試者也行。我們給用戶測試的產品擬真程度也取決于項目的階段，在整個開發過程中，步驟3和步驟4會持續多輪。
第5章：我們計劃給產品添加某些遠程數據監測，以了解用戶群體是怎么實際使用產品的。我們將會了解哪個特性是他們實際在用的，順序是什么，還有他們使用的硬件是什么樣的。在今天的大環境下，不使用數據監測，就如同在看病診療的過程中不用X射線或其他設備做檢查一樣。
第6章：安全性和易用性經常被認為水火不相容。在這一章，我們會仔細查看兩者之間的交集，去理解當它們出問題時到底發生了什么。我們會形成一項盡可能嚴密的程序安全保障計劃，同時讓軟件保持可用、易用。
第7章：在接近發布產品的時候，我們不該去添加特性，而是要去想辦法降低目前已經提供的特性的使用成本。這是我們對程序的最后打磨。
第8章：我們將通過前面的完整步驟，為波士頓的通勤鐵路系統設計一款全新的移動應用。
第9章：我們將通過前面的完整步驟，為波士頓地區的一家醫院設計一款全新的供病人端使用的網站。 |
內容簡介：在如今的軟件行業里，用戶體驗已經是建立競爭優勢的核心驅動力。沒有優秀的用戶體驗，你的軟件就會失敗，硬件產品或服務也一樣。打造良好的用戶體驗并不難，但是需要你建立起新的思考方式。本書就是一步步通過案例來告訴你該怎么做的。
本書從開發者視角，全方位闡釋用戶體驗設計的相關概念、技術及最佳實踐，覆蓋完整的設計流程，從用戶畫像、用戶故事到草圖繪制、布局以及執行階段。同時，本書還指出了一些在其他用戶體驗指南中常常被忽略的關鍵問題，比如遠程數據監測和隱私安全等。通過本書，你還能找到所需的全部資源和工具：完整的案例分析、設計文檔示例、用戶測試計劃表等。
全書共9章，前7章分別介紹打造優秀用戶體驗的七個步驟，每一章會介紹用戶體驗設計的一個特定技能，第8章和第9章分別通過完整的學習案例，從頭至尾地實踐七個步驟。通過閱讀本書，你將從零開始，實踐優秀的用戶體驗。 |
目錄：贊譽
譯者序
序
前言：用戶體驗支配一切
第1章 用戶畫像1
1.1 給用戶一張面孔1
1.2 創建最簡單的用戶畫像2
1.3 添加細節5
1.4 使用用戶畫像10
1.5 使用用戶畫像獲得成功12
第2章 用戶想要什么（何時、何地、為什么）14
2.1 我們還沒開始編程14
2.2 但用戶也不知道他們想要什么15
2.3 找到參與測試的用戶16
2.4 采訪用戶18
2.5 觀察用戶19
2.6 向極客們解釋22
2.7 講故事23
第3章 繪制草圖和原型圖27
3.1 制作原型：錯誤的開始方式27
3.2 從一張好的草圖開始28
3.3 原型圖制作工具示例：Balsamiq31
3.4 用故事板來說明交互40
3.5 用實際操作來演示43
第4章 讓真實用戶測試46
4.1 持續地測試，貫徹始終地測試46
4.2 為什么沒有測試47
4.3 早早地開始測試50
4.4 從用戶體驗測試中我們能學到什么51
4.5 找到測試者52
4.6 補償測試用戶54
4.7 測試區的設計和布置54
4.8 使用一名主持人55
4.9 任務的設計和描述56
4.10 觀察與盤問57
4.11 用戶測試示例58
4.12 對于可用性測試最后想說的66
第5章 遠程數據監測與分析67
5.1 猜謎游戲的時代67
5.2 遠程數據監測作為解決方案69
5.3 遠程數據監測的演化71
5.4 授權和隱私74
5.5 選擇一個遠程數據監測服務提供商76
5.6 應該追蹤什么77
5.7 遠程監測示例78
5.8 對于今天的原型遠程數據監測的建議82
5.9 錯誤地使用遠程監測83
第6章 安全與隱私85
6.1 一切都是權衡的結果85
6.2 用戶首先是人86
6.3 什么是用戶真正在乎的87
6.4 麻煩預算88
6.5 案例：Amazon.com93
6.6 給我們的應用建立安全性99
6.7 關于安全性最后想說的108
第7章 讓它能勝任工作109
7.1 一切的關鍵109
7.2 從好的默認設定開始110
7.3 記住一切應該記住的114
7.4 使用用戶的語言講話115
7.5 別讓用戶去做本該你做的工作117
7.6 別讓邊緣情況支配主流場景119
7.7 別讓用戶去思考121
7.8 別讓用戶來確認123
7.9 支持撤銷124
7.10 恰到好處的可定制度130
7.11 引導用戶132
第8章 案例分析：通勤鐵路手機應用135
8.1 可憐可憐這些上班族吧135
8.2 當前進展136
8.3 第一步：誰140
8.4 第二步：什么（何時、何地、為什么）143
8.5 第三步：怎么做148
8.6 第四步：測試一下150
8.7 第五步：遠程監測方案155
8.8 第六步：安全與隱私規劃156
8.9 第七步：讓它能勝任工作157
第9章 案例分析：患者門戶網站160
9.1 不錯的初次嘗試160
9.2 現狀如何161
9.3 第一步：誰170
9.4 第二步：什么（何時、何地、為什么）173
9.5 第三步：怎么做175
9.6 第四步：測試一下178
9.7 第五步：遠程監測方案184
9.8 第六步：安全和隱私規劃185
9.9 第七步：讓它能勝任工作187 |
| 序： |
