摘至 鄒欣《構建之法》一書，以作學習之用

概述

其實，計算機軟體的使用者介面（User Interface，UI）和使用者體驗（User eX-perience，UX）是一個有著豐富內容的學術領域，軟體工程師們在長期工作中也積累了很多相關的經驗

無論軟體還是硬體，都有很多功能部件，各個部件還要有機地結合起來，才能滿足使用者的需求。在使用者體驗領域中，一個著名的使用者體驗的例子是茶壺

茶壺有什麼功能部件呢？茶壺蓋，茶壺體，茶壺把，茶壺嘴下面的茶壺中，這些部件都有，但是它們都滿足了使用者的需求了麼？或者我們可以按照時髦的分類，叫它們{普通茶壺、文藝茶壺或213 茶壺}？

當一個軟體團隊的成員忙著完成自己的“部件”時，他/她是否想到了使用者將如何瞭解這些部件？如何使用這些部件完成使用者的任務？

使用者體驗的要素

使用者的第一印象

使用者安裝軟體之後，軟體第一次啟動，軟體設計者要給使用者什麼樣的第一印象？使用者頭一回來訪問你的網站，你要給他們什麼樣的第一印象？

很多軟體設計者把使用者介面等同於給領導彙報的工作成績單，所有的功能都爭先恐後地出現在使用者面前，唯恐使用者沒有注意到。但是使用者往往會被繁亂的介面弄得暈了頭，無所適從。現在電視的遙控器大多數就是這樣設計的

還有的軟體把自己當成一個毫無感情的工具，早期的一些字處理軟體就是這樣。使用者啟動軟體後，看到螢幕上部出現了一行選單，緊接著好幾行小按鈕，下面就是全白的螢幕。有更好的設計麼？

我們至少可以考慮以下兩點。

1. 誰會是我們的目標使用者？他們是什麼樣的人？他們的使用方式是什麼樣的？使用者是從哪裡進入到這個軟體或網站？他們知道這個產品是做什麼的嗎？使用者想達到什麼目的？怎樣讓他們儘快找到相應的功能入口，完成任務？我們的軟體可能比難用（學習曲線較陡），怎樣才能讓使用者儘快掌握基本功能？

2. 使用者和軟體的第一次使用，很大程度上決定了使用者對軟體的評價。怎樣讓使用者在第一次使用的時候，少花時間（或者不花時間）在對使用者沒有價值的部分（如配置軟體的基本設定、登入、填寫使用者的各種屬性等），而把大部分時間花在有實際價值的功能（如完成任務、消費內容、建立內容）上？

大家平時都說要向某某大師或某某產品學習，把最重要的功能做好交給使用者，把那些無關緊要的功能藏起來，做減法……但是程式設計師們還是會想著把高階功能“秀”出來。我們都用過各種電視/DVD播放器的遙控器，功能很強，按鈕很多吧？你有沒有注意到老人家使用遙控器時的困難？

我們可以用5W1H的方法來判斷。

• Who： 誰是你的目標使用者？

• When：他們會在什麼時間使用你的產品？比如一個郵件應用，使用者在起床時可能更偏向於快速檢視，而在工作時間會發生更多的輸入操作。

• Where：目標使用者會在哪裡和你的產品互動？是晃動的公交車上或陽光耀眼的室外？還是在沙發上？

• What：你的產品是什麼？而使用者的期待是什麼？

• Why：使用者為什麼要使用你的產品？他們的動機是什麼？還有，在眾多競爭產品中，使用者為什麼會選擇你的產品？

• How：使用者是如何與你的產品發生互動的？他們怎麼用？在使用過程中出現了什麼問題嗎？

從使用者的角度考慮問題

我們常說做產品要從使用者的角度考慮問題，這需要有“同理心”。軟體團隊的設計師和軟體工程師有“同理心”（Empathy）麼？什麼是同理心？就是理解別人的處境、心理、動機的能力。西方諺語Put yourself in other people’sshoes. 正是此意。設計不同於傳統的數學題，是沒有唯一的標準答案的。有一顆為使用者著想的“同理心”，是好的產品設計的出發點。

1. 從使用者的角度考慮
曾有網友爆料，福建某銀行公佈的反假幣電子郵箱地址長度超過70個字元（字母和數字組成）。該銀行工作人員解釋稱，該地址在內部使用時是中文，和外網銜接時會變成一長串程式碼。有網友根據GBK編碼翻譯出部分程式碼對應的漢字為“出納與現金管理”。

我們試著猜測一下事情的經過，以及技術人員是怎麼想的。

領導/專案經理：要公佈一個電子郵箱地址，讓人民群眾能發郵件投訴假幣和其他事情！

技術人員：好，內網地址搞好了，工具自動轉成外網的地址。搞定！

