編輯導語：可用性測試，能夠讓產品經理借助用戶，更加客觀理性地理解產品功能以及交互，并結合測試結果予以改進。每個產品的迭代都需要進行可用性測試，可以說“可用性測試”是交互設計中進行驗證必不可少的環節。本篇文章分享了一些不一樣的“可用性測試”技巧，希望對你有所幫助。

之前群里的設計師提起了可用性測試，說面試的過程中被問到了，其實它的流程跟***并不難，網上的教程資源也不少，很多參與過或了解過的人即使沒有主導過卻也能說個一二。

哪這門蘊含科學的測試研究***真就這么簡單?借著這個機會結合個人的一點小心得，來聊一點不一樣的“可用性測試”技巧。

一、可用性測試的應用場景與作用

可用性測試(UsabilityTest)的應用場景是沒有行業的明確界定的，它一般發生在產品研發上線的前中期，在功能或交互流程有待商榷之時，通過可用性測試可以獲得更加真實的反饋來幫助決策或改進。

當然已上線的產品，同樣可以使用可用性測試為下個版本優化迭代做投資。

其中探索式跟驗證式是常見的兩個可用性測試類型，探索式適合企業對產品進行創新設計以迎合新時代發展的步伐與商業競爭力，驗證式適合企業追求精益運營或增長設計。

對于可用性測試的概念，這里我用一段類比的情景來揭示出其中奧妙。

做好一個飯館，而菜品必定是館子的核心競爭力之一，菜不好吃，那就很難形成競爭力或留住客人，所以開發新的菜品或改進就很重要。

當廚師開發了新的菜品后，首先肯定是廚師們互相品嘗，并不會直接上菜譜開售，這就像是內測過程，當廚師們覺得還可以時，就會找食客們進行免費試吃，通常這個時候廚師們需要食客們給出反饋或一定意見，如果食客們大多表示這個菜不錯，下次還愿意吃，那么就是表示這個新菜品的可行性很高，用戶滿意度不錯，就可以考慮對菜品優化上菜譜了。

而這個過程就像可用性測試一樣，它為新菜品上菜譜降低了風險，為菜品對菜館整體體驗提升了保障，其中“菜館的食客”就像是測試的目標用戶，請求他們嘗試新的菜品并給出意見，這便是招募用戶和測試階段，詢問食客是否還會再點這個菜品，覺得這個菜品在什么價位區間，就算是對用戶滿意度或可行性衡量了。

相比***可用性測試，只是少了更多的測試流程、測試技巧與科學嚴謹的分析匯報，但是基本概念是一致的。

但值得注意的是針對單個菜品的研究并不是面向整個菜館的，可用性測試很少用于研究用戶對產品或服務的整體體驗。

所以可用性測試的本質就很好理解了，以互聯網產品為例，其實就是服務數字化后的功能與流程含有不確定性，而決定找到目標用戶還原使用場景進行測試驗證，以評測設計是否行得通、哪里需要改進，為功能上線減少風險加強容錯，減少試錯的成本。

二、高保真原型與測試場景還原

要測試就得有測試內容，所以測試對象是必不可少的內容，這個過程是我們還原真實用戶在特定場景下進行產品體驗的一系列問題反饋，那么為了盡可能的還原“真實”，肯定不能只是在用戶的真實性上下功夫，接近真實的高保真原型就顯得尤為重要。

以互聯網產品來講，還原一個可交互的高保真原型并不難，成本也不會很高，可能就是信息內容設計與素材準備會相對麻煩點，對于交互動效，基本可用就行，不必過分追求。

并且實現的工具也很豐富，對于大型框架原型可以使用“墨刀、MasterGo、AxureRP”等***，小型精致的原型可以使用“Principle、Hype3、Flinto、Sketch、Keynote”等***。

反而是工業產品設計的原型會比較麻煩，有的可能要出3D打印甚至開發測試樣品，盡管這些工作會花費一定的時間與成本，但是從產品穩健發展的戰略來看，這些投資是值得的，也是老板們可以接受的。

