中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文作者結合自身經驗，并按照實例來分享下可用性測試的具體做法，enjoy~

用戶調研分為兩種形式，一種是定量，一種是定性。

定性的方式里面又包含可用性測試、用戶訪談?？捎眯詼y試是用戶調研中一種定性研究的方法，讓產品更好的服務用戶，可以說是一種低成本高回報的一種研究方法。

今天我主要通過以下幾個層面來講解可用性測試的親身操刀經驗：

一. 什么是可用性測試

1. 什么是可用性測試？

2. 可用性測試的好處是什么？為什么有很多公司不用呢？

二、可用性測試的具體流程及注意事項

1. 需求收集

2. 資料準備

3. 用戶招募

4. 測試腳本設計

5. 預測試

6. 測試開始

7. 輸出分析報告

三. 什么是ASQ？什么是SUS量表？

1. 關于ASQ

2. 什么是SUS量表？

四、可用性測試一般在什么時候進行？

五、什么功能適合做可用性測試？

六、總結

一. 什么是可用性測試？

1. 什么是可用性測試

可用性測試，是通過觀察有代表性的用戶，完成產品中的各項任務，界定出可用性問題并解決這些問題。展開來講就是：觀察代表性用戶；完成所測產品的典型任務；測試出產品有哪些問題；解決問題

舉個例子：

拿咪咕圈圈的彈幕功能來說，用戶通常在什么場景下會使用彈幕，在使用時是否能熟練使用以及是否對彈幕功能有自己的意見或不滿？

• 代表性的用戶：會使用咪咕圈圈看漫畫的深度用戶
• 典型任務：用戶在觀看視頻時，想要發送一條彈幕，再發一條好友彈幕

測試出的產品問題：

1. 覺得填寫@調出好友界面的操作流程比較麻煩且隱藏，期望簡化操作流程
2. 擴大分享到站外好友

解決問題：

1. 可以優化聊天框，將@功能顯示出來
2. 增加擴大分享到站外好友功能

2. 可用性測試的優點是什么？為什么還有那么多公司不用呢？

第一種情況是，他認為我的產品沒問題，用戶都會用，不需要做可用性測試；第二種情況是壓根沒有這個意識，也不去了解學習，就這樣用戶離她們越來越遠，過上YY的生活；第三種情況是，有意識去做，但不專業，害怕做不好，不知道怎么入手

有人又要問了，可用性測試很重要嗎？當然重要。是必須要做的嗎？也不是。因為并不是每次迭代更新都要做可用性測試，會很浪費時間人力成本，可能效果還不好。

那為什么可用性測試又如此重要呢？因為它可以讓你接近真實用戶，除了給你帶來某功能的具體使用情況外，還可以帶給你更多的用戶信息。很多時候，可用性測試就是一次小型的用戶訪談。

二. 可用性測試的具體流程及注意事項

整個可用性測試可以分為以下幾個階段：

1. 需求收集；
2. 資料準備；
3. 用戶招募；
4. 測試任務設計；
5. 預測試；
6. 開始測試；
7. 分析報告

1. 需求收集

通常在進行可用性測試之前，用戶研究員會去向產品經理、設計師、運營等人員收集他們的需求，當然，也可以用鹽組內部提出需求，通常都會有專門的需求收集模版，讓相關角色根據模版填寫即可，然后進行整理匯總。

用鹽需求模版基本包含：

• 需求名稱／功能：描述需要驗證的是什么功能
• 需求類型：是驗證型（已上線）還是探索型（未上線）
• 配合方：在進行中是否需要其他部門人員配合或提供資料等
• 時間要求
• 需求提出方
• 需求背景
• 可用性測試目的：
• 調研內容：比如用戶在使用彈幕社交的看法態度及潛在需求
• 調研對象；
• 提供素材：是否有可疑提供的素材或資料

2. 資料準備

在測試之前，一定要做好資料準備

一個是設備資源，當然不是專業的測試實驗室，擁有各項專業設備、錄音設備、觀察室等，這種測試環境距離我們比較遙遠。對于普通公司來說，實際上不需要非常專業的測試設備。通常情況下只需要2臺電腦、2臺手機。

