好設計測出來——《使用者體驗與可用性測試》讀書筆記
由8月20日第六屆人本設計大會組委會編撰釋出。
《使用者體驗與可用性測試》
1 前言
一直想一個吸引眼球的副標題,最後還是覺得書名上的這個副標題,最能體現這本書的核心。
這是一本入門書籍,所以非常適合我這種互動的初學者。這本書給我的最大啟發,就是發現測試的重要性,之前重點一直關注上設計的理論和技巧上,而驗證設計這個重要的過程沒怎麼關注。這可能也跟我所在的公司環境有,公司從製造行業發展而來,在軟體開發過程中能引入UI/UX設計,在領導看來已經算難能可貴了吧(現狀是幾個專案共用一個UI,UI兼任UE)。
雖然公司一直喊著以客戶為中心,但UE設計人員短缺,更別提對設計的可用性測試,通常對發出的設計稿就是小組內部評審下。如果按照書中的分類應該屬於使用者可用性成熟度模型(作者根據經驗設定的一種類似於CMM的模型)中的搖籃期
設計流程大致分成三部分調研、設計和測試。
2 調研(使用者訪談的技巧)
使用者訪談的技巧
2.1 傳統訪談方式的侷限
反饋意見。反饋意見經常使用者的建議和行為並不一致,比如使用者說“我覺得習慣了的話還是很好用的”,但事實上要真的習慣這個產品,使用者可能要話費很大精力。
假如使用者真的可以想出很實用的點子,並且願意無償提供給企業的話,那麼專業的設計團隊還有存在的必要嗎?
小組訪談(焦點小組)參與人數比較多,每個人發言時間有限,收集來的多是意見、體驗比較少;發言時容易被別人的觀點影響;因為是在眾人面前發言者,發言者難免會對發言內容進行加工和潤色。
一對一訪談。無論是計劃好的問題,還是開放的問題。使用者的一般的回答也是歸納過的,缺乏細節。
2.2 師徒式訪談
師徒式訪談(contextual inquiry),也譯作背景調查法,現場調查法。它的基本基本步驟是:請教 -> 刨根問底 -> 核實
請教。訪談暖場後,慢慢將話題移到需要的主題,進而引出深入的交談。
刨根問底。跟傳統訪談的目的是獲取資訊不同, 師徒式訪談更重視完全理解使用者所講的內容。
核實。大致理解後,把理解的內容複述給使用者進行核對。
訪談結束後將記錄內容整理成情景劇本。訪談的記錄無論是語音還是文字,缺乏使用背景,對於使用者發言,分析時可能會有不同的理解。而是用情景劇本將使用者發言內容用故事的方式來記錄,則會更嚴謹,便於理解。一般地,情景劇本包括:
使用者的個人資訊
使用產品的背景
使用場景
3 原型(原型製作的要點)
原型製作的要點
3.1不要忘記做的假頁面。
在製作介面時確保錯有的選單都能點選,讓使用者在測試的時候更加自然、流暢。一個簡單的方法是,無需測試的功能就統一跳轉到一個介面,顯示“目前該頁面不可用,請返回上一頁”。
3.2 元素的保真度區分對待。
原型中的內容,如網站中的新聞、產品列表;操作中的提示框等。而另一些元素如果跟實際開發的相差很遠,使用者使用原型時將無法得到設計人員想要的結論。這些元素包括:
介面順序、數量
介面元素的位置
連結和按鈕上的文字
介面上的提示性文字
輸入項和格式
操作相關的圖示
3.3 製作原型所需的技能
絕大部分的原型不需要高深的藝術素養或專業的程式開發技能,更需要的是深入理解使用者需求,分析測試所需的邏輯能力,不侷限於已有概念的發散思維能力。
不需要區分崗位,或是需要一個人同時具備這些技能。開發團隊可以一起討論好細節,然後由介面設計人員或是開發人員製作具體的原型。
4 測試(使用者測試的方法)
使用者測試
4.1 使用者測試
使用者測試是一種典型的實驗型產品可用性評價,它是一系列使用者參與評估的方法的總稱,這些方法包括:
4.1.1 使用者測試
發聲思考法(Talk Alound Method)。使用者一邊說出心裡想的內容一邊操作,有助於弄清楚為什麼會導致使用者操作出現問題的原因。在使用者發言和操作的同時,注意一下三點:
使用者能否獨立完成任務(有效性)
使用者在使用過程彙總,是否做了無效操作或是不知所措的情況(效率)
使用者是否有不滿的情緒(滿意度)
4.1.2 回顧法
回顧法(Retrospective Method)。使用者操作後回答問題,補充想要了解的使用者資訊,這樣可以避免打斷使用者的操作。但回顧法缺點比較明顯,如複雜的操作很難回顧;使用者一般在回顧時會自行總結,遺漏很多細節;比較耗時等。正因如此,一般較少使用回顧法。
4.1.3 效能測試
發聲思考法和回顧法都屬於定性分析,如果需要定量分析,則可以進行效能測試(Performance Measurement)。
前兩種方法一般是一對一,但效能測試參與人數較多,一般採用集體測試的方式。測試場所用隔板簡單劃分後,每次5~10人進行測試,每1~2人配一個監督者(可以讓兼職大學生擔任),參與測試者需要20以上。
測試主要對產品三要素(有效性、效率、滿意度),定量體現在:
有效性可以用任務完成率來表示
效率可以用任務完成時間來表示
滿意度可以用主觀評價來表示,一般用調查表的形式
效能測試缺點很明顯,一是時間、金錢成本太高;二是設計團隊無法從測試結果中,找到使用者不能完成任務的原因。
4.2 DIY使用者測試
隨著敏捷開發的迅速普及,正規使用者測試的時間、金錢的成本難以承受。但絕不能因此而放棄測試,在保證測試環節下,進行簡化的DIY測試也能達到預期的效果。
正規使用者測試DIY使用者測試
選擇的主體專業的顧問你和同事
參與者調查公司的註冊會員朋友的朋友的朋友 ……
活動地點帶有單向可視玻璃的專業實驗室會議室或者其他可利用的空間
成果內容豐富的報告(帶動畫)像筆記一樣的報告和對話
其他參與調查會提供高檔工作餐咖啡暢飲
您也可以加微訊號MerciYu備註“量化”進入微信群討論,或直接掃描二維碼。
想學習更多好的產品和使用者體驗設計技巧?歡迎參加2016人本設計大會,本屆大會主題為“可量化效果/可迭代的設計”,邀請了眾多國內的設計領域屆的專家,圍繞設計效果的量化,持續迭代優化設計的各方面進行探討,結合敏捷設計、服務設計、使用者體驗量化等理論和實戰案例,提出各類對設計效果進行量化的方案,持續迭代優化的經驗,啟發網際網路和軟體行業的設計專家和創業者們分享和交流,應用到自己的工作中。
僅需一頓飯錢,現場參會聽聽產品和互動設計專家一天的分享,學會如何量化產品設計中的使用者體驗,不斷迭代設計,改進方法,讓自己能力快速提升,公司快速發展。
巴菲特有一句金玉良言:“Invest in yourself”。對於年輕人才說,提高自己,專注於自己的事業,讓其蒸蒸日上才是最好的投資!
相關文章
- 讀書筆記--《使用者體驗》筆記
- 《使用者體驗要素》讀書筆記筆記
- XtraBackup官方文件讀書筆記和測試筆記
- 大話APP測試2.0-讀書筆記APP筆記
- Teambition可用性測試記
- 《軟體架構設計》讀書筆記架構筆記
- 《軟體效能測試分析與調優實踐之路》(第2版) 讀書筆記(一)總體介紹(上)-真正從效能分析與調優來看效能測試筆記
- 《軟體效能測試分析與調優實踐之路》(第2版) 讀書筆記(二)總體介紹(下)-真正從效能分析與調優來看效能測試筆記
- Lua設計與實現--讀書筆記筆記
- 《Redis設計與實現》讀書筆記Redis筆記
- (原)預測的技法--讀書筆記筆記
- 軟體測試計劃與測試方案
- 軟體測試學習筆記:測試點總結筆記
- 《黑客祕笈——滲透測試實用指南》讀書筆記(1)黑客筆記
- 軟體測試設計
- 《讀書與做人》讀書筆記筆記
- 軟體測試書籍-學軟體測試最好的書
- 軟體測試的設計與組織
- 【軟體測試】學習筆記筆記
- 《Web API的設計與開發》讀書筆記WebAPI筆記
- 《Servlet與JSP核心程式設計》讀書筆記ServletJS程式設計筆記
- 《認知與設計——理解UI設計準則》讀書筆記UI筆記
- 測試案例分享:淘寶網使用者體驗測試出現的8個問題及測試方法公開
- JMeter實戰-全棧效能測試第3、4章讀書筆記JMeter全棧筆記
- 夠快雲庫可用性測試記
- 軟體測試讀書列表 (2013.8)
- 《簡約之美:軟體設計之道》- 讀書筆記筆記
- 大話設計模式 讀書筆記設計模式筆記
- 大話設計模式讀書筆記設計模式筆記
- 《程式設計匠藝》讀書筆記程式設計筆記
- Claude最新九個使用者體驗測試
- 《微服務架構設計模式》讀書筆記 | 第9章 微服務架構中的測試策略(上)微服務架構設計模式筆記
- 軟體測試之功能測試、效能測試經驗談
- TTS 測試筆記TTS筆記
- 好語言,就該善用它——《C++語言的設計與演化》讀書筆記C++筆記
- 軟體測試-測試計劃
- 讀軟體開發安全之道:概念、設計與實施15安全測試
- 《Web介面開發與自動化測試(基於Python語言)》讀書筆記(一)WebPython筆記