在大多數的可用性測試文章或教程中，用戶都是在一個相對降噪的會議室或實驗室進行的，其目的是為了更好的布置設備用于過程的觀察與記錄，同時為用戶測試減少干擾與評估難度（其實也省錢），但事實上還原產品服務的真實場景是很有必要的，并且一些產品服務自身就會含有一定的場景屬性，所以你的測試環境就應該考慮接近真實場景的布置，甚至考慮跳出會議室、實驗室。

這樣的目的也是為了更加真實的還原使用場景，以取得更嚴謹科學的有效信息來賦能設計，這也是為什么大多數產品需要上前線測試的原因，就像藥品誕生于實驗室，上架于臨床一樣，例如出行、運動相關產品，如果依舊停留在寫字樓里測試實驗，那就是閉門造車。

三、任務與指標定制化設計

產品的本質是為用戶提供服務，用戶會為了達成自己的某個目標或需求而花費時間使用產品，而我們需要用戶測試一系列功能來評測是否能夠協助完成目標任務。

所以我們在設定不同任務的時候應該以某個用戶需求或目標為導向來驅動用戶使用產品功能，而不是系統的指出完成那些操作任務，那樣沒辦法深入挖掘真實有效的信息。

所以在向用戶頒布測試任務的時候，我們應該為用戶建立一些任務背景，并且盡可能看起來真實可靠，容易接受和共情，甚至你可以在測試前的暖場環節，根據此次的功能作用推導一些使用場景和需求，并與用戶進行簡單交涉，看看那些需求很有可能發生在用戶身上，并以此需求目標來調整任務的話術來驅動用戶完成測試。

值得注意的是如果測試的部分比較明確，那么你的任務目標也應該盡可能的聚焦或明確下來。

好了，為了方便理解我要說人話了。

（1）重點補充

因為在整個測試的過程中，參與測試的用戶不止一個，所以在了解用戶情況后，可以綜合一下共同的特征再去提煉優化任務目標，以保證在多個參與者中維持評估的一致性。

并且任務目標應該盡可能的準確有效，我們是要測試新的拍攝識別功能，那我們就應該要求出來，而不是說看完書后使用APP的筆記并嘗試各種功能支持，產品或功能所沒有的就不要提。不保證有效性，最后也只能讓用戶感到困惑而已。

通常完成測試任務的過程中，會涉及到多個功能之間的交互，所以任務目標涉及的多個階段應該貼合實際的操作順序或流程規范，另外盡可能的避免***術語的出現，務必考慮“適老化”一下。

（2）關于指標定制化

通常在可用性測試中，是否可用的指標被劃分成了三大面：有效性、任務效率、滿意度，對于這三方面我們可以繼續細化成若干個二級指標用于界定產品可用性。

至于你家的產品是什么行業、什么階段、什么用途、有何特性，應該滿足哪些指標為可用，我就不深入了，相信大家心里都有數。

簡言之核心就是考慮產品的特性與階段，靈活的配置可用性的指標，這里整理了些常見的指標與說明用于參考。

四、用戶測試中常見的問題

盡管我們有測試腳本甚至測試排練，已經盡可能的保障了可用性測試的穩定可靠，但實際上在用戶測試的階段還是會出現各種問題，用戶像一個熟睡的嬰兒，何時醒來何時哭泣不可預見，所以這就要求測試的主持人能夠靈活變通，同時在技巧上符合可用性測試的科學嚴謹。

可用性測試過程中的科學嚴謹一方面體現在方案的合理性、測試主持的技巧上、及評估分析量化的***上，這些大多可用性測試的文章或教程中都會提到，這里就不展開啰嗦了。

常見問題舉例：

1.他似乎在想些什么但是沒有說出來？

你在想什么可以分享一下嗎？

2.用戶好像卡住了或遇到bug了。

這沒事兒，是我們產品設計的問題，你可以考慮跳過這一步好了。

3.就是這個，它怎么就那啥了？表述不清。

你剛剛打算做些什么，如果是你，你準備怎么去設計？有沒有一些參考。