如果是測試PC端，那完全可以用QuickTime等錄屏軟件，不僅可以記錄操作，還可以錄音；如果是測試iOS移動端，最新的iOS系統已經自帶錄屏軟件了，老系統的話可以數據線連接電腦，通過QuickTime來顯示并錄屏；如果是安卓機，可以在應用市場下載錄屏軟件。

為什么要2臺電腦2臺手機呢？

因為1臺電腦用戶做測試用，1臺是觀察員記錄筆記用，可以把問題直接記錄下來，以免后期再重復且記不清。手機的話，1臺做測試用，1臺錄音用，當然也可以用錄音筆

除了測試設備之外，還需要準備一些小禮物。

禮物根據做測試的用戶來定，如果是同事或朋友，耽擱不了很久的，買點小禮物意思一下即可；如果是你的目標用戶，還很費時間，那投入就大了。

禮物注意事項：禮物可以提前送，打消用戶心理的顧慮和隔閡，能快點進入狀態，用戶拿到禮物后，會比較敬業的完成測試，畢竟拿人嘴短。

3. 用戶招募

很多人不知道在招募用戶的時候，招多少人合適，也沒有對用戶進行區分，所以我們需要了解招募用戶的正確方法：

（1）招募5個用戶

尼爾森博士說：有5個人參加的用戶測試，就可以發現85%左右的產品可用性問題。

為什么5個就夠了呢？Jakob Nielsen博士統計了尼爾森集團在2012年做的83個可用性測試項目發現：參與可用性測試的用戶越多，并不能發現更多的問題。

（2）招募目標用戶

做可用性測試一定要招募目標用戶，不是真實用戶的話很難融入到場景當中，反饋給你的沒有太大幫助。還有一點是，招募的用戶需要有能力并且有經驗完成任務，而且有一定的動機來完成。

舉個例子：

咪咕圈圈是一款偏向二次元用戶的產品，那么在招募用戶時，就需要招募對二次元感興趣的用戶，喜歡看二次元的內容，即有一定動機來完成任務。

如果項目很簡單，只想測試一下項目的交互流程是否有問題，為了節約成本，可以找其他部門同事來幫忙，做肯定要比不做要好，避免后期開發階段發現太多問題導致推翻方案或項目延期

招募用戶時，還需要做用戶篩選，用戶一般分為：小白用戶、大眾用戶、深度用戶，如果只招募其中的一種，那么結果很定會有偏差。小白用戶對于行業不了解，像一張白紙，很難提出建設性意見；專家用戶對產品足夠了解，他會去關注各種細節，所想的范圍超出了普通用戶的范疇。所以在招募時，這三種用戶都需要招募，這樣能反饋更多有效的問題。

（3）招募用戶有哪些途徑呢？

對于B端產品來說，用戶招募不是問題；對于C端比較簡單的可用性測試，直接找內部同事即可，最難的是C端真實用戶的招募

基本上有以下幾個方法：

1. 核心人際圈：你的同事，其他部門的同事、朋友等
2. 萬能的朋友圈、各大微信群
3. 符合測試條件的陌生人：官微、官博、粉絲群等等

舉個例子：

近期在做的項目，需要找初高中生群體測試產品的核心功能，我們首先在公號、app的banner區域宣傳，還有運營部門的外部支持，以及可以匯集初高中生較多的地方宣傳招募，成功征集到6個真實用戶做測驗

4. 測試任務設計

任務的設計，是整個測試的關鍵點，任務設計的好壞決定了后期的成敗。

（1）首先要明確測試的目的，這個一定要牢記

（2）確定測試的功能

在設計任務的時候，一定要明確本次測試的重點是什么，這個在前期收集需求的階段就要明確，一個模塊包含很多個功能，如果每個功能都測一遍，那用戶也會很不滿意，所以一定要有所取舍，而且最好在正式測試之前，先預測試一番。

關于測試的時長，最好控制在1小時左右，這樣，用戶也不會覺得煩

（3）任務設計要場景化、情感化

任務場景化，是測試人員很容易忽略的問題。設計任務時可能只簡單描述一下任務，比如，打開咪咕圈圈app，在看動畫的時候發一條彈幕吐槽一下。這樣描述問題，很難讓用戶帶入到場景中，結果就是簡單完成了任務，但是不能給你反饋的建議。

那我們怎么設計呢？我們要營造一個氣氛，讓用戶感覺身處在這個場景當中。比如：請選擇一部你感興趣的漫畫進行觀看，在觀看的過程中你發現有一個畫面很有趣，想發表吐槽，并且分享給你的好友

