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

文章是作者在經過前后三次可用性測試后總結的一些經驗，enjoy~

身在傳統制造業外企，身邊并沒有像互聯網公司的用戶體驗團隊，因此擔著“用戶體驗設計師”的title，常常需要肩負起各類的職責，這其中就包括用戶研究。 雖然曾經在設計咨詢公司有過focus group和家訪的經歷，但和可用性測試有很大的不同， 因此也只好摸著石頭過河，一邊做一邊找資料一邊積累經驗啦。

本文是我在經過前后三次可用性測試后總結的一些經驗，不對的地方希望大家指出啦。

簡單介紹下三次可用性測試的基本情況：

1. 第一次可用性測試——C端用戶App v0.1，10個參與者；
2. 第二次可用性測試——C端用戶App v0.2，10個參與者；
3. 第三次可用性測試——B端用戶網站，5個參與者。

（說明：根據尼爾森的研究，5個可用性測試參與者就可以發現80%以上的問題，由于我司產品為前所未有的創新產品，因此在投入上做了一定的增加）

正文從招募用戶、測試大綱的準備、測試現場、測試結果整理等四個方面來講。

一、招募用戶

1. 招募方式

由于我們的測試需要在一些特定的小區進行，我們在前期采用了在小區內張貼海報的形式來招募用戶。在海報上會對活動的形式、時間地點、獎勵等內容做出說明，同時附上活動群二維碼，感興趣的用戶可以掃碼加入微信群。

本以為會有很多人報名，因為測試地點就在樓下，并且有獎勵，但海報招募的方式并不理想，因為很多人并不會關注海報。

因此我們又增加了一種招募方式——請物業幫忙在業主群里宣傳，這種方式招到了很多用戶，可見使用合適的招募方式是很重要的。

在招募時最好預留充足的時間，這樣可以在招募效果不理想時及時切換招募方式。

2. 招募注意事項

招募用戶時最多的問題發生在篩選用戶的條件上，常規的年齡、性別等指標在這里就不再贅述了，我只列舉一些大家經常忽略但極有可能發生的情況。

（1）考慮用戶的方言問題

在第一次測試時由于客觀原因的限制，測試的小區為北方某二線城市的一個小縣城中高檔小區。在微信群里招募到足夠的用戶后，測試當天傻了眼，10個用戶里有7.8個都講當地方言，不講普通話，因此整個測試過程中全靠猜測才能勉強和用戶溝通，產生了很大的障礙。因此在測試時最好可以電話和用戶進行提前溝通，以避免方言問題。

（2）選擇性格開朗、表達流利的用戶

除去方言外，另一個溝通方面的障礙就是表達問題，有些用戶由于害羞或不善言辭，在測試過程中會需要大量的引導。這類用戶也可以在前期溝通時避免。

（3）拒絕不符合要求的用戶時，措辭要注意

因為前期招募方式的不同，有的人無需注意該項，比如通過網絡填寫信息的方式，只要篩選出符合的參與者即可。我們采用的微信群招募的方式，需要進一步和進群的人進行溝通以了解他們的條件是否符合招募要求，這時的措辭就格外的重要。

在招募時，我們有一個條件是“年齡45歲以下”，當時有個60歲的大叔來報名，招募人員非常實在地告訴大叔年齡不符合需求，結果大叔情緒激動的說，“周末砸了你們場子”。

事后反思，對別人說需求不滿足的話的確比較容易引起別人的反感，因此，可以不必那么實在，而是采用更加迂回的方式，比如：“不好意思，我們這次招募是先到先得，下次有相同的活動我們會優先通知您?！?/p>

二、測試大綱的準備

1. 測試大綱的內容

主持人首先需要對本次活動進行說明，例如目的、形式、時間等等，同時需要在開始時征得被試者對于錄音錄像的同意，簽署NDA等。完成說明后就可以進入正式的測試環節了。

測試大綱基本結構

測試整體分為三個部分，Pretest、Test和Post-test。

Pretest中會涉及到被試者的基本信息，例如年齡段、相關產品使用經驗等，這些內容和后面的測試環節是相關聯的。如果我們發現一個人在操作上出現了問題，那么原因可能是設計的不到位，也有可能是他缺乏相關產品的使用經驗，這個就是從pretest中得到的。

