設計市場初期會 PS 就能夠找到工作，慢慢演變?yōu)樾枰龊每茨苷业焦ぷ鳎谥笞兂杉群每从趾糜媚苷业焦ぷ鳎敝连F(xiàn)在既要好看又要好用，還要能證明為什么好用，都不見得能找到工作。

企業(yè)越來越過分，總是既要又要還要，想去好公司就必須具備多項能力，會用研、有設計思維等成了各企業(yè)招聘得重要標準。但很多伙伴出自小廠，沒人帶、沒人教、哪里會形成完整的設計思考。最終形成了去大廠要設計思維，但是不去大廠又學不到設計思維的死循環(huán)。

今天帶領著你學會一些用研知識，打破死循環(huán)。

伙伴們可把學到的知識推演到自己項目中，包入作品時完整呈現(xiàn)在改版前發(fā)現(xiàn)問題的過程，讓改版有理有據(jù)，避免面試官看到你作品時“一眼假”。

不會用研進不去大廠 ，不僅大廠不會用研，死循環(huán)

一、用戶研究之可用性測試

設計都是偷窺狂

什么是可用性測試？

官話來講：可用性測試是通過觀察用戶使用產(chǎn)品完成典型任務，發(fā)現(xiàn)產(chǎn)品中存在的效率與滿意度相關問題的方法。說人話：別人操作，你偷偷觀察他的操作過程，并總結分析產(chǎn)品問題。

可用性測試目的是為探索設計的可能性、驗證設計的有效性、或是為了方案對比，最終可以歸結：想讓用戶爽。

為什么一眼假、不真實？就是因為我們大刀闊斧改的方案，根本沒站在用戶的角度、不考慮企業(yè)的利益，換句話說是我們在主觀的為用戶做出選擇，都是個人“意淫”，必然看起來假。

想要做好這件事，就要搞清楚設計為誰做，目的是什么。

二、為甚么要做可用性測試？

為你上盤菜，吃了你就知道了。

上盤菜

假說你從沒下過廚，但想為你非常重視的男神做道菜。你看著網(wǎng)絡教程做，做完自己也不嘗嘗直接端給男神吃？這種可能性不大吧？即使有教程，第一次下廚很大概率也會搞出黑暗料理，嚴謹一些的流程應該是什么樣的？

想為男神做飯—開始做飯—自己品嘗—邀請閨蜜品嘗—收集反饋—優(yōu)化菜品—邀請男神

抗風險

為避免翻車，自己會品嘗菜品，回歸到設計這個舉措叫什么？自測試吧？但是你認為好的就一定好嗎？不一定！此時還需第三方評價，在客觀的角度上做出認證。邀請閨蜜試吃就是為了對抗上線翻車風險。

邀請閨蜜試吃這件事就屬在進行可用性測試，類似于這樣的事大家都做過吧？

很多時候我們自認為的好設計 都是產(chǎn)品、設計、老板自己想出來的，大家總會說：我覺得、我認為…可用戶不要你覺得他們只要他覺得，你認為的不見得一定是對的，所以在產(chǎn)品每一個階段我們都可以通過測試來判斷用戶到底需要什么。

方案初期驗證方案的可用性、有效性。上線后可以通過測試來進行體驗性的驗證，同時可為后續(xù)迭代做準備，對抗未知風險。

你是故意的 ，還是不小心？

不要小看這一步驟，被稱為最強陽謀的小胖為什么會被評為淘汰（這里是一個綜藝節(jié)目，小胖用未清洗大腸做飯，讓評委吃）自己都不試吃啊，翻車實屬必然事件。

三、3+1 形式：測試前準備

老 3 樣：時間、地點、人物。+1:任務

時間 、地點、人物、任務

時間

測試的進行時間需要控制住 1-2 小時以內(nèi)，并要提前預約好別人時間。

想來你閨蜜也不會隨叫隨到吧？人家不需要陪男朋友嗎？與參與者的時間一定提前約定好。

控制測試時長，避免時間過長讓參與人員產(chǎn)生對抗情緒。

提前整理好參與測試人員名單，備注其姓名、工作、約定時間、以及該用戶特征。資料沉淀，無論是給領導匯報還是入作品集都是非常加分內(nèi)容。

時間

地點

這一點無需多說啦，咱請人吃飯總得有個地方吧，總不能蹲在大馬路邊上吃吧？是在家吃、還是在客廳吃？

測試地點自然會議室屬最優(yōu)選擇咯，相對屬于安靜的環(huán)境。PS：專業(yè)的用研公司會有專門的房間來進行測試，雙面玻璃的觀察房那種。咱小企業(yè)不需要考慮這么多了，成本過高就不必奢求。

