簡介面向高校人機交互課程學習者與期末項目完成者這套實驗資料圍繞二維交互畫圖板、語音交互、界面設計與VRML虛擬現(xiàn)實四組實驗展開并配套綜合性大實驗幫助讀者完成從需求分析、界面布局、原型制作到用戶測試的完整訓練。包內共86個文件約24.97MB含6份doc實驗報告、5份ppt課件、5組cpp與h源碼及obj/pdb等編譯中間文件、22張bmp界面素材、2份pdf教程和2個wrl虛擬現(xiàn)實場景另有語音SDK參考文檔與TTS示例便于對照實驗步驟復現(xiàn)并做二次修改。已有2487人學習。資料覆蓋訂單管理、BBS、飛機訂票查詢等界面設計案例也提供VRML入門教程與示例場景讀者可參考報告結構、評估思路、源碼組織與原型實現(xiàn)方式適合課程實驗提交、大作業(yè)選題以及交互設計方案復盤。1. 一張人機交互的知識地圖實驗報告和最后大實驗其實是同一條鏈很多人把人機交互的實驗報告和最后大實驗當成兩件事前者是寫文檔后者是做原型。實際上它們位于同一條鏈的兩個位置一條為「人—任務—界面」的認知線關注用戶怎么感知、決策、出錯另一條為「設計—原型—評估—迭代」的工程線關注界面如何被改到能用。實驗報告是把這條鏈上某一次觀測寫成可復現(xiàn)的證據大實驗是把整條鏈走一遍并留下修改痕跡。這份材料適合兩類人期末要交報告、要答辯的以及正在復習、需要把零散概念連成網的人。地圖先記住一句話所有實驗設計都在回答「我改了什么、我測了什么、別的變量控住了沒有」所有評估方法都在回答「誰在什么任務上卡住了、卡得多嚴重」。2. 實驗報告的骨架假設、變量、數(shù)據表三件套實驗報告寫得像流水賬多半是在動筆時才開始想「我要證明什么」。真正決定分數(shù)的部分在動手做實驗之前就已定型一句可檢驗的假設、一張變量對照表、一份不用返工的數(shù)據表結構。這三樣定死后面的統(tǒng)計和討論只是順著往下推。2.1 八段式結構里哪幾段真正決定分數(shù)課程報告的段落順序基本固定但評分點分布極不均勻。下面這張表把每段「必須回答的問題」和最常見的缺失列在一起寫之前先對照看一遍。| 段落 | 必須回答的問題 | 最常見缺失 | | 引言 | 要驗證什么、為什么值得驗證 | 只有背景鋪陳沒有可檢驗的假設 | | 方法 | 別人照著寫的內容能不能復現(xiàn) | 缺指導語原文、缺條件順序安排 | | 結果 | 數(shù)據長什么樣、差異是否穩(wěn)健 | 只放圖不放描述統(tǒng)計無效應量 | | 討論 | 結果支持還是推翻了假設 | 把局限寫成客套話不解釋異常數(shù)據 | | 結論 | 一句話能帶走什么 | 重復結果段沒有收斂到設計建議 |假設的寫法有個硬標準可檢驗、有方向、帶指標?！覆季?A 更好用」不是假設是口號「布局 A 的任務完成時間顯著短于布局 B且錯誤率不高于 B」才是假設——它規(guī)定了比較對象、指標和方向也提前堵死了事后挑數(shù)據的路。方法段最容易失分的地方是「指導語」。被試聽到的每一句話都會影響行為所以指導語要原文照錄包括你怎么解釋任務、允不允許提問、有沒有告訴被試可以隨時終止。這部分寫全了報告立刻從「學生作業(yè)」變成「可復現(xiàn)的實驗」。2.2 自變量、因變量、控制變量一張表定死變量定不清后面所有統(tǒng)計都是白算。做界面實驗時把這幾類變量攤在一張表上比在腦子里過一遍可靠得多。| 變量類型 | 具體例子 | 記錄方式 | | 自變量 | 布局方案A/B、目標尺寸三檔、菜單廣度4/8/16 | 條件編號寫進每一行數(shù)據 | | 因變量 | 完成時間、錯誤率、點擊次數(shù)、量表得分 | 每次試驗一行不合并 | | 控制變量 | 屏幕分辨率、指針速度、字號、任務內容 | 固定值寫進方法段 | | 混淆變量 | 學習效應、疲勞、練習量、被試間能力差異 | 用平衡順序和練習試次壓住 |表里最容易被忽略的是最后一行?；煜兞坎粫驗槟銢]寫就不存在它只會悄悄混進結果里讓你在討論段寫不出一句有底氣的話?？刂扑氖侄螣o非三種隨機化條件順序、用拉丁方做平衡、每個條件前加固定輪數(shù)的練習試次并把練習數(shù)據剔除。還有一個常被忽略的區(qū)分被試內設計和被試間設計。同一批人做所有條件叫被試內樣本效率高但必須平衡順序不同人分到不同條件叫被試間沒有順序問題但個體差異會變成噪聲。課程實驗里九成用的是被試內而九成的翻車也都出在忘了平衡。2.3 數(shù)據表怎么設計才不用返工數(shù)據表的格式在實驗開始前就該定下來因為一旦開始錄數(shù)據改表頭等于重做。推薦用「長表」一行一次試驗所有條件混在一列里用字段區(qū)分。subject_id,condition,block,trial,mt_ms,error,target_w_px,distance_px,sus S01,layout_A,1,1,842,0,32,256, S01,layout_A,1,2,795,0,32,256, S01,layout_B,2,1,1103,1,32,256,每列的含義要固定subject_id是被試編號去標識化不要寫真名condition是條件名block是第幾輪trial是輪內第幾次mt_ms是這次試驗的完成時間毫秒error用 0/1 表示是否出錯后兩列是自變量的實際取值sus只有每個條件結束時填一次其余行留空。為什么不推薦寬表每個條件一列因為條件數(shù)一旦變動就得改表頭而且缺數(shù)據會變成空格統(tǒng)計時很難區(qū)分「沒測」和「測了為 0」。長表還有個好處能直接接分組聚合。import pandas as pd # 一行一次試驗的長表先聚合到「被試 × 條件」再進統(tǒng)計檢驗 df pd.read_csv(trials.csv) per_subject (df.groupby([subject_id, condition])[mt_ms] .mean() .unstack()) # 行 被試列 條件 print(per_subject.describe())這段代碼的關鍵動作是groupby再mean把幾百行試驗壓成「每被試每條件一個均值」。不做這一步直接拿幾百行 trial 去做配對檢驗樣本量會被虛增十幾倍p 值必然漂亮——這是整個方向里最典型的踩坑方式之一而且很難在結果段自查出來。參數(shù)上要注意unstack()之后行是被試、列是條件配對檢驗要求兩列長度一致缺數(shù)據的被試要么整行剔除要么在報告里說明處理方式。3. 經典實驗范式菲茨定律、希克定律與布局對比課程實驗報告里出現(xiàn)頻率最高的三類題目本質是三種不同的測量對象菲茨定律測「指向動作的難度」?？硕蓽y「選項數(shù)量帶來的決策成本」布局對比測「整體方案在真實任務下的績效」。前兩個是可控的經典范式第三個是把前兩個的指標組合起來做一個綜合判斷。3.1 菲茨定律實驗ID、MT、TP 三個量怎么算菲茨定律描述的是「從起點移動到目標并點擊」這件事有多難。核心量是難度指數(shù) ID單位是比特ID log2(2D / W)D 是起點到目標中心的距離W 是目標沿運動方向上的尺寸。移動時間 MT 與 ID 呈線性關系MT a b·ID。吞吐量 TP ID / MT單位 bit/s用來橫向比較不同設備或不同設計方案。import math def fitts_id(distance_px, width_px): 難度指數(shù) ID單位 bit。 distance_px起點到目標中心的距離 width_px目標沿運動方向上的尺寸橫排按鈕量寬豎排量高 if distance_px 0 or width_px 0: raise ValueError(距離和目標寬度都必須為正數(shù)) return math.log2(2 * distance_px / width_px) def throughput(ids, mts): 吞吐量 TP每個條件各自算 ID/MT 再取平均 而不是拿平均 ID 除以平均 MT。 pairs [(i / t) for i, t in zip(ids, mts) if t 0] return sum(pairs) / len(pairs)參數(shù)上有三個坑值得單獨說。第一距離和目標寬度的單位必須統(tǒng)一都用像素或都用毫米混著算出來的 ID 沒有意義。第二W 取的是「沿運動方向」的尺寸一排橫向排列的按鈕量的是寬度一列縱向排列的菜單項量的是高度。取錯了ID 會系統(tǒng)性偏大或偏小。第三2D/W 必須大于 1否則 ID 為負或為零說明這個任務對用戶毫無難度測出來的時間只是在測手抖。一般把 ID 設計在 1 到 7 bit 之間覆蓋「很容易」到「需要專注」的區(qū)間。throughput函數(shù)里那句注釋是本節(jié)的真正重點。很多人先算所有條件的平均 ID 和平均 MT再一除得到 TP這在數(shù)學上不等于「各自算再平均」條件之間難度差異越大兩者偏得越遠。答辯被問到這一句答不上來基本就露餡了。3.2 希克定律與菜單選擇選項數(shù)量不是線性成本?？硕芍v的是決策時間隨選項數(shù)量的增長方式選項越多決策越慢但增長是對數(shù)的不是線性的。常見形式是 RT a b·log2(n 1)n 是等概率選項數(shù)。這條定律最常被用在菜單設計的爭論上一個大而扁的菜單還是幾個小而深的層級純按公式推似乎寬而扁更優(yōu)因為多一層就要多一次決策。但真實界面里選項不是同時可見的用戶還得做視覺掃描和尋找所以純?？硕芍贿m用于「所有選項同時呈現(xiàn)、位置隨機、彼此無視覺層級差異」的場景。設計這類實驗時把「決策時間」和「視覺搜索時間」分開記錄會更嚴謹可以用兩種條件一種是選項位置固定熟手靠位置記憶一種是每次隨機必須逐個讀兩者的差值就近似視覺搜索的貢獻。這個設計思路寫進討論段比單純復述公式有分量得多。3.3 布局對比實驗把「感覺更好用」變成可測的數(shù)布局對比是最后大實驗里最常見的題目形態(tài)也是最容易做成主觀感想的一類。要讓它站得住指標要提前定且至少覆蓋績效和主觀兩側。| 指標 | 采集方式 | 需要提前定死的事 | | 任務完成時間 | 從首次點擊到目標達成 | 起點和終點的判定規(guī)則 | | 錯誤率 | 錯誤點擊數(shù) / 總點擊數(shù) | 什么算錯誤誤點后算不算重來 | | 操作步數(shù) | 完成任務經過的界面數(shù) | 返回算不算一步 | | 指針移動距離 | 采樣點累加 | 采樣率會影響結果需固定 | | 主觀負荷 | 六維度負荷量表測試后立即填 | 填表時機要統(tǒng)一 | | 偏好排序 | 兩方案二選一或排序 | 偏好不能替代績效數(shù)據 |設計上建議每個條件至少十次有效試驗前面加固定輪數(shù)的練習并把練習數(shù)據剔除條件順序用拉丁方平衡避免所有人都是先做 A 后做 B——先做的那個一定吃虧因為界面還不熟。這個「吃虧」在數(shù)據上表現(xiàn)為 A 的完成時間系統(tǒng)性偏長而你很可能把它解釋成「A 的設計更差」這就是典型的把混淆變量當結論。4. 評估與迭代三種評估方法和最后大實驗的完整鏈路原型做出來只是開始能不能畢業(yè)看的是評估。三種方法的分工很明確啟發(fā)式評估靠專家經驗快速掃雷成本最低認知走查靠逐步推演不需要真實用戶適合極早期可用性測試靠真實用戶做真實任務最貴也最有說服力。三者不是替代關系是按階段遞進的關系。4.1 啟發(fā)式評估十條原則怎么變成問題清單十條原則背下來不難難的是把它們變成一條條能落到具體界面上的檢查問句。下面這版對照表是按「問句化」整理的走查時逐條念出聲即可。| 原則 | 檢查問句 | 典型問題 | | 狀態(tài)可見 | 系統(tǒng)現(xiàn)在在做什么用戶一秒內能看出來嗎 | 保存無反饋、加載無進度提示 | | 貼合現(xiàn)實 | 用詞是不是用戶自己的語言 | 出現(xiàn)內部代號、字段名、縮寫 | | 用戶可控 | 誤操作能不能撤回 | 刪除無二次確認、無撤銷入口 | | 一致性 | 同一個動作在不同頁面是不是同一個說法 | 「確定/保存/提交」混用 | | 錯誤預防 | 能不能在出錯之前攔住 | 日期讓用戶自由文本輸入 | | 識別優(yōu)于回憶 | 需要的選項是不是擺在眼前 | 要用戶記住上一步的編號 | | 靈活高效 | 有沒有給熟手留一條捷徑 | 只能一步一步點無批量操作 | | 極簡設計 | 屏幕上有沒有和當前任務無關的元素 | 裝飾圖表擠占主操作區(qū)域 | | 錯誤恢復 | 報錯有沒有說清原因和下一步 | 「操作失敗請重試」 | | 幫助文檔 | 幫助是不是出現(xiàn)在用戶需要的位置 | 幫助入口埋在三級菜單里 |流程比表格更重要。正確做法是三到五名評估者各自獨立走查、各自列問題然后才合并去重先討論再走查會迅速收斂到同一種視角問題數(shù)量直接砍半。合并之后按「出現(xiàn)頻率 × 嚴重程度」分級嚴重度可以用四級一級是外觀瑕疵二級是輕微不便三級是阻礙任務完成四級是可能導致數(shù)據丟失或誤操作。最后輸出一張問題表每行寫明位置、觸犯的原則、嚴重度、修改建議——這張表就是大實驗迭代階段的輸入。4.2 認知走查四個問題逐屏過一遍認知走查不需要用戶靠的是評估者把自己代入一個具體用戶沿著一條具體任務逐屏問四個問題用戶會不會嘗試達成這個效果界面提供的操作和用戶的目標對不對得上用戶能不能注意到正確的操作是可用的可見性夠不夠用戶會不會把這個操作和想達成的效果聯(lián)系起來映射清不清楚執(zhí)行之后用戶能不能看出操作已經生效有沒有反饋四問的順序不能亂因為它對應的是「形成目標—尋找操作—建立映射—評估結果」這條認知鏈。任何一問卡住都記一個設計缺口并注明是「通過 / 失敗 / 存疑」。存疑不要強行判通過標記出來留到可用性測試里驗證。這套方法最適合低保真階段紙面原型上做認知走查改一筆成本幾乎為零等到高保真做完再走查改一個交互可能牽動整條流程。帶血淚經驗的一條是走查時一定要挑「第一次使用」的用戶視角而不是「已經用了三天」的自己。4.3 可用性測試任務腳本、發(fā)聲思考與量表計分可用性測試最容易做錯的地方不在數(shù)據分析在任務腳本。腳本寫的是目標不是步驟?？聪旅孢@一組對比反例點擊右上角的設置圖標然后選擇通知選項把開關關掉。 正例假設你不想再收到這類提醒了請把提醒關掉。反例里每一步都寫明了位置和操作測的其實是「用戶能不能照著指令點」測不出任何可用性問題。正例只給目標用戶怎么找到入口、會不會迷路、會不會點錯才是要觀察的東西。主持人全程只說兩句話「你現(xiàn)在在想什么」和「繼續(xù)」。任何一次「你可以試試左邊那個」都會讓這一輪數(shù)據作廢。樣本量上有個常用的經驗值同一類用戶群、同一類任務五名被試大約能暴露大部分約八成以上的可用性問題。這個數(shù)字經常被誤用成「五個人就夠了」——它成立的前提是用戶群單一、任務類型集中。如果你的產品有兩類差異很大的用戶五個人分攤到兩類里就不夠了。主觀量表最常用的是十題版的系統(tǒng)可用性量表。這十題里有一半是正向描述、一半是反向描述計分時必須反向翻轉這一步是重災區(qū)def sus_score(responses): 十題系統(tǒng)可用性量表計分。 responses長度為 10 的列表每題原始分 1~5。 奇數(shù)題1/3/5/7/9正向貢獻 原始分 - 1 偶數(shù)題2/4/6/8/10反向貢獻 5 - 原始分 assert len(responses) 10, 必須正好十題 assert all(1 r 5 for r in responses), 原始分必須在 1~5 之間 total 0 for idx, raw in enumerate(responses, start1): total (raw - 1) if idx % 2 1 else (5 - raw) return total * 2.5 # 0~40 折算到 0~100每題的貢獻是 0 到 4 分十題合計 0 到 40乘 2.5 折算到 0 到 100 區(qū)間。這里有個必須說清的點這個分數(shù)不是百分比不能說「可用性 80%」。它只是一個約定區(qū)間的分數(shù)業(yè)界常拿 68 分當平均參考線八十分以上算比較順但樣本量只有五個人時單看均值意義有限更該看的是每個人在哪幾題上給了低分——那幾題指向的才是具體問題。4.4 最后大實驗的六步鏈路每一步的產出和驗收標準大實驗失分往往不是因為做得少而是因為階段之間沒有咬合原型做得很漂亮但需求說不清來自哪里測試做了一堆但改了什么沒有記錄。把六步的產出和驗收標準列清楚進度和成文都會輕松很多。| 階段 | 主要產出 | 判定通過的標準 | | 選題 | 一句話問題陳述 目標用戶描述 | 能說清「誰在什么場景下被什么卡住」 | | 用戶研究 | 三到五份訪談記錄、需求清單 | 每條需求都能追溯到某條原始記錄 | | 任務分析 | 層次任務分析表或用戶旅程圖 | 每個任務有明確起點和終點 | | 低保真 | 紙面或線框原型 | 認知走查無三級以上缺口 | | 高保真 | 可點擊原型 | 主流程能獨立走通五人測完 | | 迭代與成文 | 問題清單、修改對照表、報告 | 每個問題都有處理結論 |兩點取舍經驗。一是別在高保真上過度投入視覺精細度和可用性沒有必然關系把時間花在第二輪測試上收益更高。二是迭代記錄要做成「問題—修改—驗證」三列而不是只寫「已優(yōu)化」答辯時被追問「你怎么知道改好了」能翻出第三列的人立刻占優(yōu)。5. 易漏易錯點五個讓報告掉檔的細節(jié)5.1 條件順序沒平衡學習效應冒充了設計差異易漏點被試內設計里所有被試都按「先 A 后 B」的順序做結果 A 的完成時間偏長報告寫成「A 方案更難用」。為什么漏數(shù)據本身沒有異常兩組均值確實差著統(tǒng)計檢驗也顯著從數(shù)字上完全看不出問題。學習效應藏在順序里不做平衡就永遠暴露不出來。怎么補一半被試走 A→B另一半走 B→A也就是最基礎的拉丁方平衡每個條件前加固定輪數(shù)的練習試次并剔除練習數(shù)據分析時把「順序」當成一個額外因素看一眼如果順序的主效應很大說明平衡沒做好得在討論段如實說明。5.2 量表反向題沒翻轉分數(shù)全反了易漏點十題量表里反向題直接按原始分累加算出來的分數(shù)看著像模像樣方向和真實感受相反。為什么漏正向題和反向題混排錄入時逐行敲數(shù)字很容易一路順著敲下去而且錯誤結果仍然落在合理區(qū)間內不會報錯、不會越界屬于典型的黑匣子錯誤。怎么補把計分寫成函數(shù)參考 4.3 的實現(xiàn)奇數(shù)題減一、偶數(shù)題用五減輸入前先斷言范圍錄完隨機抽兩三份手工復算一遍對不上就整批重來。這一步花五分鐘能省掉答辯現(xiàn)場被要求現(xiàn)場重算的尷尬。5.3 任務腳本里藏了操作提示測試變成了教學易漏點腳本寫「點擊右上角設置選擇通知關閉開關」用戶順利完成成功率 100%報告寫「界面易于使用」。為什么漏腳本讀起來非常自然像是正常的任務描述寫的人自己意識不到已經把所有決策都替用戶做完了。而且成功率漂亮沒人會去質疑。怎么補寫完腳本做一次自查——把腳本里所有方位詞和控件名劃掉看剩下的句子還能不能構成一個完整目標。不能就重寫。測試時主持人只記錄不提示用戶問「是不是點這里」回一句「你覺得呢」即可。5.4 只報 p 值不報效應量和樣本處理易漏點結果段寫「p 0.05差異顯著」然后直接下結論說方案 A 明顯更好。為什么漏顯著性檢驗是最容易出結果的一步軟件一點就有數(shù)字而效應量、置信區(qū)間、異常值處理這些「不顯著但重要」的東西教材上往往一筆帶過。怎么補每個主要比較都配一個效應量并在方法段寫清樣本量、剔除標準和剔除數(shù)量。樣本量只有八到十人的課程實驗里p 值本身很不穩(wěn)定多報一個效應量能讓結論的可信度上一個大臺階。順便說前文提到的「拿幾百行 trial 直接做檢驗」也是同一類問題的變體——先把數(shù)據聚合到被試層面再談顯著性。5.5 原型做太早太細來不及迭代易漏點第二周就開始摳高保真細節(jié)到測試階段只剩三天測出來的問題一個都改不完報告里只能寫「后續(xù)可優(yōu)化」。為什么漏做界面比想需求有成就感工具又順手很容易一頭扎進去。等到發(fā)現(xiàn)方向錯了沉沒成本已經很大改不動了。怎么補把「低保真通過認知走查」設成硬門檻沒通過不許進高保真高保真只做能走通主流程的最小集合裝飾性內容留到最后。測試排期往前挪至少留出兩輪修改時間——第一輪改大問題第二輪驗證改得對不對這個節(jié)奏比任何視覺細節(jié)都值錢。6. 復習清單交稿前把報告倒著讀一遍復習這個方向最有效的方式不是重看教材而是拿自己那份報告做一次逆向檢查。下面這張自查表按「最容易忘」到「最不容易忘」排序交稿前從上往下過一遍。| 序號 | 檢查項 | 不合格的表現(xiàn) | | 1 | 假設有方向、有指標 | 只有「更好用」這類描述 | | 2 | 指導語原文完整 | 方法段只有「被試按指示完成任務」 | | 3 | 條件順序已平衡 | 所有人順序一致報告不提順序 | | 4 | 數(shù)據已聚合到被試層面 | 直接用 trial 行數(shù)當樣本量 | | 5 | 量表反向題已翻轉 | 沒有計分函數(shù)手工敲的數(shù)字 | | 6 | 每個比較都有效應量 | 只有 p 值 | | 7 | 剔除標準寫清 | 只說「剔除異常值」不說怎么判 | | 8 | 任務腳本無操作提示 | 腳本里出現(xiàn)方位詞和控件名 | | 9 | 問題清單有嚴重度分級 | 一長串問題不做優(yōu)先級 | | 10 | 迭代記錄有「驗證」列 | 只寫「已優(yōu)化」 | | 11 | 局限段解釋異常數(shù)據 | 局限寫成「樣本量較小」一句帶過 | | 12 | 圖表有單位和誤差線 | 只有均值柱無離散程度 |然后試一個倒讀技巧從結論段往回讀每讀到一句判斷就往前找支撐它的那個數(shù)字。讀三遍基本能揪出所有「結論跑在數(shù)據前面」的句子——這是評審最容易抓住、也最難辯解的一類問題。倒讀還有個副作用會讓你發(fā)現(xiàn)某些圖其實可以刪掉因為它們不支撐任何一句結論。最后說一個習慣。從那以后我每次做完實驗都會在收數(shù)據當天就把長表按「被試 × 條件」聚合一遍看一眼極值和缺失再決定要不要補測等寫完報告再回頭看數(shù)據往往已經來不及補了。這個動作花不到十分鐘但它把「數(shù)據能不能用」這個問題提前到了還能補救的時候。希望幫到你。本文還有配套的精品資源點擊獲取