測試人員：把郵件地址複製/貼上到電子郵件的位址列，傳送一個郵件試試看，收到了麼？收到了。好，通過！

專案經理：好，把郵件地址印成提示牌，搬到各地的營業處去！

有同理心的軟體工程人員是怎麼想的呢？他們會想到：

我們的客戶是什麼文化水平，平時在哪種情況下會發現假幣，他們發現後會怎樣發郵件報告？

他們會在辦公室裡，一邊喝茶（用前面的三種茶壺之一），一邊用滑鼠和鍵盤複製/貼上郵件地址，然後發郵件？

不會，那他們會怎麼做，我們的產品經理和設計人員設身處地自己做一下看看？手動敲入70個字母和數字組合的地址？

2. 這不是Bug——如果你輸入中文就沒問題了
我在工作中時不時要重灌電腦，我一般裝英文的作業系統。裝好電腦之後，第一件事情就是裝中文輸入法。系統自帶了幾個，我覺得都不夠好，所以我想直接裝最新的微軟拼音中文輸入法。於是我用我司推薦的搜尋引擎，輸入[Microsoft Chinesepinyin IME]，搜尋結果中居然都沒有最新版本的連結。於是我就發郵件給相關專案組的同事提意見。幾經E-mail反覆轉發/問答之後，有一個同事回答：

如果你輸入中文“微軟拼音中文輸入法”。搜尋結果的第一條就是正確的連結！拜託，我之所以要搜尋這個東西，就是因為我的機器不能輸入中文！

3. 使用者需要幫助，但是使用者沒有那麼笨
微軟必應搜尋有一個“實時顯示英語解釋”的功能，但是這個功能把滑鼠所在的所有英語單詞都解釋一下，包括小學生都懂的“a, of, at, on, and,the, he, she, …”，使用者的滑鼠常常會無意地停留在這些詞語上面，你就會看到這個“英語翻譯”功能自作多情地告訴你“a”是什麼意思，順便把頁面的其他文字給遮住了：

我們的PM/Dev/Test在設計/實現/測試這個功能的時候想過目標使用者的英文水平是什麼樣的麼？他們需要哪種程度的英文解釋？如果他們連“a”都不懂，他們能來到你這個網頁搜尋含有英文的結果麼？！

4. 光吃狗食也不夠
微軟公司有“吃狗食”（Dogfood）的傳統，團隊成員都儘可能在實際工作和生活中使用自己開發的產品（從內部測試版開始），從而發現問題。我在Outlook團隊做開發的6年中，大部分時間都使用非正式的測試版本，有些是前一天剛構建好的產品。這種傳統保證了開發人員能瞭解軟體功能的實際表現，是非常有道理的。對於自己的產品，如果我們的員工經常“吃狗食”，上面提到的問題就不會出現——除非微軟員工連“a”都需要解釋……

但是，這種優秀的傳統也有一個副作用，由於我們十分了解自己寫的軟體，而我們的心理、技術能力和一般使用者有很大差別（參見下文提到的“認知阻力”），所以也會出現問題。有一次，一個同在微軟的朋友給我打電話，問電子郵件軟體Outlook的一個怪問題如何解決。我說，你到選單上Tools |Option | Advanced …然後把某一個選擇框勾選掉就可以了。

他說——我哪敢啊，這還是高階選項（AdvancedOption），萬一搞錯了怎麼辦？

很多程式設計師都沒有意識到，使用者對那些選項對話方塊中的種種選擇會有很大的畏難情緒，而程式設計師則覺得自己開發的功能必須有幾個高階選項，才顯得有水平。

軟體服務始終都要記住使用者的選擇

使用者使用任何軟體來解決問題，軟體從頭到尾的各個部件要結合起來把使用者的問題給解決了。這樣的問題，可以通過“基於場景的設計”來強化團隊成員對使用者體驗連貫性的理解。

短期刺激和長期影響

很久以前，百事可樂和可口可樂在市場上競爭很激烈，有一次，百事宣佈其新型飲料在使用者試驗中大獲好評，測試使用者“嚐了都說好”，可口可樂公司立馬買了對方的飲料，在自己的實驗室也做使用者實驗。不料結果真的像競爭對手說的那樣，大部分使用者都很喜歡百事公司的新飲料。這下可口可樂公司裡的一些人士開始著急了，紛紛尋找對策。但是過了幾個月，市場資料顯示這個在實驗室裡很受歡迎的飲料並沒有產生巨大的銷量，這是怎麼回事？是投放市場不對，還是供貨跟不上，又或者是實驗室裡的使用者撒謊？後來大家才知道在實驗室裡喝幾口飲料和在消費者家裡喝是很不一樣的。在實驗室裡：大家心裡想著，我要品嚐飲料啦！漱口之後，品嚐幾口或一聽飲料。反饋是：新產品甜味較大，口感很好，我喜歡！在家裡：美國消費者一次買一箱（24聽），隨意坐在沙發裡，一邊看電視一邊喝。反饋是：新產品甜味較大，喝多了太膩味，喝不下去了。再也不買了！