地點

吃飯總需要餐具吧，碗啊盤子啦、筷子啦、餐巾紙之類的內(nèi)容總是要準備的吧？那可用性測試需要的‘餐具’都是什么呢？

物品準備

如圖所示，記錄本、筆、錄音筆（實在沒條件可以考慮用手機錄音）測試用的手機和電腦，還需準備一臺用于記錄信息的電腦，如果有需要可提前準備錄屏軟件，還有一個重要事情～準備好給用戶的小禮品哦。

招募人員

人物：招募用戶

時間、地點、餐具都準備好就可以有請你的好閨蜜們閃亮登場啦。

你對于選閨蜜，選男友有要求，我們對于招募用戶也是有要求的，招募的用戶可從用戶畫像中尋找相關特征，比如說你用戶分層有老年人、青少年、兒童，那你則需要把著三類用戶都招過來才好。每組 4-5 人即可。

小心研發(fā)為你挖坑

當然也可以粗暴的將用戶分為兩類，專家級用戶、小白用戶。

專家級用戶就像我們這種做設計師、或者研發(fā)、產(chǎn)品、具備競品經(jīng)驗用戶、用戶特征和我們的產(chǎn)品匹配的。普通用戶所指沒有相關經(jīng)驗的，了解行業(yè)較少小白用戶。有些伙伴應該發(fā)現(xiàn)了我標記的紅圈，測試時要注意不要讓同組產(chǎn)品或者研發(fā)作為被測試人員，東西都是他們研發(fā)的，你讓他們說哪里有邏輯 bug 那他能告訴你么？又當裁判又當運動員可不行。

核心目標在哪里 ？

有目標才會衍生任務

時間地點人物介紹清楚了，就要說一下我們測試目任務是什么，畢竟有目標才會有前進的方向。

例：你想成為設計高手所以來閱讀文章

例：做了兩個設計版本，想確定哪一個版本更好，所以測試

例：不確定當前方案是否滿足用戶訴求，所以進行測試

例：功能已經(jīng)上線，想觀察用使用狀態(tài)，進一步總結為迭代做準備。

不可能今天咱腦門兒一熱，突發(fā)奇想來做個測試吧？

我們要做的事情 ，搞清價值、理清任務、設計量表

任務 1：明確功能本身價值，此能幫助用戶解決什么問題？（一句話說清楚此功能的作用，換句話說就是這個功能最起碼有用）。

任務 2：確定好功能后圍繞此功能 展開其用戶操作流程。

例：我想在購物軟件上買一架直升機，流程大概是：打開 APP—搜索并挑選—加入購物車—下單并支付，將此流程記錄形成任務（流程）大綱。

大綱特征也可幫助指導我們篩選招募人員，例上述流程可判斷出招募人員的特征最起碼要帥氣！多金、有購物（網(wǎng)購）習慣的用戶。

價值與任務

輸出這樣一份表格，將目標、任務細化。

還需要準備幾份量表，ASQ 量表、SUS 量表等。不要被名字嚇到，其實使用起來非常簡單！！！這兩份量表內(nèi)容都是固定的，咱拿去套用就行。

ASQ 量表：用戶執(zhí)行任務后對有效性、滿意度做出評價。畢竟測試做的是否成功，任務設計的是否復雜需要一個標準來衡量，我們測試做的是是否成功？是不是需要和領導做匯報？拿什么去匯報？這個表不就解決問題了。

SUS 量表：用來判斷咱們產(chǎn)品的可用性和易用性。

雖說題目是固定的，但大家要對其中內(nèi)容有所了解，例 SUS 量表中第 6 條：我發(fā)現(xiàn)產(chǎn)品中很多不一致的地方，用戶可能會疑惑，這是啥意思？需向他進行解釋，比如說顏色使用不一致，字體大小不一樣，設計風格不一致，操作上、流程上和用戶的使用習慣不一致等等。

這兩種量表都是 5 分制，分別是從非常不滿意—非常滿意，拿到用戶評分后進行平均值計算就好啦。

ASQ 、SUS

說一下 SUS 量表的計算規(guī)則，敲黑板啦！！很簡單一聽就會。

這 10 道題里

將奇數(shù)題：用戶評分-1（如用戶第 1 題評 4 分，那該道題的得分則是 4-1=3）

偶數(shù)題：5-用戶評分（如用戶第 2 題評 4 分，那該道題的得分則是 5-4=1）

然后將 10 道題的分數(shù)相加在乘 2.5，就等于總分啦。

