UX 神話——原型設計、用戶測試和 UX 可交付成果
已發表: 2022-03-11神話。 高大上的故事。 誤解。 這些是我們聽到和相信的事情,但不一定是真的。 在幾乎所有領域,包括用戶體驗設計,神話可以改變那些實踐以及那些從實踐中受益的人的看法。
例如,一個普遍存在於設計項目中的用戶體驗神話是,“我們來自這個行業,所以我們知道用戶想要什麼。” 事實證明,這很少是真的,我們發現為了最終用戶的更大利益和更高的成功機會挑戰這一說法是個好主意。
作為 UX 設計師,我們的目標是通過嚴格和有條理的設計流程來創造更好的用戶體驗。 由於常見的誤解,讓客戶相信這些流程可以帶來的價值通常具有挑戰性。 解決這些神話將幫助用戶體驗設計師克服設計過程中的障礙。
UX 神話:原型
原型是必不可少的設計資產,有助於快速反饋、用戶洞察和更高效的設計流程。 不幸的是,由於幾個用戶體驗神話,它們可能很難賣。
誤區 1 – 原型花費太多時間:錯誤
在整個設計過程中,當用戶體驗設計師有明確定義的目標和一些現有數據作為任務流程的基礎時,他們可能會創建快速原型。 這可能會導致原型只有三個屏幕:
- 用戶來自哪裡(這可能是通知或登錄)
- 用戶要去哪裡(大多數情況下是主屏幕)
- 他們需要做什麼(任務目的地)
以下是一些有助於快速原型製作過程的設計工具:
- 紙質原型:在某些情況下,拿出一些網格紙和一些彩色標記並創建紙質原型可能會更容易。 這些可以是詳細的、半功能的並且對用戶反饋有用。
- 原生移動產品: InVision 和 Marvel 在需要逼真的全屏模式進行用戶測試的原生移動環境中運行良好。 其他原型工具(如 Figma)使用“鏡像”方法,要求筆記本電腦始終處於開啟狀態、穩定的 wifi 連接以及它們在單個目標移動或平板設備上的鏡像應用程序。
- 表單和登陸頁面: Webflow 和 Axure 非常適合需要感覺像 HTML 的表單,允許用戶通過選項卡瀏覽並向字段添加內容。 這些工具也具有響應性,並且在用戶的計算機或設備上進行測試時會感覺很自然。
- SaaS 桌面:有多種選擇,其中一些具有協作功能,例如 Atomic、Adobe Experience Design、InVision、Axure、Justinmind 和 UXPin。 特別值得一提的是 Marvel App,它內置了用戶測試功能和快速報告功能。
- 數據驅動:如果用戶需要查看實時數據或集成,則可能涉及一些編碼。 一些促進這一點的工具是 Bubble.is、Framer 和 Axure。
- 交互:當挑戰是試圖找出產品如何對用戶點擊或外部事件做出反應或反應時,Hype Pro、Principle、Flinto、Adobe Animate 和 InVision Studio 等工具提供的動畫可以改善用戶與產品。
誤區 2 – 原型是最終設計:錯誤
原型一詞通常與可能需要數月才能構建的昂貴設計工作錯誤地聯繫在一起。 然而,原型通常用於驗證產品的可用性和成本遠低於對最終設計進行更改。
如果特定產品的最終設計沒有獲得批准,仍然可以使用成熟的設計系統(如 Material Design、Atomic Design 和 Bootstrap)開發原型。 原型不是最終設計; 它們是重要的人工製品,可以告知並減少最終設計“失敗”的機會。 ”
誤區 3 – 五名用戶將發現 85% 的可用性問題:錯誤
一個流行的 UX 神話是只需要五個用戶就可以發現 85% 的可用性問題。 這在該領域很少是真的。 在題為“測試網站:五個用戶還遠遠不夠”的文章中,Jared Spool 和他的團隊這樣說,“我們的發現與 Virzi 和 Nielsen 早期工作得出的通常被視為'行業標準'。 我們發現,我們研究的四個網站需要超過五個用戶才能找到 85% 的問題。”
儘管這個神話在某些情況下可能是正確的,例如精益/迭代設計或小型初創公司獲得快速反饋,但對於擁有大量資源和適當預算的大型項目而言,情況並非如此。
那麼它需要多少用戶呢?
對於需要指定數量的用戶進行測試的特定項目類型沒有規則。 這取決於在進行 UX 用戶測試方面經驗豐富的範圍、預算、時間和設計人員。
UX 神話:用戶測試
用戶測試可幫助設計人員在產品最終確定和發布之前獲得對潛在問題的寶貴見解,從而節省時間、金錢和產品故障的風險。
誤區 1 – 用戶不知道他們想要什麼:錯誤
用戶知道他們想要什麼; 他們只是不知道如何表達。 研究人員和設計師的工作是在不展示最終設計的情況下從用戶研究中發現這些見解。 進行用戶測試以找出對用戶有效的方法以及無效的方法。
一種常見的做法是構建三個或更多原型並部署用戶測試,以獲取的不僅僅是知道什麼有效或無效,而是更深入地了解用戶真正想要什麼。 當本著創新的精神這樣做時,每個人都普遍認為這具有良好的商業意義。

