閱讀576 返回首頁    go 阿裏雲 go 技術社區[雲棲]


《用戶至上:用戶研究方法與實踐》用戶體驗入門

本節書摘來自華章出版社《用戶至上:用戶研究方法與實踐》一書中的第1章,第1節,作者凱茜·巴克斯特(Kathy Baxter)[美]  凱瑟琳·卡裏(Catherine Courage)凱莉·凱恩(Kelly Caine)更多章節內容可以訪問雲棲社區“華章計算機”公眾號查看。


用戶體驗入門

1.1 什麼是用戶體驗

如果你開始閱讀本書,說明你對用戶體驗(UX)這個領域有所了解或者有些許興趣。用戶體驗從業者和學生往往來自不同的學科背景,例如計算機科學、心理學、市場營銷專業、商科、人類學和理工科(Farrell & Nielsen,2014)。學科背景的多樣性的益處在於,用戶體驗從不同的領域汲取知識和經驗並最終回饋於用戶體驗。同時,這也說明無法用單一嚴苛的方法和理論來定義用戶體驗。

業內對於用戶體驗有很多定義(詳見https://www.allaboutux.org/ux-definitions)。用戶體驗專業協會(UXPA)將用戶體驗定義為“用戶與產品、服務和係統交互過程中感知到的全部要素。用戶體驗設計包含構成界麵的全部要素,例如頁麵布局、視覺設計、文字、品牌、聲音和交互等。可用性工程協調各個要素之間的關係,並為用戶提供最佳交互體驗”。

提示

如何簡單有效地讓不熟悉用戶體驗的人了解你的工作?可以用一句話來解釋—“讓技術變得簡單易用”。這可能不是最佳答案,但卻可以讓對方快速理解用戶體驗的實質。Kelly在經曆了一遍又一遍解釋自己的工作,對方仍然一頭霧水的窘境後,她在親朋好友以及飛機鄰座旅客裏做了個小範圍的用戶研究,發現“讓技術變得簡單易用”這個簡明的解釋非常奏效。通常對方會說:“哇!好棒!我們需要更多像你這樣的人。”

 

可用性的著眼點是在交互過程中不出錯,而用戶體驗的範疇則更加廣泛和全麵。可用性是客觀的並且以產品為中心(可用性關注一個產品是否可用),而用戶體驗卻是主觀的,並且以用戶為中心(用戶體驗是產品與用戶的合集)。通常情況下,用戶體驗研究肩負著針對新技術(如,移動設備、網站、穿戴式技術、軟件等)探索用戶需求,同時評估現有技術可用性的職責。

用戶需求是指一個產品應該具備哪些功能點或特征才能符合用戶的預期。以用戶為中心的設計是收集和分析用戶需求的全流程。本章會介紹以用戶為中心的設計領域裏的基本概念,不同利益相關方的需求,以及如何令他們支持用戶研究實踐。

哪些人在從事用戶體驗工作

很多不同背景的人都在從事用戶體驗工作(見圖1.1)。業內對於用戶體驗從業者有很多不同的名稱,例如:

用戶體驗設計師

用戶體驗研究員

信息架構師

交互設計師

人因工程師

商業分析師

谘詢師

創意總監

交互架構師

可用性研究員

用戶體驗管理層的崗位包括(Manning & Bodine,2012):

首席客戶總監

首席客戶官

首席體驗官

用戶體驗副總裁

從根本上講,用戶體驗研究關注於如何理解人、環境和技術。盡管我們寫這本書的出發點是用戶體驗研究,但是書中提及的方法也可以用來理解不同場景和技術環境下的用戶行為、感知、想法、需求和顧慮等。

要點速覽:

以用戶為中心的設計

多樣化體驗

如何讓利益相關方支持用戶體驗研究實踐

 

 

圖1.1 用戶體驗學科一覽(www.envis-precisely.com)。此圖由Creative Commons Attribution授權,更多信息可訪問網站https://Creativecommons.org/licenses/ by-sa/30或發信至Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA。出自https://upload. wikimedia.org/wikipedia/commons/d/d5/Interaction-Design-Disciplines.png.

進一步閱讀資源

目前,很多院校都設有human-centered computing、人機交互、工程心理學和信息科學等碩士和博士項目,提供用戶體驗相關的課程。如果你並沒有接受過相關課程的係統培訓,下麵的這幾本書可以作為本書中提到的各個知識點的入門參考。

Norman, D. A. (2013). The design of everyday things: Revised and expanded edition. Basic Books.

Lidwell, W., Holden, K., & Butler, J. (2010). Universal principles of design, revised and updated: 125 ways to enhance usability, influence perception, increase appeal, make better design decisions, and teach through design. Rockport Pub.

Rogers, Y. (2012). HCI theory: Classical, modern, and contemporary. Synthesis Lectures on Human-Centered Informatics, 5(2), 1–129.

Johnson, J. (2014). Designing with the mind in mind: Simple guide to understanding user interface design guidelines (2nd ed.). Morgan Kaufmann.

Weinschenk, S. (2011). 100 things every designer needs to know about people. Pearson Education.

 

1.2 以用戶為中心的設計

以用戶為中心的設計(User-Centered Design,UCD)是關注最終用戶的產品開發實踐,其理念在於讓產品適應用戶需求而非用戶適應產品,也就是說在產品的整個生命周期中涉及的技術、流程和方法都需要以用戶為中心。

專業詞匯說明

我們的一些同事(甚至我們自己!)似乎不太喜歡“用戶”(user)這個詞,因為它帶來負麵的聯想(例如,癮君子drug “user”),造成主觀的距離感,無法表達人本身和體驗的複雜與深度。Don Norman(2006)曾提到“詞匯的選擇很重要,我們談的是人本身,不是客戶,不是消費者,也不是用戶”。我們深以為然。但UX是業界廣為認可的術語,這也是我們在本書中使用它的原因。

 

1.2.1 以用戶為中心的設計原則

UCD三大設計原則(Gould & Lewis,1985):盡早地關注用戶及他們的任務,產品使用的實證研究,以及可迭代的設計。

盡早地關注用戶及他們的任務

這一原則強調係統性和結構化地獲取用戶體驗,這也是本書的重點,在後續的章節會講解收集用戶體驗的一係列方法。

為了實現最大化產品用戶體驗的目標,在產品開發的第一時間就應該關注用戶。越早地關注用戶,在產品開發後期返工的工作量就越小(如,可用性測試之後)。UCD始於收集和獲取用戶體驗,這一過程有助於理解用戶的需求、行為習慣、心理預期以及內心的訴求。這些信息對於設計一款優秀的產品至關重要。

產品使用的實證研究

這一原則的重點在於經典的可用性原則:易學性、有效性和無錯誤,這可以通過產品原型的可用性測試在產品開發的早期實現。可用性測試是邀請用戶來使用設計原型或最終產品完成一係列任務。這個過程可以發現產品的使用性問題,便於在產品上市前做出改進。我們將在本書的第14章介紹可用性評估的相關概念。

 

圖片基於漫畫#5,更多信息可訪問https://www.usability.uk.com/

可迭代的設計

這一原則建議在獲取用戶體驗後,通過迭代的方式來設計、修改或測試產品。可迭代的設計強調的是在產品早期不斷地試錯。早期設計原型要比已經調試好的係統更容易修改。這就意味著你所在的產品團隊可以先從紙上原型(paper prototyping)開始並不斷迭代,再進入可交互原型階段。這個開發流程並不是線性的,而是不斷迭代和調整直至最優。即便你可以非常熟練地開展用戶研究實踐,你也無法在一開始就獲取全部信息。

1.2.2 將UCD原則融入產品開發生命周期中

本書會介紹產品開發生命周期中每個階段用到的研究方法,但在實踐中可能沒有足夠的時間和資源,甚至也並不需要應用本書提到的每一種方法。你需要明確所在的團隊、公司或者實驗室麵臨的關鍵研究問題,並采取對應的研究方法解決問題。Stone(2013)提到,“在我看來,一個優秀的用戶體驗研究包括四個因素,依次是及時性、可信性、可行性和新奇性。及時性需要我們與產品團隊的節奏一致,否則用戶體驗研究的效果會大打折扣。可信性來自於對問題背景的縝密思考和基於此的任務設計。可行性是指與產品團隊在麵臨的決定上達成共識。新奇性是指比團隊中其他成員更善於觀察和理解用戶行為。以上是我知道的唯一訣竅。高質量且高效率地完成工作,人們一定會注意到並感激你的付出”。

圖1.2展示了UCD融入產品開發生命周期的理想情況。“概念”階段(第一階段)主要在產品開發的前期理解你的用戶。“設計”階段(第二階段)包括早期的用戶理解和實證研究。“開發”和“發布”階段(第三和第四階段)更多地側重實證研究。每一階段的具體活動如下:

第一階段:概念

這一階段主要圍繞產品的概念進行如下活動:

建立用戶體驗、目標

構建用戶特征和人物畫像

開展用戶體驗研究實踐,如訪談、實地研究等

第二階段:設計

這一階段會根據第一階段獲取的用戶信息開展可迭代的設計,涉及的用戶研究活動包括:

低保真原型的用戶走查(如,紙上原型)

啟發性評估

用戶體驗活動研究(如,焦點小組、卡片分類法等)

第三階段:開發

在這一階段,開發人員和工程師開始介入產品開發,涉及的可用性測試如下:

準備、計劃和執行產品上市前的啟發性評估

準備、計劃和執行產品上市前的可用性測試

第四階段:發布

這一階段是產品麵向公眾、客戶或你所在的組織發布,包括用戶體驗研究和其他實證研究。軟件的正式可用性測試將在真實的環境下進行。除此之外,在發布階段開展的用戶體驗研究也將獲取用戶在實際使用產品過程中的真實反饋。這一階段所包含的用戶體驗研究實踐包括:

可用性測試

調查或訪談(真實環境下的用戶反饋)

實地調研(了解用戶實際使用產品的過程)

 

圖1.2 引入UCD流程的產品周期

UCD第三大原則—“可迭代的設計”,被廣泛應用於產品開發流程的各個階段。例如,你可以在概念階段開展一次實地走訪,這個用戶體驗研究有助於收集用戶數據,並同時發現新的問題。你可能接下來會進行一對一訪談來獲得更多的用戶數據。這些新的用戶數據有助於改進或迭代用戶體驗研究文檔。

1.2.3 設計思維

如果在你的工作環境中UCD流程並未得到認可,則你的職責更加任重而道遠,僅靠幾次用戶研究實踐可能無法達到效果。一個有效的解決方案是“設計思維”。

如果你的公司、客戶或學術導師並不理解用戶研究的價值,設計思維也許是一個有效的讓人們認識到它的重要性的手段。設計思維可以應用於各種類型公司的創新實踐中。它不是一個按部就班的流程,而是一種思維和觀念模式。它以行為習慣為導向,以人為中心,並展開一係列持續的測試。設計思維的核心思想在於通過深入地理解用戶需求來探索創新機會。這些機會點也將通過快速迭代的原型設計和用戶測試不斷得到優化,最終成為具有劃時代意義的產出。收集用戶需求是整個流程不可或缺的一部分。設計思維讓人們很好地理解為什麼理解用戶對於創造偉大的產品和服務如此重要。Hasso Plattner Institute of Design(斯坦福設計學院)在宣傳設計學院的課程和高管訓練營方麵取得了很好的效果。現在你也可以在其他的院校或谘詢機構找到類似的工作坊。通過一到兩天的培訓,你的團隊可以更好地理解與用戶共情的重要性。

進一步閱讀資源

如果你對建立設計思維文化感興趣,可以參考以下資源:

Hasso Plattner Institute of Design: https://dschool.stanford.edu/.

“Building a Culture of Design Thinking at Citrix”: https://www.mixprize.org/story/reweaving-corporate-dna-building-culture-design-thinking-citrix.

你或許打算進行管理策略改革以影響組織架構、流程和文化,這並不簡單,下麵的書籍包括全麵細致的指導:

Bias, R. G., & Mayhew, D. J. (Eds.). (2005). Cost-justifying usability. San Francisco: Morgan Kaufmann.

Schaffer, E. (2004). Institutionalization of usability: A step-by-step guide. New York: Addison-Wesley.

Sharon, T. (2012). It抯 our research: Getting stakeholder buy-in for user experience research projects. Morgan Kaufmann.

 

1.3 一係列要求

隨著用戶體驗的興起,許多產品團隊開始意識到理解用戶的重要性,並開始重視用戶是否能夠簡單愉悅地使用產品。許多公司和實驗室紛紛將UCD流程融入到產品和科研的生命周期。然而 在很多實踐中,用戶體驗被簡單地等同於可用性測試。

可用性測試與用戶體驗研究有著非常明確的差別。可用性測試是判斷一個給定的方案是否可用(簡單易用並且沒有差錯)。而用戶體驗研究則是幫助團隊從用戶理解的角度出發,在眾多可能性中挑選最佳方案。優秀的設計師和卓越的設計師的差別在於後者對於方案的視野。不做用戶研究,你的視野會狹窄很多。

盡管可用性測試是UCD流程中至關重要的環節,但它畢竟隻是UCD流程中的一個環節。本書更多地側重於用戶體驗研究階段,通常情況下人們對其關注較少,但它實際上卻與可用性測試同等重要。用戶體驗研究可以為設計提供用戶要求。我們將用戶要求定義為產品應該具備的功能或特征。用戶要求的來源非常多樣化,可以是市場、產品開發團隊、最終用戶、購買決策者、方案策劃,等等。產品團隊需要慎重考慮不同來源的有效要求。例如,在設計一款關於旅遊預訂的移動端應用時,用戶需求可能包含如下條目:

該移動端應用在iOS、Android和Windows手機上都可下載和使用。

用戶在下單前需要注冊。

這款應用同時支持英語、西班牙語和法語。

各個人群均能使用該款應用。

用戶無需培訓即會使用該款應用。

接下來介紹在業界工作中可能遇到的不同要求,但這裏提及的建議同樣適用於非營利組織或學術界(如雖然沒有來自銷售團隊的需求,但仍然有其他的利益相關方)。在任何情況下,理解產品有競爭力的要求有助於更好地對用戶要求進行定位。

1.3.1 產品團隊的觀點

在業界,產品團隊通常是對產品有直接責任的一群人,如產品定義、開發和銷售等。在需求收集階段,產品團隊必須進行早期研究來決定產品方向,必須從不同的渠道收集需求(如,銷售、市場、經理、客戶和用戶),並以此來確定哪些功能應該定義在產品上。這一階段為設計奠定基礎,並會影響整個產品生命周期(見圖1.2)。如果需求收集階段出現紕漏,則很有可能造成最終產品無人問津,並無法給購買的用戶和公司帶來有效價值。

在產品開發過程中會存在來自各方的不同需求,不同需求之間可能會存在混淆。圖1.3展示了產品團隊需要應對的需求方和不同的需求類型。

 

圖1.3 產品需求一覽(圖片來源:Weigers,1999)

我們經常在工作中聽到有同事講,“我們已經收集好用戶需求了。”但實際上,他可能隻是收集了功能和市場需求,而非用戶需求。接下來我們探討一下商業需求、市場需求和銷售需求,因為人們經常會將它們與用戶需求弄混。這三個需求都很重要,但是它們都不是用戶需求。雖然其中可能會有重疊,我們仍建議獨立地從各個需求方了解需求,並按照優先級歸納整理。你不能假定銷售人員想看到的產品和最終用戶希望的一樣。為了有效地了解關於產品的不同需求,你必須有效地區分它們。

 

DILBERT 商業需求

購買者對於產品會有自己的要求。這些購買者通常是公司的專業人員或者高層管理者,他們也被稱作決策者。他們的需求一般反映了公司現階段的商業實踐或是為節省成本而開展的新舉措。他們希望產品能夠符合他們的預期。明確理解商業需求對於吸引決策者客戶非常重要。商業需求有時可能會和用戶需求重合,但通常商業需求是更宏觀或更技術方麵的。在學術界,“決策者”可能是你的導師或者學術委員會。

市場和銷售需求

市場和銷售部門的需求點在於產品的銷量,他們會提出他們認為消費者想要的、競爭對手有或沒有的產品功能等。市場需求的表達會更宏觀和缺少細節。市場部門並不關注產品的細節,他們更傾向於從宏觀的角度理解消費者喜歡產品的原因。舉個例子,市場部門對於一款旅行應用的需求可能會是這款應用應該比同類產品提供更多的航線選擇或是最低價保證。

銷售人員每天都在一線和消費者打交道,因此他們的需求會圍繞消費者看到產品展示時的反饋。但我們需要提醒自己銷售人員的受眾通常是“決策者”而非最終用戶。他們可能會要求這款應用“要快”,“要看起來像市場上排名第一的旅遊應用”。再次重申,這些需求可能是嚴重客戶導向的,但並不適用於其他現有或潛在的客戶。

銷售和市場部門通常並不收集具體信息,如,用戶需要什麼產品,用戶如何使用產品,用戶使用產品的場景等。然而,一些市場和銷售需求確實會反映一部分用戶需求。你可能會發現用戶需求和銷售市場需求存在一些重合。如果一款產品不是用戶想要的,它即便再可用也是沒有意義的。市場和銷售人員通常會與用戶聊天,有時甚至會聊到可用性,但即便如此,也是比較宏觀層麵的,例如產品的功能點和性能。這些是非常有價值的輸入,但是問題在於他們收集到的信息通常是不完整的,並僅限於產品展示過程中(更多地在銷售產品而非傾聽用戶)收到的反饋。他們也努力地理解用戶,但因為這並不是他們優先級最高的目標,因而他們也沒有足夠的時間和動力去收集真實的用戶需求。此外,他們希望在產品上加一些新功能的原因是最新的技術是銷售中一個很好的賣點,並不是從用戶需求的角度考慮。

1.3.2 用戶需求

無論你供職於學術界、公司還是非營利組織,你都需要實現利益相關方的需求。這些利益相關方包括資助科研項目的政府機構(例如,NIH)、投資人或股東。平衡用戶需求與商業、輿論或銷售需求是每個人的職責。在一款產品或服務完成之前,你希望其包含用戶真正所需的功能。如果你忽視了這個重要的目標,用戶可能在實際使用產品時需要接受大量的培訓指導,從而造成效率緩慢,滿意度低。這將大大損害開發的積極性、科研的成功率及未來的銷售額,也會降低用戶更換或升級產品的可能性。長遠來看,這甚至會為產品聲譽造成負麵影響,從而降低投資者的投資意向,使得沒有新用戶願意嚐試使用。

通過上麵的討論,你可能會覺得你了解用戶的需求,因為利益相關方已經告訴你用戶的需求是什麼。這是產品團隊犯的第一個錯誤。采購、銷售和市場負責人都認為自己理解用戶如何與產品交互,然後他們(采購、銷售和市場負責人)並不是真正的用戶,他們的理解經常是錯誤的。另外,他們從單一的渠道獲得的用戶信息,其中大量有價值的信息卻在傳遞給你的過程中丟失了。圖1.4顯示了產品團隊從大量存在問題的交流途徑獲取所謂的“用戶信息”。

 

圖1.4 從用戶到產品團隊的信息交流渠道

因此,你必須接觸真正的用戶—那些真正使用產品的人,來了解他們的想法和需求。對用戶的理解包含理解他們使用產品的任務、目標、使用的場景、用戶技能等。

在深入理解這些需求後,可以依此開發符合用戶需求的產品,這將實現:

用戶滿意度和易用性的提升帶來的產品銷量和市場份額的增長。

符合用戶需求的交互界麵降低了產品培訓和客戶支持的工作。

準確把握產品的核心功能點減少了開發時間和成本。

1.4 如何讓利益相關方支持用戶體驗研究實踐

如果與你合作的利益相關方認可用戶研究的價值,這就是一件非常幸運的事。然而,我們發現很多情況下,利益相關方對於用戶體驗研究如何驅動產品創新、提高接受度、提升效率和增大利潤並沒有顯性化的認識。因此,作為用戶體驗從業人員一個重要的能力就是有效地傳達用戶研究的重要價值。

雖然用戶體驗UX對於項目的重要價值並不僅限於經濟收益,但是當你需要說服利益相關方接受並支持用戶研究時,從經濟收益的角度入手會使得溝通變得更有效。好的用戶體驗(UX)會提高生產力,提升用戶滿意度,減少出錯率,降低培訓和支持成本,提升銷量,節省設計迭代成本,提高流量,並獲得更積極的線上評價(Bias & Mayhew,2005)。下麵列出一些幫助你有效展示用戶體驗(UX)價值的具體說辭:

理解用戶體驗(UX)對於創新至關重要。“創新不是發明。創新可能涉及發明,但是包含更廣泛的內容—對於用戶需求和願景的深刻理解”(Keeley, Walters, Pikkel, & Quinn, 2013)。

一個公司客戶體驗質量很大程度上依賴於客戶忠誠度,例如產品回購的意願、更換其他產品的可能性及向朋友和家人推薦的意願等。這些因素一並影響公司的年收入(Burns, Manning, & Petersen, 2012)。

改善客戶體驗,即使在很小的方麵,“也可以為公司每年帶來數以億計的收入增長……所有行業都希望通過改善客戶體驗來增加收入“(Manning & Bodine, 2012)。

從長遠來看,盡早整合用戶體驗可節省未來重新設計的大量工作。Sun的例子表明,早期在用戶體驗研究上的兩萬多美元的投入為公司挽救了一億五千兩百萬美元的損失(Rhodes, 2000)。

1.4.1 反對聲音

你可能會聽到不支持用戶研究的聲音。在表1.1中,我們列出最常見的反駁理由和應對建議。表格左邊的語句你可以直接引用,右邊的內容是每個語句的解釋和支持理由。

表1.1 用戶體驗研究的反對理由以及如何反擊

“我們沒有時間來做這個研究”或“我們項目進度已經拖後了”

“我們可以按照項目時間設計用戶研究。我們可以在一天之內盡可能收集一些初步信息。”

“即使研究可能無法幫助即將發布的產品,我們仍可以將這些數據用於未來的版本上。”

“現在用少量時間可能會在未來節省大量時間。僅在軟件開發過程中,60%的錯誤源於不正確的用戶體驗(Weinberg, 1997)。”

“糟糕的用戶體驗會導致延誤。63%的大型軟件項目的進展超出規劃,很多是與其不佳的用戶體驗相關(Lederer & Prasad, 1992)” 獲得一些信息總比沒有好。

你想讓信息盡快發揮作用,但不要停止收集信息。

通過開展用戶研究來確定產品需要保留和改進的功能是快速並簡單的。可參見Hackos and Redish (1998)大量的案例。

也可參見Johnson (2008),GUI Bloopers 2.0一書的第8章Management Bloopers。在規劃中關於不準確的原因有24個,其中4個最主要原因都與糟糕的用戶體驗相關(Marcus, 2002)

“我們沒有預算來做這個研究”

“創造優質的用戶體驗的投資回報率非常高。2011年的研究表明,客戶體驗可以帶來三千一百萬到十二億的收入。”

“我們的競爭對手知道用戶研究的價值。”“提高產品的易用性可以節省成本。你可能在設計環節花費1美元解決的問題,在產品開發階段可能需要10美元,如果產品發布後,你可能需要100美元甚至更多來解決。”

“我們不能不進行這樣的研究。如果產品未滿足用戶需求,後期的維護成本可能要占到全部費用的80%” 折扣技術很便宜。從小處著眼,累積價值。

用戶體驗是對產品未來收益的投資(Forrester抯 North American Technographics Customer Experience Online Survey, Q4, 2011 (US))。

理解用戶是一個競爭優勢。

在設計早期階段考慮用戶需求比之後解決更經濟。Robert Pressman在Software Engineering: A Practi-tioner抯 Approach一書中計算了設計、開發和發布的成本。

軟件生命周期中80%的成本花在維護階段。很多維護成本集中在“未滿足或不可預見的”用戶需求和其他可用性問題上(Pressman, 1992 via Marcus, 2002)

“如果用戶很蠢的話,這並不是產品的問題”

“你不是用戶。隻是因為用戶和你不一樣(例如,不能記住每個快捷鍵或想不起25~30個字符的密碼),並不代表他們是愚蠢的。並不是每個人都和你有同樣的經曆和培訓”  用戶研究的成果可能讓利益相關方(通常是工程師)看到,即使是非常聰明的用戶也可能與他們使用產品的方式不同。關鍵是讓利益相關方意識到他們並不能很好地代表最終用戶

“用戶並不知道他們想要什麼,”或者“如果你問用戶他們想要什麼,他們會說一匹更快的馬”

“用戶並沒有職責來清晰準確地表達他們的需求。這是我的職責,研究人們的行為和需求。我們從用戶身上獲得相關信息,並將這些轉化為有用的和可操作的信息”  正如產品開發要求的其他技能,理解用戶也是一種技能,是需要培訓和實踐的。用戶不應該被誤認為是設計師。用戶體驗(UX)和產品團隊負責提供可能的解決方案

“我們不想丟掉任何潛在的訂單或者令客戶因為指出產品未做到的地方而不開心”

“當係統符合用戶需求,滿意度會大大提升。”

“根據多年開展用戶研究和可用性測試的經驗,我們從未令公司丟掉訂單或讓客戶不滿意我們的產品。用戶體驗研究可以改善我們與客戶的關係,因為他們看到公司正在竭力理解需求”    1992年Gartner Group研究指出,可用性方法提升了40%的用戶滿意度(Bias & Mayhew, 2005)。

如果客戶認為產品開發或銷售團隊沒有滿足他們的需求,這將導致客戶的不滿,開發和銷售的沮喪

 

“銷售人員對客戶負責。”

“我們都對創建愉快和滿意的用戶體驗負有責任。”

“如果銷售人員沒有時間幫助我們找到研究參與者,我們可以自己來。”

“這是我們的研究” 其他利益相關方可能會擔心你削弱了他們的地位和權利。鄭重說明用戶體驗的目標和銷售不同,你的工作會幫助他們實現目標。

最後,如果你無法接觸到客戶,但總有方式接觸到最終用戶(參見6.4節)。

我們的研究將使利益相關方支持用戶體驗項目,向產品團隊全麵介紹並號召關注用戶體驗(參見Sharon 2012)

“你做出的承諾,我們無法兌現”

“我們不會對客戶做出任何承諾。我們隻會傾聽和收集數據。產品團隊將決定如何在產品開發中使用這些信息”    參與者會理解你是在收集他們的反饋,並不期望你會立刻提出一款滿足他們所有願望的神奇產品,你也並不需要做出任何許諾

“你會泄漏機密信息”

“我們會讓每一個研究參與者簽署保密協議。”“我們會設計一個標準化的研究腳本,並得到團隊所有成員的許可,再將其用於研究中”    參與者很清楚我們的項目基於研究中的問題,保密協議(NDA,參見3.3節)的作用就是確保他們不要將研究公之於眾

“我們已經有用戶信息了。為什麼還要收集更多?”或者“我在這個行業已經有十餘年的經驗了。我知道我們的客戶要什麼”

“現有的信息很好,我們並不打算取代它。然而,我們需要更多的信息來補充已有知識。”

“我們的方法和目標與現有的不同。我們要確保沒有偏見的客觀數據”  說明你將收集的信息會有所不同。比如,你要采訪最終用戶,而非購買決策者;或者你要了解用戶當前完成的任務,而非在原型上獲得反饋。

產品團隊可能已經進行內部的“焦點小組討論”,市場部門可能已經訪談過潛在用戶,銷售團隊也有可能做過他們自己的“實地考察”,但這些團隊都是出於自己的目標

“我們在進行一個不同的流程,所以不要浪費時間學習當前的流程”

“我們需要了解用戶當前的環境,和如果我們改變流程用戶可能會麵臨的挑戰。”

“我們需要理解用戶當前如何工作,因此我們最大化優勢並減少劣勢”  還希望了解培訓的變化。需要中止一些與當前做法不符的設計。你還需要了解變化的連鎖反應。不合適的改變可能會影響其他的組/係統/客戶

“這個產品/流程/服務是全新的。沒什麼可觀察的”

“如果潛在用戶不存在,誰會購買我們的產品?”“總是存在某些用戶和事例,我們可以借鑒用到設計上”   在一開始如何確定產品的需求?總會有手動或自動的流程。我們可以看看哪些並非顯而易見的

“每個人的行為都不同,所以沒有必要研究少數幾個用戶”

“會有個體差異。這就是為什麼我們要研究一係列用戶和環境。”

“隻研究5個用戶就能發現80%最關鍵的產品問題”   通常來講,個體差異可能比我們理解的要小。如果研究中發現差異很大,這是很重要的發現。

研究“少數”用戶很有用(Nielsen, 2000)

 

“我們隻是在改變係統/產品/環境的一部分。我們並不需要研究那麼多”

最成功的係統是各部分都完美地整合在一起的—如果我們隻孤立地考慮其中一部分,這永遠無法發生    係統要比大多數人認識到的關聯性更強。你需要明白適合的情境。要知道,用戶並非孤立地使用某一功能

“我們並不需要這個方法。這個產品僅是內部使用。此外,員工的時間並不計費”

“一個不可用的產品在內部使用時會對公司帶來兩倍的生產效率負麵影響。員工生產力低下,他們需要公司維護支持人員來解決問題”    將時間作為投資。現在花費的時間將節省未來的時間和成本。

我們會在員工不是效率最高時安排研究。例如,選擇在兩個合同期之間的員工

 

1.4.2 避免遭到反對

避免遭到反對最有效的辦法是盡量避免反對聲音混在一起,可以通過以下兩種方式來實現:

獲得利益相關方的支持。

成為團隊的虛擬成員。

獲得利益相關方的支持

本書強調的關鍵之一是“獲得產品團隊(或利益相關方)的支持”。你要讓他們覺得他們對於你進行的用戶研究擁有所有權。

成為團隊的虛擬成員

如果你在組織架構上並不是屬於產品團隊,那麼你需要成為該團隊的虛擬成員。從你被指定到某個項目的那一刻起,你需要努力成為產品開發團隊中積極的和被認可的一員。你需要成為團隊的一部分;否則,你可能會在關鍵信息的共享或重要決定的討論會中被遺忘,即便你可以提供有價值的信息。

如果你是以谘詢的角色自居,產品開發團隊可能隻把你當作局外人。即便你在該產品上投入百分百的資源,開發人員或者管理層也有可能因為你的特殊技能而並不將你視為團隊的一員。如果你不被當作團隊一員,你的研究計劃或發現可能不會被重視。產品團隊甚至認為你對產品的知識或重視程度不夠。很顯然,這並不利於你的工作。

理想的情況是成為產品團隊的虛擬成員。你需要對產品和各個環節中的因素有充分的理解。你不僅僅是找出現有解決方案的問題,而是為產品開發新的解決方案作出貢獻。這可能需要你發展技術專長,並參加與用戶研究和設計不直接相關的員工周會。你需要獲得團隊的尊重和信任,這需要時間。要讓產品團隊明白,你並不是破壞他們的辛勤工作,而是幫助他們開發最好的產品。如何做到這一點?你需要將用戶研究融入產品大局。當然,用戶研究對於產品成功至關重要,但是你也必須承認,用戶研究並非唯一因素。

越早融入產品團隊,效果越佳。你和產品團隊共處的時間越長,你將越熟悉產品,同時你也會收獲更多的尊重和信任。

1.5 下一步是什麼

現在你知道了什麼是用戶體驗,誰來進行用戶體驗研究,UCD原則,你可能與其合作的利益相關方,以及如何讓利益相關方支持你的研究,那麼現在你可以開始規劃用戶研究活動了。在接下來的章節中,我們將介紹在用戶研究活動開展前你應該知曉的信息,你需要考慮的法律和倫理問題,如何開始進行用戶研究,以及如何選擇方法和準備用戶研究活動。你需要獲得他們的同意和支持,用戶體驗活動將有利於他們的產品。如果他們不相信或者對你的研究抱有懷疑態度,那麼他們很有可能在你的研究活動結束後並不執行改進建議。為了獲得他們對用戶研究的支持,你需要讓他們在各個階段(從前期準備直到最後建議)都參與其中。

最後更新:2017-05-19 16:02:00

  上一篇:go  《Spark 官方文檔》Spark作業調度
  下一篇:go  《Maven官方文檔》創建Archetype