Test環節一般會根據測試的目的和內容分為幾個任務，在每個任務中，參與者會根據主持人的指令完成一些操作，并對操作進行打分。例如：“請在APP中完成登錄操作”是一個任務，主持人在參與者操作的過程中需要錄像（經過允許后），記錄其完成的時間、完成過程中的不尋常的操作，然后再詢問被試者原因。

可參考如下形式：

Post-test時一般會問一些整體和綜合性的問題，例如App整體的界面是否友好，對App的滿意度，App最（不）吸引人的特征，想修改App的什么特征等等，方便得出整體的評價和打分情況。

2. 測試大綱注意事項

完成測試大綱的基本結構后，還有很多細節內容需要修改和潤色，以下詳細展開。

（1）增加發聲思考練習

在第一次測試的過程中，我發現有些參與者想要表達但是不知道如何表達，有些參與者則比較害羞，參與者話少會導致用戶反饋的質量降低。因此在第二次測試的過程中，我在Pre-test的環節中增加了發聲思考的練習，測試的質量有了提升。發聲思考的時候主持人可以先給參與者做個示范，然后再打開某個常用的App或網站引導參與者自己做一次嘗試。

（2）在設計測試大綱時，要想清楚問題的目的

有的問題是沒有答案的，或有了答案并不能做什么，這種問題就是無用的。例如：第一次測試的時候，工程師要求我在大綱中加入手機運營商的問題（移動、聯通還是電信），目的是看他們是否能收到驗證碼短信，但是否能收到短信我們通過觀察就可以看到，而不必要細分到是什么運營商，即使知道了結果也不能用于改進，這個問題就是無用的問題。

（3）任務劃分要合適

對于測試環節中參與者要完成的任務，既不可太復雜，也不可太輕松。如果太復雜，參與者可能中途忘記自己要干嘛，如果太簡單，結果可能是參與者直接跟著指令來操作。

因此，任務劃分是一門藝術，對后面結果的分析非常重要。另外，若測試過程中有多個任務，那么各個任務的scope要接近，如果相差過大，比如有的任務10秒能完成，而有的任務要3分鐘，很有可能造成每個任務分值懸殊的結果。

（4）明確是可用性測試還是市場測試

這個問題歸根到底還是測試的目的。在測試之前，一定要了解清楚老板想要的是什么數據，是技術可靠性、是市場接受度、還是app的可用性？

不一樣的目的需要的方法是完全不一樣的，得到的結果也是完全不一樣的。若幾個數據老板都想要，那么就要分清楚哪個是主要數據，那么大綱就要圍繞主要數據展開，穿插一些其他數據。

（5）事先要進行預演

在大綱完成后，一定一定要找不了解項目的人做真實的預演。

預演有幾個目的：

1. 校正大綱中預定的不合適的時間，起到時間控制的目的；
2. 若在app使用過程中有使用場景/場地的變換，需要在大綱中做出明確標識，預演可以發現不到位的地方；
3. 大綱在準備的過程中使用的是書面語言，而訪談使用的往往是口語，經過預演后，能夠發現大綱在語言上可以修改潤色的地方。

（6）采用更合適的問法

在設計大綱時，語言的表述是非常重要的，同一個問題采用不同的表述方式，得到的答案可能大相徑庭。

舉個例子：

“您平時的主要工作是什么？”

“就是普通的文職啊”

換個問法后：

“您的日常工作主要會涉及到哪些？”

“管理門禁系統、巡視啊等等”

所以不同的問題可能會得到完全不同的答案。在設計問題時，可以自己先預想一下會得到什么樣的答案，對問題的設定是有幫助的。

（7）酌情增加啟發性問題

啟發性問題可以幫助我們發現真實用戶的潛在需求，進一步提升產品。比如：“您是否可以描述一下您的一個普通的工作日？您在一天的工作中會做什么？”，發現了一些洞察點之后可以繼續深挖。

再比如：“平時是否會用到某軟件？是否可以實際操作演示一下？”這個問題可以幫助我們了解類似產品的使用情況，進而借鑒優秀的地方，規避有問題的地方。

三、測試現場

如果在前期經過了充分的準備，那么在測試現場不會發生大的問題，但這并不意味著萬事大吉了，還有很多需要注意的地方呢。

