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

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

Share on facebook
Facebook
Share on linkedin
LinkedIn
Share on telegram
Telegram
Share on twitter
Twitter