4.然后我要怎么做呢？

對于用戶提問說明遇到了障礙，嘗試反問你平時會怎么做？

5.用戶反饋了一些趨勢或點子，看起來很有價值。

嘗試深挖，順著點子或趨勢向用戶多問一點，但是不要直接問“為什么”，可以嘗試問好在哪里或者哪里不好，讓問題更有頭緒一點。

以上不難看出，即使有了腳本，但是用戶依舊是一個變量因素，所以腳本依舊需要不斷調整，也只有去調整才能更好的保障測試結果的有效性，同時主持者也需要隨時準備靈活的應對各種幺蛾子。

五、創新與顛覆性設計如何測試

可用性測試被很多人視為評估體驗的制勝法寶，但實際上很多產品在行業中已經逐步成熟，并有大企業花費大量資源進行研究摸索，讓生態系統更進一步，所以說要是你的產品沒有特殊的創新或瓶頸，而是傳統的功能研發，其實并不一定要花費成本去做可用性測試，直接按照行業標桿也是沒問題的。

那么你的產品就是有創新或顛覆性設計怎么辦？

通常這個時候就會面臨一個問題，打破傳統或者顛覆用戶的常識。類似這種顛覆式或創新技術其實非常多，例如按鍵手機一下到了觸屏時代、智能駕駛、語言助手的誕生、刷臉支付等，這對企業是機會也是風險，所以在進行可用性測試的時候也會有些不大一樣的地方。

我們悉知在可用性測試的三大指標中就有一項是“效率”，對此也會有一些完成任務的時間作為指標，這些指標通常是根據內部人士或專家完成任務的時間乘上2倍或者更多倍做為一個評測指標。

但是對于顛覆性的變化，我們需要給用戶首次測試留出更多的時間去學習去適應，在此之后，可以讓用戶再進行1～2次的測試，并且比較多次任務完成的時間變化，如果時間能夠大幅度縮減且完成任務，那就表示可用，而這樣做也是為了保障測試的科學嚴謹性，以避免學習門檻對創新性的評測影響。

六、多版本Battle你需要小型可用性測試

可用性測試需要招募用戶進行測試，預算時間精力可謂一項都不能少，但是大多公司的窘境卻是公司小資源又有限，又不給預算招募，可用性測試做不起來？內部產出版本過多，不知何去何從？別擔心，小型可用性測試了解一下！

1.什么是小型可用性測試(SmallUsabilityTest)？

小型可用性測試就是在標準的可用性測試的基礎上減少了一些流程與要求，這就像是大公司與小公司之間會有各自的研發流程一樣，兩者各有千秋，對應公司規模與背景對癥下藥。

在小型可用性測試中，也有腳本、簡易的暖場、用戶定義、測試目標、測試任務、測試原型、測試參與者、測試觀察、思考總結，更多的也是發生在功能上線之前的推敲階段，它比較適合設計師在自測階段后的驗證以及多版本Battle，幫助你Pick一套更加合適的方案。

但是整個過程相對正式可用性測試會更加簡單易行，其中價值觀念與目的都是一致的，都是以用戶價值與用戶目標來驅動（使用動機）使用產品，并且觀察用戶的使用過程以獲取有效的反饋來改進或決策。

不過呢，腳本會更加簡易一些，原型材料也不用那樣精細，主要能表達功能作用與信息流程為主，其中測試者更多的是尋求那些關心我們產品或有需求的用戶，另外也不會準備那些知情書、協議、錄制設備、測試指標啥的，更多的是尋求熟人或哪些有意向的用戶快速進行測試并觀察，這樣不僅時間成本都節省了，難度降低了，也能拿到一定的有效測評結果。

基本上主要的實踐步驟就這五點，還有一些布置會穿插在其中，后面代入案例講解一下。

2.案例代入講解

便于直觀的了解和感受小型可用性測試，這里代入一個老案例講解一下，關于案例背景這里簡單交代一下。

（1）背景