如果平均分超過了 70，使用體驗已經(jīng)甩出其他產(chǎn)品幾條街了，如果低于 58 分，那這項功能需要慎重考慮一下了哦。

除此之外還需準備記錄表、日程表、用戶知情同意書、保密協(xié)議等等（不過類似于這種玩意公司內(nèi)部測試很少用，除非保密項目或一些 B 端項目，嚴謹就準備一下，單純分析調(diào)研倒不用那麻煩，依自己公司情況來定就好啦）。

串聯(lián)一下

四、測試前的準備

總體串聯(lián)一下：

咱想請男神吃飯這，先邀請閨蜜來家里試吃。

測試目標：測試飯菜做的好不好，是不是達到上線標準（測試價值/目標）

測試時間/地點：下午 2:00 在家里（預約受訪者）

準備物品：餐盤、餐巾紙、刀叉等等（設備準備、各類表準備）

參與人員：生活精致、愛美食、女性巴拉巴拉（根據(jù)特征進行用戶篩選、招募測試人員）

測試任務：先吃沙拉后吃醬、先吃甜點后吃飯（任務大綱梳理）

五、執(zhí)行可用性測試

準備工作已就緒，是騾子是馬走上一圈～

團伙作案

團伙作案

團伙先占領會議室：團伙配置要求需 2-3 人，不易過多，你想想如果你在吃飯時一群人圍著你，能自在嗎？如果人員不夠，則最大標配主持人、觀察員。

主持人：最好是行業(yè)相關的人，親人、不要總板著臉，總不好請一個光頭、膀大腰圓的花臂大哥吧？會嚇到客人（反正我害怕）。

觀察員：需降低自身存在感默默在一旁觀察、記錄他的罪證。

座位要求：客人要坐在主要位置，其他人可選擇坐在斜對角、側面、避免給客人帶來心理壓力。

注意：測試過程中不要隨意的去打斷客人操作！咱要講禮貌不是～

暖場子

暖場子

人都來了總要吱個聲打招呼吧！先把場子暖起來！！嗨起來！！

參與測試者和我們大概率不熟，需寒暄一下、進行段自我介紹，記得隨行伙伴也要介紹，畢竟你不是來說單口相聲。

告知測試目的、注意事項告知，畢竟可能會錄屏、錄音、攝像等等，需讓參與者知情，告知錄像錄音之類的只用來做分析，不會泄漏出去。告知操作不分對錯，測試者可按自己習慣操作，如遇困難盡量努力解決，我們不會提供過多幫助巴拉巴拉...這種話術就自己編輯一下就好啦～

切記做介紹時不要照著稿子念，毫無感情色彩會讓人感受上非常不適，我們只是嘮家常而已，像朋友一樣聊聊天，可以圍繞著想要測試的功能進行詢問。

舉個栗子

例：怎么樣，最近忙不忙？平時還有機會和伙伴出去聚餐吃飯什么的？你和朋友出去通常都吃些什么？你們是提前預定還是直接去餐廳吃呀？你是如何通過軟件預定呢（進入主題）

也可以做測試前的訪談，了解一下用戶的年齡啦、崗位啦、習慣特性之類的（不過我更傾向用戶特征內(nèi)容可在招募用戶時的問卷中收集）

通過聊天形式了解用戶，拉近距離，同時引導他們進入操作場景

如測試的場景出現(xiàn)概率比較低，可通過講故事、提假設、引導用戶操作，總而言之，言而總之要給用戶一個執(zhí)行任務的理由。

提出任務

為用戶設計的任務要聚焦在核心流程上，不要搞那種找到某個功能按鈕，可以把這些個小問題融合在大流程內(nèi)一起測試，正所謂好鋼用在刀刃上。

要是招募人過來就是為了找不同，實在是對不起這份折騰。

明確任務的起始點在哪，用戶會在哪里開始，哪里結束，這也是對于任務設計是否合理判定標準之一，關于起始點和任務流程前面說過 這就不再贅述了。

明確起始點

提個注意事項，布置給測試者的任務不要顆粒度過高，要符合用戶的操作邏輯。

吃飯就好好吃飯，不要要求人家吃幾粒米、菜要嚼多少口，限制過度、任務顆粒度過高會導致用戶無法按照個人操作習慣進行執(zhí)行，測試也就失去了意義。

符合邏輯，大家都知道甜點應該飯后吃，你上來就讓人家炫甜點明顯不符合大家正常邏輯，不符合邏輯的操作，用戶只會覺得莫名其妙罷了，不會帶來實際價值。