（4）任務設計的數量

在設計任務時，經常容易設計的任務過多，前面講過，1個可用性測試最好在1小時內完成，時間過長的話，用戶的耐心和配合度都會減弱，1小時內完成3－6個任務是比較合適的。如果每個任務都很重要的話，可以分成2次來測試，先測一部分，剩余的并入下一期來測；或者是本期測完，但真對某些任務只測部分用戶

5. 預測試

預測試是指把測試設備、測試腳本都準備好，按照正常測試流程走一遍，盡可能的模擬真實環境，主持人要講完所有的串詞，注意不是拿稿子念，觀察員要看完用戶操作全程并記錄，如果真實測試是在戶外進行，還要考慮Wi-Fi不良的情況。

預測試的結果也要寫進分析報告中，非百分百的真實用戶提出來的體驗問題也是具有參考意義的。

預測試結束后，需要問一下被測用戶在整個流程中是否有不適的地方？哪些環節是我們需要完善的？主持人和項目組討論復盤整個流程和所有文檔。

復盤后改動的工作量可能比較大，所以預測試和正式測試最好不要放在同一天進行，這樣有比較充足的時間修改和打印資料。

6. 開始測試

測試的時候總會有一些意想不到的情況發生，比如忘開錄音、錄屏，測試人員經常會偏離測試任務等。

那么在測試進行時，需要注意哪些問題呢？

（1）關于測試人員

測試人員最好2個，不要超過3個，為什么不能超過3個呢？可以想象一下一群人圍著你看你完成任務是什么感受。人太多會給測試者帶來心理壓力，選擇座位的時候也要注意，讓測試者坐主要位置，讓被測者有一種主人的感受，最好不要面對面做，要有一定的角度。

測試人員分為主持人和觀察員，有人會說，一個人豈不是更好？其實并不是，一個人的話往往會讓氣氛比較尷尬，有時候你都不知道該說什么了，或者出了問題沒人提醒你。

主持人最好是項目相關人員，比如產品經理、交互設計師，其次，主持人最好具備良好的溝通能力和隨機應變能力。

主持人需要注意用戶在做任務時的操作和我們預想的不一樣而打斷，直接引導他們完成任務，這是測試中很忌諱的，對于新手主持人一定要親自跑一遍流程，主持人要和藹可親，不要板著臉，最好和用戶成為朋友。

觀察員要默默降低自己的存在感，跟用戶打招呼，介紹自己，然后坐一邊默默觀察全過程，并記錄發現的問題。觀察員切記不要直勾勾盯著用戶，會讓用戶感到緊張不安，除了在專門的提問環節，不要隨意打斷測試插入問題。

如果很多人都想參與測試呢？我們可以輪換著聽，或者把測試后的錄音錄屏等資料給他們

（2）測試的環境

最好找一個相對安靜、不會被打擾的地方進行測試，以防被測者被外部環境打斷和圍觀，如果使用產品的場景就是在戶外或者公共場所的話，那么要保持和使用場景一致或相似。

（3）暖場

暖場是指測試前的簡單介紹，包括自我介紹、本次測試的目的、緩解氣氛，把用戶帶入測試場景。可以和用戶聊聊被測產品相關的小問題，平時怎么用的？一般什么時候用？感受怎么樣等等

介紹測試時，一定要強調，我們測試的是產品，不是用戶本人，告訴用戶本次測試大概需要多久時間，讓用戶有個心理準備。但盡量少說一點，比如可以說這次測試大概需要半小時，但實際上可能達到1小時以上。

還需要告訴用戶在測試時會錄音、錄屏，便于后期整理，但是一定會對測試資料進行保密。

還有一點一定要告訴用戶：在測試期間您有任何問題，都可以問。但我可能不會立刻回答，因為我想知道大家在沒有旁人幫助的時候會如何做。如果測試結束后，還有問題我將盡最大努力做出回答。

（4）發聲思考法

發聲思考法是指：用戶一邊操作，一邊說出心里的想法，有些用戶不太懂，測試人員可以演示一下。這樣的話我們方便了解用戶的真實想法，了解用戶和我們的任務是否偏離，反饋更多我們意想不到的信息。

有時用戶進行測試時，默默的完成了任務，忘記了發聲思考，我們可以以問句的形式去提醒用戶：