不讓使用者犯簡單的錯誤

大家知道，戰鬥機有[緊急彈射座椅]這一功能，在緊急情況時，它能幫助飛行員逃生。這個按鈕不應該藏得很隱蔽，不然飛行員在碰到緊急情況時半天找不到這個按鈕。如果我們把[緊急彈射座椅]這一按鈕放在戰鬥機控制面板上的這些常用按鈕之中：[噴水刷窗] [FM電臺] [彈射座椅] [機艙燈]可以想象有不少悲劇會發生，飛行員想開啟調頻電臺，啊……這一設計也可以稱為——“腦殘設計中的戰鬥機”。

“不讓使用者犯簡單的錯誤”（Fool Proof）的原則當然是大多數人都同意的，高明的設計能讓操作者不需要花費額外注意力，也不需要經驗與專業知識即可憑直覺完成正確的操作。

使用者體驗和質量

好的使用者體驗當然是所有人都想要的，如果它和產品的質量有衝突，怎麼辦？犧牲質量去追求使用者體驗麼，使用者能接受麼？

GE公司的總裁傑克·韋爾奇講過這個故事：20世紀90年代，韋爾奇注意到核磁共振機的通道特別狹窄，在長達幾十分鐘的檢查過程中，病人常常有得了幽閉恐懼症的感覺。韋爾奇做過類似的檢查，深有體會。他問專家，能不能把通道做得寬一些？專家說那樣會降低掃描成像的質量。他又問，對於那些不需要太高精度的檢查，能否犧牲一些成像質量，換取使用者的良好體驗呢？專家說，他們會考慮的……然後就沒有下文了。不久，競爭對手推出了寬通道的掃描裝置，並奪取了大量的市場份額。GE被動迎戰，花了兩年時間才趕上對方。

情感設計

設計是一門科學，很多方面可以進行數字化的衡量，但是設計也有很多層面。在個人電腦發展的初期，大部分顯示器都是黑白的（有大約256種灰度等級），當彩色顯示器剛出現的時候，設計師唐納德·諾爾曼（Don Norman）借了一臺給自己用，他發現彩色顯示器並沒有增加可分辨的價值，但是實驗結束後，他自己卻很不願意把彩色顯示器還回去。

諾爾曼進一步闡明瞭設計的三個層次，以及對應的產品特性：本能（Visceral）層次的設計——外形行為（Behavior）層次的設計——使用的樂趣和效率反思（Reflective）層次的設計——自我形象、個人滿足感、回憶三個層次的因素相互交織，共同影響了使用者體驗。大部分軟體工程師主要關心的是“使用的效率”，這只是使用者體驗設計的很小的一部分。那我們要在什麼階段，以什麼方式來關注其他方面的設計呢？

使用者體驗設計的步驟和目標

使用者體驗和使用者介面設計的目的是什麼？有哪些步驟呢？一些沒有經驗的工程師覺得，“我先把程式碼寫好，然後有一些會畫圖的人來把介面改一改就好了……”，這種想法是非常幼稚和有害的。另一方面，如果認為工程師只能等著設計師的線框圖才能開始工作，這也是同樣幼稚的。

在上一節提到的三種設計層次之外，使用者體驗設計的一個重要目的就是要降低使用者的認知阻力（Cog-nitive Friction），即使用者對於軟體介面的認知（想象某事應該怎麼做，想象某操作應該產生什麼結果）和實際結果的差異。我們來看一個具體的例子，如果使用者（一個生活在中國二線城市，有高中文化水平，有基本計算機基礎的成年人）要在一個文稿中寫居中的一句話，在下表所列的各種工具中，使用者是怎麼才能做到的。

倘若認知阻力大，學習曲線就會比較陡；但是經過學習和練習，如果使用者適應了新的認知模式，工作效率便會有較大的提高。

如果使用者用的是VI（或者Vim等變種），如何完成這一任務，這個編輯器的認知阻力有多大。一般使用者對於VI這種強大編輯器的抱怨是，它有好幾種模式（Mode），同樣地敲鍵盤，有時候是輸入文字，有時候是控制，我們常見的“紙和筆”沒有這些不明顯的“模式”。

需要指出的是，軟體工程師往往以熟練掌握認知阻力大的工具而自豪（例如命令列操作、VI、Emacs等編輯器），這對於工程師的工作是有幫助的；但是大多數使用者的心理是要躲避認知阻力。

