當操作錯誤時,為什麼 使用者 總是先責怪自己?

伴隨著不確定的因素,我們總是無法做得很好。當事情出錯時,我們總想儘快或希望能輕易地了解為什麼會發生,但當 “科技” 這個因素加入後,我們對事物的感知會有所差異,問題也會變得更加複雜。譬如 使用者 操作 UI 時發生的錯誤,我們總是很難找到原因。

連結與關心使用者,是設計師的職責。用設計語言與手法來教導他們如何使用,將最小價值產品(MVPs)給其使用,並進行測試、訪談,最終設計出最佳解決方案。設計師絕不僅僅是設計漂亮的產品而已,也包含怎麼讓使用者有好的體驗,特別是發生錯誤的時候。下段,我將描述遇到設計不良服務而造成任務失敗,並產生自責感的故事。

付錢給政府,卻讓我覺得自己很笨

幾年前,那時我還是接案設計師,我使用英國政府的線上繳稅服務,當我想要使用某些功能時,發現許多字眼是不明確的,我必須用盡全力來猜測。在整個流程中,我竟無法順利瀏覽,顯得我相當愚蠢;介面上使用機械式的用語導致我無所適從。雖然,我知道這不是我的錯,但每當任務過程中發生錯誤,我就會責怪自己。

使用者

我應該要弄清楚到底發生了甚麼事情?哪個環節出了錯?

我知道這個責任不在我身上。一個線上的繳稅服務應該要可被輕易的使用,並讓使用者知道他現在處於網頁何處、如何到達他想去的頁面、如何連結過去、為何處於這個頁面、以及如何返回等脈絡。在這次的體驗中,我感到我是無能力的、失落、以及不安全的,且系統也沒有提供相關的協助與諮詢。

我們真的不是要它好看!因為沒必要讓一個繳稅系統美麗迷人,這不是重點,設計者應該要更關心使用者在每一個步驟或流程中的感受,讓使用者感到安心與安全。畢竟,用戶可是相當謹慎小心把努力賺來的錢交給政府。不過這次,我只感受到我自己還沒準備好,甚至應先閱讀使用手冊。

產生壞體驗,我們應該責怪誰?

當問起誰應該負起這些錯誤的責任,誰應該修復它?你可能會馬上回答:就是介面設計師阿!但出乎意料地,大多使用者(如我)通常會責怪自己,不過介面並不是使用者設計的,為什麼我們要自責呢?

Blame_02

Don NormanThe Design of Everyday Things 一書中,將”責怪”這個概念解釋得相當好,他提到人們易於將錯誤歸咎於自身,而不是怪罪於真正的元兇:設計師與開發者;並解釋為什麼這個行為是錯誤的。可能你會覺得探究這點有點無聊,但這與心理學息息相關,是相當複雜、矛盾與有趣的。

人們討厭不確定性即使是欺騙自己,我們還是想盡辦法逃離它

使用者 的腦筋怎麼運作的?

我們的頭腦會玩一些把戲,讓事情變得更簡單一些,以及更輕易的判斷出方向。

其中一個把戲就是自利性偏差(self-serving bias),它會讓我們把負面的結果推究於外在的因素。換言之,人們會認為好的事情發生,都是歸因於自己的性格特質。若失敗,我們會認為是任務太難;若成功,我們會歸因於我們夠努力。自利性偏差可套用於任何情況,如求職、運動等,不過電腦與應用程式這部分卻是例外。

Blame_03

就人與電腦之間的關係來看,使用者往往會把任務的成功歸因於電腦,而失敗時會指責自己。當然,其中可能還有其他不同的因素,例如年齡、科技使用程度、性別等;不過我們還是可以常常聽到”我是科技絕緣體”這句話。然而,人們卻常接受這樣的藉口,而不是大聲質疑”它並不直覺”;使用者感到自責,且把應該是設計師的錯當成自己的責任。

錯不在你,是設計師

Blame_04

我們來解析為什麼”自責”會發生:

1. 對部分 使用者 來說,電腦還是一個陌生的東西

人們通常對事物都存在特定的概念模型(心理模擬),如我們對”電腦的運作”這件事,雖然不盡然正確,但也足以可以認知初步概念。不過因為有這樣的想法,錯誤就跟著發生。

如果使用者因電腦發生錯誤而感到困惑,且無法以自己的概念模型來解釋,使用者就會產生壓力。此時,他們會選擇最沒有阻力的途徑,就是責怪自己,因為這比試圖了解”應用程式的運作方式”以及”該怎麼正確地被操作”來的快速。但身為開發與設計者的我們,應該要深刻地體會:他們只是使用者阿!不是品質測試者(QA)。

2. 我們常認為“美學”等同於”使用性”

如果app非常漂亮,使用者就會認為我必須會使用它,若無法,他們就會認為是自己的錯。舉個最近的例子:Ello 是一個漂亮與極簡的網站,但因為設計不一致、有太多不必要的動畫、以及許多 bugs,讓它變成使用者的噩夢

3. 告訴 使用者 可用,不等於他們就會用

如果我們告訴使用者可如何執行任務,他們就會相信自己應該也能夠完成。如果他們辦不到,他們就會感到內疚和自責。

4. 習的無助感(taught helplessness 由 Norman 提出)