• 您現在看什么呢？
• 您現在想什么呢？
• 您現在在做什么操作？
• 您覺得接下來怎么做比較好？
• 這是您想要的結果嗎？
• 您現在覺得怎么樣？

（5）不要對用戶進行指導

有時用戶在做任務時，不知接下來如何操作或者問你該怎么操作等，有的測試人員覺得被測者很笨，實在受不了，直接告訴用戶。這是做測試時的大忌，我們需要時刻記住，我們測試的是產品，不是用戶。

當用戶偏離你的任務時，你可以提醒下用戶；當他不知道怎么操作或者某個地方是否能點擊時，你可以鼓勵用戶去嘗試下，而不是立即告訴用戶答案

（6）時刻觀察用戶

在測試時，需要注意觀察用戶的肢體反應和情緒、表情變化，并不時的問用戶為什么感到驚訝、疑惑等。方便我們挖掘更多有用信息

在做完一個任務時，趁著用戶記憶還比較新鮮，可以讓他們直接說出來自己的體驗或者不好的地方；在用戶操作任務時發現用戶有異常情緒但沒緊跟著追問，可以在這時候補問。

（7）再來給大家簡單歸納一下流程：

整個測試階段的流程大致為：

• 開場白：做簡單介紹，說明錄音錄屏情況及保密協議簽訂等
• 事前訪談：詢問用戶背景、基本信息，及任務相關內容
• 事前說明：發聲思考法介紹演示、設備的簡單操作等
• 任務執行：提示任務并觀察
• 事后訪談：詢問用戶有什么感想、評價和期望等
• 結束：支付報酬、感謝、送客

7. 輸出分析報告

分析用戶測試數據，總結報告，推動完善產品，才是我們的終極目的。

具體怎么做分析報告呢？

根據我們前期的記錄和錄音錄屏開始整理，把整個測試任務中遇到的問題和測試出來的問題記錄下來，然后對這些問題作出區分：關鍵問題、重要問題、次要問題，然后將這些問題反饋給產品經理、開發、設計師，根據這些問題進行優化排期。

• 關鍵問題：該問題未得到解決，用戶無法順利完成任務
• 重要問題：該問題未得到解決，將影像很多用戶的實際操作，比如多次操作不成功、用戶求助度很高等
• 次要問題：用戶在操作時可能感到麻煩，但仍然會繼續完成任務，比如有些按鈕、反饋很不顯眼，需要仔細查找。

三. 什么是ASQ？什么是SUS量表？

1. 關于ASQ

通常我在設計測試腳本時，會在每個任務后面，針對該任務進行一個小問卷調查，通常包含2-3個個問題，只需要打分即可，對用戶來說很簡單，輔助我們客觀評價任務。

上圖這個問卷，也可稱為ASQ量表，即情景后問卷，是讓用戶完成一系列任務或者一個情景任務后，對產品進行可用性的評價。最好是完成1個任務后就開始回答一下，這時的記憶最新鮮，具體設置幾道題根據具體情況而定，量表的分值可以設為5分。

ASQ問題涉及到可用性的3個方面：有效性（問題一）、效率（問題二）、滿意度（問題三），問題如上圖所示。

什么時候要用ASQ量表呢？可以讓用戶完成1個任務后填寫，也可以完成全部任務后填寫。如果這個任務不是特別重要，也可以不設置ASQ

2. 再來說說SUS量表。

SUS量表，即情景后問卷，量表一般由10道題組成，包括奇數項的正面闡述，也包括偶數項的反面闡述，要求被測者在使用產品后對每個題目進行打分，滿分5分。

SUS的優勢在于小樣本量都能得出較為準確的結果。

SUS量表題目如下：

當參與者完成問卷之后，我們開始打分，奇數項的記分采用原始分數－1，偶數項得分采用5－原始得分，由于是5點量表，每個題目的得分范圍是0-4，SUS的范圍是0-100，故需要將每個題目得分相加后再乘以2.5，即可獲得SUS的最終分數。

SUS的平均分數為68分，50以下是不可接受的，70分以上是可以接受的。

舉個例子：

用戶1的計算公式為：Q1（5-1）＋Q2（5-1）＋Q3（5-1）＋Q4（5-2）＋Q5（4-1）＋Q6（5-1）＋Q7（5-1）＋Q8（5-1）＋Q9（4-1）＋Q10（5-1）=37