平臺服務于游戲相關的訂單交易、互動娛樂，本次測試的內容是新的游戲訂單定制服務，通過推出一批專供用戶定制游戲服務的客服來完成溝通與定制下單，其價值在于幫助用戶快速了解平臺游戲服務以及快速定制服務并完成下單轉化，以溝通的方式減少用戶下單的操作流程與門檻。

（2）任務流程

設計服務入口與流量分發->用戶選擇心儀的小魚（專供客服的代稱）->進入小魚的會話界面->溝通需求目標->小魚制定用戶專屬服務訂單->用戶支付確認->轉到訂單流程

為了加快講解和體現測試的價值與***，這里就不跑全套流程了，就以小魚入口的設計與流量分發來代入講解，測試前提是聊天會話界面中已經集成了“小魚”所受理的主要游戲業務介紹，以及快速下單的入口。

當然一般都是在用戶向“小魚”傾述目標需求后，由“小魚”進行服務定制，并向用戶發起訂單等待用戶確認支付，之后便是等待訂單完成到驗收評價，平臺轉交傭金。

（3）首先定義用戶與目標

在這個測試任務開展前一定要知道開展目的是什么，然后就是這個過程中你的功能或產品是為什么樣的人服務，能為他們帶來什么樣的價值，也就是前面一直提到的價值與目標驅動用戶的概念。

為此你可以建立一個簡易的用戶原型來定義用戶的特征屬性，使得目標群體再具體一些。

然后將小魚的服務價值寫出來，讓參與者能夠快速知道小魚功能有什么用：

（4）創建適用于目標的測試任務

對于測試任務的創建，應該是圍繞目標的。

根據流程的多少或復雜程度，可以劃分為多個階段，這樣具有階段性會更好控制測試節奏或分段進行，然后就是將多個任務按照流程順序或是操作難度排序，目的是使得任務流程正確或是用戶接受起來更容易。

當你把任務清單羅列出來后還不算完，這套清單你可以放在腳本里，但是當你描述給用戶時，你應該代入對方視角去描述并且帶有目標性，所以還需要進行一次調整后應用：

（5）找到合適的測試參與者

關于參與者我們會參考第一步中所設定的用戶原型，不需要全部中標，但至少這些人要看起來會用得上你的產品才行，通常這些人建議通過熟人關系去尋找，甚至可以是你的同事，只要他們對產品沒有額外的偏見，且不是相關設計者、營銷運營者或技術研發人員，因為這些人對該領域的知識掌握甚多，有失真實性。

當你找到這五六個接近真實用戶的參與者后，你只需要將起初寫下的“功能價值闡述”告訴他們，讓他們知道要做一個怎樣的服務測試，然后預約他們在不同的時間節點上花費半個小時來做一個簡單的功能測試即可。

（6）觀察參與者如何執行任務

在這個階段，你需要保證已經準備好了測試原型，以及一份腳本，腳本中會規范以上的功能價值、測試任務、一些簡易的指標、關注要點、暖場介紹、流程順序等。

然后你要找一個相對安靜低調的測試場地，不一定是會議室，不用很大空間，一個桌子兩個椅子和一些必備的材料即可，但不要有一些產品相關或商業的痕跡，會形成干擾。

在測試開始前你需要將測試原型初始化，以確保每個參與者測試的一致性。

在暖場和任務布置完成后，就是測試者的ShowTime了，主持者可以拿好自己的小本本或者錄音筆，認真的觀察測試者的操作或口述反饋，當測試者遇到一些問題不知所措時，也不用著急指導，告訴測試者先按照自己的認知或想法去做就好。

如果測試者在一個地方卡了好幾分鐘，沒有一點頭緒甚至感到受挫那就讓測試者先跳過障礙，避免整個測試節奏失控。另外記得提醒測試者口述反饋，這很重要。

當在計劃的時間段完成測試后，就為測試者送上準備的獎品，寒暄幾句后送測試者去休息或離開，然后對材料或記錄進行簡單整理后，準備下一場測試。

（7）思考與總結