使用者體驗設計有哪些步驟呢？一個成熟和常用的方法是分階段進行設計和探討 。

當軟體團隊沒有確立這些設計階段時，他們就會出現設計時機不當、本末倒置的錯誤。正如前面所說，這是一個迭代的過程，整個團隊要在使用者反饋的基礎上再次進行調研、分析、設計和實現。

評價標準

上面我們提到了這麼多抱怨，那麼對於一個軟體的使用者介面，我們有沒有什麼評價標準呢？可以參考費茨法則（Fitts law）、Nielsen啟發式評估十條原則以及其他經驗[註釋13]。下面是作者在自身實踐的基礎上總結的一些原則：

1. 儘快提供可感觸的反饋系統狀態
要有反饋，等待時間要合適。現在程式發生了什麼，應該在某一個統一的地方清晰地標示出來。一個目標使用者能夠只靠軟體的主要反饋來完成基本的操作，而不用事先學習使用手冊。系統的反饋可以是視覺的、聽覺的、觸覺的（例如手機振動）。但是要避免簡單重複的提示。

2. 系統介面符合使用者的現實慣例（Familiarity，Avoid Surprise）
與使用者溝通，軟體系統要使用使用者語言而不是開發者語言，所用的概念要貼近生活實際，而不是用學術概念或開發者的概念。我們說的生活實際，最好是目標使用者的實際生活體驗。例如，給病人使用的網路掛號系統，就不宜使用只有醫務工作者才熟悉的術語和介面（最壞的結果是使用軟體工程師才熟悉的術語和介面，而醫護人員和病人對此很不熟悉）軟體的反饋要避免帶給使用者驚奇——例如，在使用者沒有期待對話方塊的時候，軟體從奇怪的角度彈出對話方塊，或者給使用者提示“找不到物件”。

識別勝於回憶，要給使用者提供必要的資訊提示（可視&易懂），減少使用者的記憶負擔，從而減少認知阻力。

3. 使用者有控制權
操作失誤可回退，要讓使用者可以退出軟體（很多軟體都沒有退出選單，這是導致使用者反感的一大原因）。使用者可以定製顯示資訊的多少，還可以定製常用的設定。

4. 一致性和標準化
在軟體中，對同一事物和同類操作的表示用語，各處要保持一致。例如，某詞典軟體有“幫助使用者收集生詞並且背誦生詞”的功能。這個功能要有明確一致的稱呼，不能混雜著叫“單詞本”、“生詞本”、“Word List”、“Word Book”、“單詞檔案”……等等。

5. 適合各種型別的使用者
我們的軟體要為新手和專家提供可定製化的設計。一些操作方式，如快捷操作，使用者可以自行調整。我們還應該為存在某些障礙的使用者（色弱、色盲、盲人、聽力有缺陷的使用者、操作鍵盤滑鼠不方便的使用者等）提供一定程度的便利。對於長期使用某個軟體的使用者，軟體應該能適應使用者的使用習慣，讓使用者越用越順手，最後產生感情上的好感和忠誠度。

6. 幫助使用者識別、診斷並修復錯誤
軟體的關鍵操作要有確認提示，以便幫助使用者及早消除誤操作。要注意使用樸素的語言來表述錯誤資訊。錯誤資訊需要給出下一步操作提示（我現在出錯了，那下一步怎麼辦）。必要時提供詳細的幫助資訊，並協助使用者方便地從錯誤中恢復工作。讓所有的使用者都可以通過電子郵件或者表單來提交反饋意見。有些程式用一對簡單的笑臉/哭臉符號來鼓勵使用者提交反饋，這也是很好的辦法。

7. 有必要的提示和幫助文件
不需要文件，使用者就能使用自如，當然更好，必要時還可以提供線上幫助。如果軟體和使用者的工作相關（而不是簡單的遊戲），那麼基本的提示和幫助文件還是很有必要的，而且也要提供便利的檢索功能。文件要從使用者的角度出發描述具體步驟，並且不要太冗長。

有些軟體在首次啟動時會通過圖示或動畫展現某些新功能的用法，或引導使用者進行一些基本的設定（例如第一次使用輸入法時，讓使用者選擇候選詞的個數、字型大小，等等）。這些都是不錯的方法。在PC桌面軟體時代，軟體團隊總是要等到專案的穩定階段才開始寫“幫助文件”，因為之前的軟體介面和功能還有很多變化，然後要很快寫好，才能和軟體一起釋出。在網際網路時代，離線的幫助文件進步到“聯機幫助”網頁；在大量頻寬和活躍的使用者社群幫助下，我們可以看到使用者創造的如何高效使用各種軟體的視訊。這應該給軟體團隊很多啟發——如何能用好各種形式的“幫助檔案”。