誤區 2 – 分析和 QA 等同於用戶測試:錯誤
分析不是用戶測試。 這是一組顯示過去發生的用戶活動的數據,雖然它可以告知用戶“做了什麼”,但分析無法告知他們“為什麼”這樣做。 “為什麼”來自用戶測試,是改善用戶體驗的基礎。
一個很好的例子是可口可樂和百事可樂的口味挑戰。 分析會告知過去一年可口可樂或百事可樂在某個地理區域的銷量,而用戶測試會蒙住同一地理區域的人們,以找到他們最喜歡的軟飲料。 分析告訴我們,可口可樂的銷量增加了 30%,但在口味測試中,75/100 人更喜歡百事可樂的口味。
然後可以測試假設以驗證為什麼人們更喜歡百事可樂的味道,而可口可樂的銷量更高。 它可以是廣告、營銷、包裝、價格、貨架位置或品牌聲譽。 分析無法告訴我們原因,但用戶測試可以。
質量保證 (QA) 測試包括確保設計團隊為產品和/或產品功能集提供最佳可用性體驗和代碼的所有活動。
QA 對產品設計過程至關重要,但它不使用與用戶測試相同的科學方法或產生相同的結果。
正在測試的功能集的歷史參考(經過驗證的用戶故事、用戶與原始問題交互的視頻剪輯以及顯示該功能應該如何構建的原型)有助於開發人員和 QA 工程師。
用戶測試可以幫助驗證 QA 假設,但它不能替代 QA 測試。
誤區 3 – 辦公室的任何人都可以進行用戶測試:錯誤
有些人天生善於提問和觀察行為; 但是,在執行正式的用戶測試時,最好有訓練有素、經驗豐富的專業人員(UX 設計師),他們可以了解用戶與原型交互中的微表情和最小的細微差別。
在用戶測試期間通常會發生瞬間動作,這些細節對於項目的成功至關重要。 有經驗的 UX 設計師和 UX 研究人員將迅速掌握這些行動並記錄下來。
如果有任何其他原因讓經驗豐富的 UX 專業人員進行用戶測試,那是因為他們具有敏銳的閱讀肢體語言、捕獲公正數據、在需要時重置測試以及在原型未加載或未加載時獲取重要數據的能力。發生不可預見的情況。
UX 神話:報告和 UX 可交付成果
UX 可交付成果(報告)是設計師在設計過程的每個階段所做的所有工作的結果。 這些可交付成果的價值不容小覷,因為它們為未來的改進提供了信息,並提供了整個產品設計項目的歷史快照。 然而,有一些關於 UX 可交付成果的常見誤區。
誤區 1 – 沒有人閱讀報告:是的
儘管這些報告可能很有價值,但我們都知道它們很少被閱讀。 設計師在設計過程中投入了大量工作,文檔是其中很大一部分。 最終的 UX 可交付成果應在研究的科學支柱之間取得平衡,任何美學重點都已融入其中。
將讀者吸引到報告中的一些想法是:
- 視覺強調- 創建類似廣告的傳播以顯示問題陳述。
- 視覺對比——用說話的氣泡畫出漫畫來顯示用戶的對話。
- 個性化——來自重要客戶的名言及其照片。
- 各種媒體——用戶與軟件交互的視頻突出了確鑿的證據。
- 排版層次結構——大的、粗體的、定量的摘要。
誤區 2 – 報告只能來自外部顧問:錯誤
有一種誤解認為,內部 UX 可交付成果和用戶測試報告的價值不及收取高額費用的外部顧問提供的相同信息的價值。 還有一種觀點認為,外部顧問由於他們在特定行業的專業化或利基而帶來更多價值。
內部報告是免費的,由用戶體驗設計師提供,這往往會削弱他們在執行團隊心目中的附加值。
以下是用戶體驗設計師可以實施的一些技巧,以幫助“銷售”可交付成果及其相關價值:
- 使報告看起來像是由專業顧問提供的; 如果它看起來很重要,它會改變看法。
- 專家的報告是一些最常被引用的文件,因此將其建模為專家市場研究報告。
- 通過在公司全體會議或市政廳分享見解和發現來支持研究。 將調查結果和報告視為對組織的好處。
誤區 3 – 報告的日期是提交的那一刻:錯誤
這個廣為人知的神話可以通過創建一個名為“報告”的文件夾來證明,他們都會死去。 UX 可交付成果是大量辛勤工作的結果,並且在設計過程的所有階段都充當工件。 它們可以包括業務和用戶洞察、路線圖、可用性問題和產品營銷金塊。
與其將可交付成果留在文件夾中死去,不如使用這些最佳實踐來保持它們的活力:
- 將報告和其他 UX 可交付成果添加到公司的生態系統中,以便經常訪問它們。
- 在 Slack、Trello、Jira 或其他可以看到報告的地方添加指向報告的鏈接。
- 當有機會引用報告中的發現時,請包含一個鏈接,以便可以訪問它。
- 將可交付成果轉化為動態文檔、行動項目或任務。
UX 神話,就像任何其他誤解一樣,傾向於將一個重要且有價值的過程變成比它需要的更多的工作。 作為設計師,我們一直在努力證明這個過程及其結果的價值。 了解神話及其真相將大大有助於克服疑慮、改善用戶體驗、提高 KPI,並將幫助許多參與項目的人在此過程中獲得更多信任。
• • •
進一步閱讀 Toptal 設計博客:
- 完善你的用戶體驗設計過程——原型設計指南
- 使用原型進行用戶測試的價值
- 頂級設計師使用的 10 個 UX 可交付成果
- 不良用戶體驗的突出因素