在完成一輪簡單的小型可用性測試后，通常一定會拿到一些有用的反饋，可能有些零散還需要進一步的整理，但這不影響最后的分析結果，為了方便驗證和整理，我們會提前把一些重要的問題點羅列出來，然后根據測試者的反饋進行記錄歸檔。

最終當你完成了這些測試及反饋信息收集以后，產品方案中究竟哪里出了問題應該就了解的差不多了，一些比較明顯的問題甚至會被測試者多次提及，或許是頁面信息不被理解、交互難懂、提供的內容不受測試者喜愛，亦或是測試者都認可、設計亮點被用戶親睞。

盡管會發現一些跟我們預期不大一樣的結果，但都是正常的，值得注意的是，我們應該結合這些數據進一步的反思，究竟這些反饋有何含義有何價值，哪里還能優化，基于不用的產品服務或受眾，反思點可能會有些不同，這里我泛舉一些；

最終呢，我們也是通過測試取得一些有效的反饋，并根據反饋深思了更好的設計方案，我們對小魚卡片的信息進行了豐富以保證可比較性，將每批三個小魚卡片擴展到了8個，用戶可以通過橫向滑動查看更多，同時為了方便用戶更好的換到下一批，在最末尾給予了滑動換批次的交互，使得用戶可以一指滑動到底完成查看與換批次的交互銜接，在之后的驗證測試中也是獲得了測試者的認可與看好。

相信說到這里，怎么做好一輪小型可用性測試已經了解了，當你完成了這些測試任務，一定記得不要忘了后續的反思與優化迭代，甚至制定后續的研究計劃。

七、多版本方案如何可用性測試

有時候設計產生多個版本也是在所難免的，那么對于多方案是應該將內部推薦的拿出來測試，還是應該直接兩個版本一起拿出來，兩個一起會不會因為采集量過少不準確呢？

這里我們再說說有多個版本怎么做好測試計劃與分配，當有多個版本準備可用性測試時，如何制定測試計劃還要看版本數量、版本差異化這兩大維度，力爭做好有效且不費力。

如果說在設計過程中產生的多個版本差異不大，那么都進行測試的必要性我認為不大，通過在商業價值與用戶體驗間做衡量，選擇一個更加符合產品階段的方案進行可用性測試即可。

但是如果多個版本差異較大，難以決策且不確定性較大，那么第一件事就是經過一輪決策將版本減少到兩個左右，然后再進行可用性測試，對于此類情況基本上有兩種***進行分配測試；

1.將版本分為兩組進行測試

如果說直接分成兩組進行可用性測試，那么需要數據樣本會更大，數據采集量過少確實會有不準確的可能，因此直接分成倆組進行測試的話，會需要招募更多測試者和測試準備，但同時可能會有意外的驚喜。

往往我們以為的，可能會在測試者那里收獲意料之外的反饋，這將允許我們以真實用戶的視角去挖掘價值或決策，避免內部短視而埋沒了好的設計。

2.一組人員測試兩個版本

相比分多組測試，一組人員測試兩個版本在成本上會更有優勢，但同時會面臨兩個版本測試的前后順序影響，要知道第一個版本會對用戶形成更多印象，甚至產生一些偏好，所以為減小測試結果的偏差，我們會將測試者分為數量相同的兩組，并安排兩組不同的先后順序進行測試來打破僵局。

八、測試結果的量化或匯報技巧

測試結果量化的目的在于更好的衡量可用性在怎樣的一個水準線上，同時便于整理復盤整個測試過程，并將結果更加直觀的展現出來，便于同事們了解。對于測試結果量化有兩個方面；

一方面是將整個測試過程中收集到的各種問題反饋進行分類整理，并用數據圖表現出來，這樣能夠很直觀的展現問題缺陷與突破口，同時能夠快速體現測試價值，或者說你進行可用性測試為業務帶來的價值。

另一方面則是通過面向用戶的問卷調查獲取可用性測試量表，最常見的標配問卷即ASQ(任務后評估問卷)與SUS(系統可用性問卷)。