任務大綱只需給個大概，讓其自由操作就好，如測試結果于我們計劃的相差甚遠，需反思一下是不是話術引導出了問題，或者功能本身出了問題，又或是我們未給出任務框定條件，例：想讓用戶操作產(chǎn)品中的地圖導航，布置任務時告訴用戶要從地點 A 到達地點 B，參與者直接掏出百度地圖！這明顯脫離測試范圍，需要及時干預、補全任務條件：僅使用某某 APP 完成此任務。

總結：創(chuàng)建任務注意事項

任務聚焦：聚焦核心流程、能為用戶來帶價值意義的功能上，任務安排不易過簡單。

場景化：布置任務前先為用戶塑造場景，為用戶執(zhí)行任務創(chuàng)造理由。

常規(guī)化：任務操作邏輯合理，步驟安排顆粒度不易過高。

起始點明確：判斷用戶是否完成的主要依據(jù)。

聽她說 、看他做

開始「偷窺」

此過程中主要是聽她說、看他做。

聽她說：可讓用戶在每步操作時說出來他要做什么（這也稱之為：發(fā)聲法），或談自己的想法，我們跟著用戶思路就好，如用戶操作過程中忘記說出自己的操作，或在某一頁面長時間停留，可適度提醒：此時你在想什么，可以分享一下嗎？或者問您在看什么？您在操作什么？

如用戶操作過程中出現(xiàn)困惑，向我們求助，我們要嘗試進行反問：您覺得接下來怎么操作比較合適？您平時是怎樣進行操作的呢？引導鼓勵用戶進行思考。

全程我們應保持中立，不要誘導用戶做出操作，如確實遇到了 BUG 無法避免未知錯誤時可先引導跳過此步驟。

看他做：多觀察用戶的操作、肢體、表情等。例如他在操作某步驟時皺眉、忽然淺笑、撫摸下巴、 摸耳朵等等，任務結束后需及時提問讓其為你解答（看您在操作某某步驟時淺笑了一下，可以和我分享一下原因嘛？看到你操作某步驟時不斷摸下巴，是遇到了什么困難嗎？等等）。

用戶訪談

提問過程屬于訪談內(nèi)容咯，這里就不進行展開談啦～后續(xù)會繼續(xù)寫篇訪談技巧文章的～

問卷回收/總結

任務、訪談結束后就可以掏出咱們準備好的各種表讓他填啦。ASQ、SUS 等等量表。

著重說一下用戶體驗記錄，此表需讓用戶根據(jù)（京東團隊整理的）21 條可用性原則輔助理解進行填寫，21 條會將問題進行分類：例導航、頁面、內(nèi)容、功能需求等等，方便我們后續(xù)對問題進行整理。（注意表中需允許用戶插入圖片，可以輔助我們準確判斷用戶所闡述問題點在哪。）此表偏向于讓專家級用戶填寫，對小白用來說戶理解成本偏高，咱們很難有效回收問卷。

匯報一下

總結匯報

將咱們訪談過程遇到的問題、問卷回收問題進行分類整理。描述問題點、問題出現(xiàn)原因是什么、缺陷重要程度、是否有優(yōu)化空間、是否存在對應的某些設計難點等等。總結并輸出設計建議反饋到領導以取得支持。

總體來看一遍訪談流程

知道很多伙伴可能看的看那么多字，在此總結了測試框架，大家按框架去執(zhí)行可用性測試就好啦。

流程框架

此外擔心表格內(nèi)容看不清，為大家放大一下，有需要的伙伴可以拿去抄作業(yè)。

記錄表 、匯總表、維度表

ASQ 、SUS、21 條

21 條/緯度包含了大部分設計落點，不會定義目標的伙伴可在表內(nèi)尋找問題，帶著問題進行倒推 走查自己的項目。

可用性測試還需要用到用戶記錄表、劇本設計、任務表等等，這里就不為大家一一展示了，畢竟每個人所做的事、所處的環(huán)境不同，此類表大家按需自定義就好咯。

伙伴們也可將本篇框架帶入自己的作品集，多提一嘴，咱們總談到的‘用戶體驗地圖’其實也與可用性測試息息相關，如果你有在作品中提到體驗地圖，將其與可用性測試關聯(lián)在一起可很大程度的怎加地圖可信度。

這就是發(fā)現(xiàn)問題—分析問題—提出方案的過程嘛～有框架做支撐就不會讓人覺得的作品設計一眼假嘍～希望本次寫的內(nèi)容可以對你有所幫助。

最后！祝你和男神女神吃飯愉快

拜拜～