使用者可能在某次操作與科技產品相關的任務時失敗,導致他們認為以後操作這類的產品或服務也會失敗,因為使用者無法想到具體可改進或解決的方案(例如只要調整字的行距,就可以提升閱讀性等等)。也因此,很容易得到 “我不擅長使用科技產品與服務” 的結論。如此一來,若讓使用者造成極大壓力,就很有可能會失去與你們產品接觸的機會。

如果想要打造出偉大的數位產品,我們就不能讓使用者自責。而設計師與開發者應該要讀懂他們的心,並讓他們了解到他們才是成就好產品中最重要的要素。

此外,設計師絕不能閉門造車,要打造美麗、可用與直覺的介面,需要有與使用者協同合作的流程。

解決方案:UCD、MVP、UAT!

所以,我們該怎麼做來避免上述錯誤的發生呢?身為介面與產品設計師,我們應該更人性化的檢視所有流程。畢竟,我們是打造給”人”用的介面,讓他們感受到團隊的用心,並解決他們的問題。

Blame_05

  • 使用者中心設計(User-centered design) 是目前產業界常用的方法:在研究、測試、建立與創造等階段,需時時刻刻將使用者的目標放在心上。確認使用者是否知道產品的價值、犯的錯誤是否能被修復、以及了解他們的渴望。我們需學習他們的語言並傳達我們的概念,如此,將獲得具有價值的回饋。
  • The MVP:就如此文章 The Guide to Minimum Viable Products 中討論到的,我們必須盡快的將具最小價值的產品(MVP)交給使用者手上,它不一定是要一個具體的產品,它可以是一個手繪稿、原型或服務。因為它的形式並不重要,重要的是讓使用者越快的與你的概念互動,這樣便可透過他們的反饋讓產品不斷的變好,而不僅是停留於口號或行銷式的傳達而已。
  • 提早做測試,且時常做測試:就如此篇文章 – The Guide to Usability Testing 所強調,不要等到高擬真度的原型完成後,才進行測試。因為如果需要大規模的調整,你不能想像開發者會有多氣。所以盡可能的早些進行測試吧,此外也盡量提高測試的次數。更早得到使用者的意見,也可讓開發團隊成員更有信心。
  • 不過測試要有目的:進行測試的手稿、wireframes 或 prototypes 立意良好,但重點在於我們必須定義好測試的目的(假說),而且設計好正確的施測問題。如果回答符合假說,我們可從中得到資訊;反之,我們也可以學習到東西,不過這都取決於我們是不是問對問題。
  • 教育與強調若使用者給你錯誤的反饋,代表可能你也問錯了問題。如同此篇文章 Usability Testing Kit 所述,確保使用者了解你的產品,若他們不慎清楚,結果的錯誤將是自己承擔。我們必須將電腦就是個黑盒子般運作的迷失消除,且告知使用者若發生錯誤也沒問題,我們之後會修復它。
  • 使用者驗收測試(User Acceptance Testing,UAT):別與使用者測試混淆,UAT 是以技術的觀點來檢視介面是否完善。如果你已知使用者想要完成某項任務,藉由這個方法可了解他們是否真的能辦到?並在使用者看到前,找出與解決錯誤。
  • 不要眷戀於感官上的改變:花大量時間調整字距、圖片或選換字體,都可能因不了解原因,還是造成使用者的閱讀挫折。所以,換個方式吧!先專注於使用性上,自然美感也伴隨而來。
  • 準備好改變:假如所有測試結果都顯示你犯了錯誤,別慌張。將重心轉移到修正目的上,甚至將產品砍掉重練。此時,你會找到新的方向、目標與產品亮點。

使過程透明,是消除當使用者遇到錯誤時,對電腦與其應用程式無限信任的神話。此外,讓產品更好並不是使用者的工作,但他們的回饋扮演著成功的關鍵,協助我們設計出更直覺的介面。設計師們,請專注於問題的解決,而非點綴的裝飾性設計

設計就是提供信心

設計並不是一件”耍弄像素”的工作,而是擁護使用者的一種活動。身為設計師,我們不應該讓使用者自行了解技術或科技,而是讓技術或科技懂他們。當我們因設計錯誤,讓使用者自責,很有可能會失去真正能讓產品或服務大鳴大放的機會。

就如 Mike Monteiro 所說:設計就是提供信心的遊戲。

Blame_06

身處服務業中,無論我們喜歡與否,都應該向客戶或是使用者提供”信心”,這代表著必須向他們解釋,我們正在打造符合他們需求與解決問題的產品或服務,若無法滿足使用者,也不是他們的錯。而我們的工作是設計界面,也就是與使用者互動的介質,如果不能符合他們的需求,就會讓使用者產生挫敗感。

打造偉大的數位產品,通常都是對問題與使用者做了相當的努力、改變與了解,這活絕對不簡單。

若讀著想要學習更多關於 UI/UX 的知識,請下載免費的電子書: Web UI Best Practices。這本書分析了33間公司的案例, 並有許多專家提供的建議,如 Jared Spool、Jeff Sauros、 Luke Wroblewski等等。

本文章已獲得作者授權,翻譯自:How Bad UX Makes Users Blame Themselves by Ivana McConell,原文出處 UXPin

本文章所屬設計大舌頭與作者所有,未經授權,不得轉載!如需轉載,煩請通知

訂閱設計大舌頭

隨時關注第一手 UX、UI、科技、設計新知

Facebook
LinkedIn
Telegram
Twitter