除此之外還有專門面向網站產品的WAMMI(網站分析和測量表)、SUPR-Q(標準通用的百分等級量表，但是獲取有效的百分比數據需要購買服務，所以不額外介紹了，有興趣的自己百度下)，以及面向APP使用體驗的SUPR-Qm(APP用戶體驗量表)，在說明這些量化表怎么使用和定義前，我需要額外說明一些量化表的概念，這很重要！

1.可用性測試量表標準

作為一個合格的標準化量表至少需要保障以下幾點：

（1）可信度

對同一對象測量得到的結果是否一致，這將直接決定問卷獲取的結果是否能可靠，可以通過重復測量信度和分半信度測量，測量出的信度會在0～1之間，越是接近1的可信度越高，因為量化結果會被直接引用，所以信度至少高于0.7才比較有意義，不然一個半信半疑的結果真的充滿風險。

同時以上我提到ASQ、SUS、WAMMI、SUPR-Qm這四個量化問卷也都是經過業內長期試驗與驗證后信度較高的靠譜問卷模式。

（2）有效度

主要理念在于是否密切關注到了你所在意的問題點，以及問卷問題是否與驗證系統有關聯性，對于效度也有效標效度（皮爾遜相關系數）和內容效度（因子分析）兩種評估***，不過并不一定要有很高的系數來證明很有效。

（3）靈敏度

指達到統計顯著性所需的最小樣本量，例如一個水果偏好二選一問卷，你問兩個人可能是答案A，但是你問完10個人后卻是B，當采量過小沒能達到統計顯著性所需最小樣本量時，可能會獲得不夠準確的答案。

（4）客觀性

一份問卷應該保持客觀性，不能攜帶編輯者的個人偏好或主觀意愿影響，這會讓問卷有失統一性。

（5）重復性

盡可能的使問卷框架結構能夠復用，一方面便于更多人可以研究驗證，另一方面可以使得問卷本身價值最大化。

（6）可量化

對于問題的答復最好進行量化處理，而不是單純的是或否，目的在于可使用高效的統計學***來理解結果，或進行對比，亦或是數據可視化體現更加精密的差異。

所以說開發或調整一套標準可用的度量問卷也是一門富有學問的技術活，并非簡單問幾個問題這么簡單。

2.任務后評估問卷(ASQ)

也叫場景后問卷，一般在可用性測試完畢后進行，它可以直觀的在任務難度、完成效率和幫助信息上獲取到測試者的直接反饋，主要就固定三道題目，答案采用5分制或7分制，所得分除以總分即可得到一個均分，該分值至少要大于0.6才能合格，要獲得大部分人滿意或認可，則要高于0.7。

3.系統可用性問卷(SUS)

SUS總共10題，奇數項是正面描述題，偶數項是反面描述題，答題采用奇數的5分制。SUS益于它正反向問題結合，以及具有泛應用的可用性與易用性題型，在業內具有大量應用數據為基礎，不論是客觀性、靈敏度、可量化還是信度都具有較高的水準，這也是SUS能夠成為可用性測試后問卷最主流的原因。

（1）SUS量化分數計算

在SUS的相關創建者經過對大批數據的研究，其中可用性部分量表信度為0.91，易學性部分可行度為0.7，為使得整體量表得分兼容在0～100的范圍，最終需要對可用性量表總分乘以3.125，易學性量表總分乘以12.5。而經過長期的應用迭代，最終分數的計算方式進行了定格：

步驟一：所有奇數編號題目得分減一后相加；步驟二：所有偶數編號題目得分由五減去后相加；步驟三：將奇數項最終得分+偶數項最終得分后乘以2.5即最終SUS得分。

（2）分數值概念

在經過創建者的研究與沉淀，最終構成了5層不同級別的評級，A即最優評價，并且對應0～100分，有趣的是5個評級并非是將100分平分，為了解釋評級與得分的強關聯性，創建者新增了第11題進行整體而言的數據收集與分析，最終得到了以下圖中所對應的關系。