然后37*2.5=92.5，這樣就得到了用戶1的得分，再把其他用戶的得分算出來，最后得出平均分為84分

在使用SUS量表時需要注意什么呢？

（1）10個題目中，有個別題目對參與者來說比較難以理解，比如2、5、6題，需要和參與者進行解釋。也可以根據具體情況優化一下問題表達方式。比如第二題，可以改為：我認為這個產品太復雜。第五個問題可以加上文字說明：我覺得這個產品多種功能結合的很好（比如我想要的一些基本功能都有，并且很容易找到）。第六個問題加上文字說明：我覺得這個產品有太多不一致（比如文字提示不一致、點擊某個功能后出現的頁面和我預想的不一致）

（2）在使用時，需要把“產品”換成我們產品具體的名字，如“咪咕圈圈app”

（3）SUS問卷除了給我們一個科學的打分方法以外，還有助于我們對用戶進行追問。

四. 可用性測試一般在什么時候進行？

1. 四個階段

（1）產品開發初期

也被稱為探索式測驗，這時候是對初期概念在市場上進行驗證，并評估這一概念的可行性及后期的如何運作變現

（2）產品實現中期

這一階段主要是對某一功能的交互流程進行驗證，看能否跑通，其次是對交互或視覺上不同設計方案的驗證

（3）產品開發后期

主要是檢驗產品的性能、功能方面是否達到標準

（4）產品上線后

這一階段主要是為下一次的迭代做準備，更加深入的了解用戶群體對該產品的使用體驗及意見反饋

PS：可用性測試能在初期的時候做，就在初期做，這樣避免后期各種狀況不佳導致推倒產品重來的危險，成本巨大。

2. 舉個例子

目前我們在做一款新的app，在放手做前期，就開始做市場調研、用戶人群定位，充分了解該項目從各方面都可做的情況下，才開始動手去做的。

在原型、視覺稿出來之后，會出demo給到被測人員做可用性測試，檢查使用流程上是否麻煩、流暢等，從視覺上，是否有icon表意不清等問題，檢查出問題后再去優化，然后才是程序開發階段，后面還有階段包來驗證產品等等。產品上線后還要繼續新一輪的用鹽分析。

五. 什么功能適合做可用性測試？

不是所有的產品和功能都要做可用性測試的，比如一個表單、一個字段的修改等等，是不需要去做測試的。

那什么情況和功能適合去做呢？

（1）新開發的產品，急需得到驗證

我們需要對整個產品的核心功能做測試，來驗證產品是否符合目標用戶的需求，用戶在使用中是否有疑惑

（2）功能變更?？赡苁遣僮髀窂降淖兏?，也可能是功能入口的變更

比如對不感興趣功能的交互，以前是點擊之后出現彈窗，現在是長按直接拖出畫面，部分用戶已經習慣了之前的交互方式，需要對新的方式進行測驗

（3）新增比較復雜的功能

有些功能會比較復雜，步驟比較多，這種情況也需要做一下測試，看看用戶的接受度，看哪里需要做出調整

（4）設計階段有爭議的

當在設計前期，無論是交互層面還是視覺層面，雙方觀點不一致，誰也說服不了誰，或者拿不準到底用哪套方案，可以去做一下可用性測試，看哪種方案接受度更高

當你想所有的功能都做測試，但有沒有那么多資源，可以通過以下步驟來確定：

（1）討論測試功能

從以下幾個方面例舉：

• 經常使用的
• 主推的
• 新的
• 早期版本反饋中有問題的
• 對用戶來說重要的
• 如果不正確使用有潛在危險或者不良作用的等等

（2）通過功能優先級排序法來篩選本次測試的功能

通過給每個功能的重要程度和對于該功能的疑問打分，并且相乘得出總分，來突出每個功能間的分數差異。

（3）確定本次測試的功能

六. 總結

以上是我的個人經驗，有了可用性測試的結果，在評審或者后期做方案時會比較有說服力哦~

可用性測試完成之后，記得抄送相關同事及領導，或者也可以內部現場匯報一下結果，讓大家都有一定的了解。可用性測試是讓設計師變被動為主動的有力工具，一定要用起來哦～

本文由 @?安迪 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Pexels，基于 CC0 協議