（1）心中有大綱，現場就不慌

在真實測試之前，一定要做到對測試大綱很熟悉。大家都知道，在測試的時候需要主持人具有很強的洞察力，發現參與者不尋常的行為、語言并深入探究原因。如果主持人對測試大綱不熟悉，他就會拿出相當一部分精力，思考或尋找下一個問題是什么，這樣可能會影響關鍵洞察的發現。

另外一方面，如果主持人頻繁查看訪談大綱，也會給參與者留下不專業的印象，同時會使自己緊張，影響測試現場的發揮。對大綱越熟悉，就越胸有成竹，越有足夠的精力發現關鍵洞察。

（2）認真體會參與者的心理，及時調整問題

在第三次測試時，針對的是B端網站的測試，有一個參與者是一個20多歲的年輕小姑娘，在物業做文職工作。在訪談她時，有一個問題是請她描述一個普通工作日會做哪些工作。

參與者起初說“就是普通的文職”，后來表現出了不愿意講的情緒“不知道怎么講”，最后直接說“過吧”。測試后整理時，我發現是我在現場沒有及時發現參與者的情緒，反思后，猜測可能是她自身不滿意年輕卻安逸的工作現狀，所以不愿意說出自己寥寥無幾的工作內容。如果能及時體會到參與者的心理并調整問題，就會化解參與者的尷尬，調整氛圍。

（3）維持好現場秩序

如果測試是在會議室等地進行，現場不需要太多的維持秩序工作。由于我們產品的特殊性，測試只能在小區進行，因此在測試時會有很多好奇的人前來詢問和觀察，這會大大影響參與者的發揮。因此，現場的秩序維持工作是非常重要的。

（4）提前和參與者double-check以防出現意外

請務必提前多次和參與者確認他是否能準時參加，如果不行，及時增加替補。

（5）保留多個錄音備份

這個點很重要了，第一次測試時我們的錄音筆發生了故障，導致丟失了多個錄音文件，只好根據大綱筆錄回憶用戶說了什么。

四、測試結果整理

測試完成之后還有一個重要的部分，就是測試結果的整理。

（1）提前設計數據整理表格

這三次可用性測試之后，體會很深的一點是：不同的人需要的是不同的數據。例如：對于我們用戶體驗設計師來說，希望得到的是可用性數據；對于技術人員來說，希望得到的是技術可行性數據；對于市場人員來說，希望得到的是市場數據……

測試可以采集到的各種數據可以說非常的多，而我們要做到抓取不同的數據給不同的人。因此，提前設計數據整理表格非常的重要且必要，它可以幫助我們理清思維，明確測試要的是什么，也可以反過來完善大綱內容，避免遺漏必要的問題。此處的表格應盡量詳細，做完后提前和相關人士進行溝通是否全面。

（2）做好表格中的分類項

統計數據時，我們使用的是excel，在excel的表格中做好分類項對我們非常的有用。例如：對于每一個用戶體驗相關的問題，可以把它分類到某個任務或產品模塊，對于出現的bug，可以把它的操作系統是iOS或是安卓進行分類，這樣分類后，可以在后期輕松的從更高的角度看到每個模塊（操作系統）出現問題的多少，進而明確后期優化的重點。

（3）原始數據原樣記錄

在進行數據整理之前，我的習慣是先把原始數據完整記錄下來，比如：半個小時的錄音，就把主持人和參與者說了什么完整的寫下來。這個過程切記不要翻譯，原話是什么就寫什么。雖然這個工作繁瑣且沒有什么技術含量，但可以大大提高后面數據整理時的工作效率，忘記時也可以回過頭來查看。

以上就是我在三次可用性測試中得到的一些體會，大部分是比較零碎細小的點，歡迎大家補充。但我的收獲絕不僅僅是學會了如何做可用性測試，而是掌握了用可用性測試的思維來反思自己設計的方法，能夠站在一個新手的角度考慮設計，例如在我準備測試大綱的過程中，就提前發現了app在新手引導部分的不足。

最后，多實踐才能做好可用性測試和訪談，也希望大家在設計時，能夠腦補下可用性測試的過程，來發現自己設計中的改進點。

作者：Vicky Yang，知乎：Vicky Yang。

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

題圖來自Unsplash，基于CC0協議