如果說結果是“Good(C)”，那么對應的平均分值則是“71.4”，如果說你的得分高于85.5分，那你的評級則處于“Excellent(B)”，這可能已經意味著你的產品優于絕大部分產品了。

4.網站分析和測量表(WAMMI)

WAMMI的建立是為了專門量化網站產品的，該問卷一共20道問題，采用5分制回答，整體信度高于0.9，但是吸引力、可控性、效率、幫助性、易學性多個因子測試信度只在0.63～0.74，因此該問卷對測試樣本要求不少于30個。

若該產品屬于學術或***性較強類型，則樣本量不少于100個，平均分值為50分，總分100分，但是也受樣本量影響，WAMMI很難在可用性測試場景后使用，不過它的問題可以在小型可用性測試中進行應用或自檢。

WAMMI官網：http://www.wammi.com/index.html

5.APP用戶體驗量表(SUPR-Qm)

作為一個APP用戶體驗量表，涵蓋了更多的體驗度量面，而不僅僅是衡量了可用性（比如SUS），并且可以在可用性測試期間或可用性測試之外進行，也可以與其他問題混合使用以便于測量某些特殊產品(如游戲)的用戶體驗，同時它的信度也高達0.94，SUPR-Qm一共16道問題，采用傳統的5分制李克特反應選項。

SUPR-Qm的16道題原本來至23個其他相關文獻中的題目和4個***性的問題，經過不斷測試驗證和減少冗余后，留下的16個具有單維的、可靠的、有效的、兼容強的問題。

SUPR-Qm原博客說明：https://uxpajournal.org/supr-qm-measure-mobile-ux/

6.關于測試結果匯報

有些同學一直不清楚可用性測試報告要寫些什么，有無固定格式，其實報告沒有什么特別的地方，簡言之就是將測試的目的、測試過程、測試結果進行整理匯報并反饋優化意見而已。

其中大部分內容沒有硬性的格式要求，看起清晰易懂是重點，你可以是文檔匯報也可以是PPT匯報，另外記得測試匯報講究真實性，可以把測試過程中的照片或截圖等放進去用于佐證。

另外就是測試結果的歸檔，我們通常會借助表格的形式來呈現，這樣能夠更好的將信息整合。

但是考慮報告輸出，不是一味的反饋負面問題或解決方案，同樣也可以反饋被用戶認可的設計，這也是測試的一種價值作用，能夠為后續的優化設計提供一定的方向指引與團隊信心，所以我們將常見的測試結論歸檔表進行了一些輕微的調整，補充了反饋的正負趨向，最終呈現如下：

九、關于用戶反饋的思考

用戶反饋本身就是用戶在使用產品的過程中遇到了問題，然后通過找客服或反饋入口所給予的反饋。

如果一個應用的用戶忠誠度不高，即使你在應用內發布問卷收集反饋，用戶的參與也會很有限，反而是因為一些問題讓用戶受阻了才會產生一些寶貴的反饋，而讓用戶準備和提交截圖憑證更是困難。

所以這個時候讓用戶反饋的入口更好找，對問題類型提供細分選項，甚至對截圖等動作做出一些預判都是不錯的選擇。

以支付寶的使用場景為例，我們有時候截完圖是不是就馬上會收到彈窗提示是否遇到什么問題了？

這便是對用戶反饋的一種重視，如果你確實要準備進行反饋，那么你后續的操作步驟會少很多，使你更容易達成而不會因為繁瑣的步驟而產生放棄的念頭，并且截圖時詢問的窗口也是極力克制不會產生過分的干擾。

這么說來你是否對用戶反饋這個功能有了新的看法，并有了給自家產品優化一下的想法呢？

寫著寫著就又沒剎住車，又成了所謂的萬字干貨了。

不管你是從事什么職位，都希望你能夠有所收獲，即使你腦子里一靈光有了新的想法或不同意見都歡迎來找我交流。

最后也感謝那些不厭其煩與我交流的用研大佬們，下次有想法了還來煩你們哈哈。都看了這么久了，點個贊收藏一下吧～

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

題圖來自Unsplash，基于CC0協議