简介：面向高校人机交互课程学习者，这套资料包尤其适合正在完成课程实验、撰写实验报告和期末综合项目的本科生。内容围绕用户需求分析、界面设计原则、交互模式、无障碍设计与可用性评估展开，涵盖二维交互式画图板、语音交互程序、订单管理、BBS与订票查询系统界面设计、VRML虚拟现实交互等实验场景，并给出期末大实验从需求分析、线框图与原型制作到用户测试的完整实践线索，便于对照理解实验组织方式与报告写作结构。压缩包共86个文件、约24.97MB，以ppt课件、doc实验报告与设计文档、cpp与h源码、bmp与wrl素材以及exe、obj等编译文件为主，兼具理论参考、可运行示例和界面素材。已有2487人学习，适合用来梳理实验流程、复用界面设计思路、补充评估方法，也可为课程项目选题、原型迭代和答辩整理提供参考。

1. 从一份被打回的实验报告说起：这套方案要解决什么

A同学把十二页的人机交互实验报告交上去，被打回的理由只有一句：通篇在写自己点了哪里，没有一句在说这个界面为什么好用、好用多少。这是这门课最容易踩的坑——实验报告不是操作记录，它得用指标说话。这套材料就是围绕这句话搭起来的：前半段是若干基础实验，每个实验只练一种能力，走查、任务分析、纸面原型、交互方式对比、行为日志、量表评估；后半段是一次大实验，把这些能力串成完整链路——选题收敛、任务拆解、低保真到高保真、可用性测试、两轮迭代、评估结论。它适合要交人机交互课程设计、实验报告，或者毕设开题做交互原型的人；也适合需要出一份可用性测试方案的产品与设计同学，照着改参数就能直接跑。

2. 实验体系设计：六个基础实验与一次大实验的能力链路

基础实验最容易散：六个实验各写各的，工具换三套，数据格式互不相认，到了大实验又得从头搭一遍。合理的做法是把它们设计成一条流水线，前一个实验的产出物正好是后一个实验的输入。我一般会先把整门课的实验矩阵画出来，确认每个实验只承担一种能力训练，再决定用什么工具、采什么数据，这样大实验阶段就不需要返工。

2.1 实验矩阵：每个实验只练一种能力

矩阵的价值在于防止两件事：一是每个实验都在做"设计一个界面"这种大而全的活，二是六个实验其实在重复同一件事。把能力和指标对齐之后，报告里该出现什么数据就变得很明确。

从表里能看出一条依赖关系：实验二拆出来的步骤，是实验三纸面测试的任务脚本；实验四的对照组设计，决定了大实验里改版前后怎么比；实验五的日志格式，直接复用到大实验的高保真原型上。所以我建议在开课第二周就把这张表定下来，后面每个实验只往里填数，不再改结构。

实验四的对照设计值得单独说一句。很多报告把"交互方式对比"写成两个界面各找几个人用一下，然后说 A 比 B 快，这种结论站不住，因为人不一样、任务顺序不一样、熟练度不一样。通常的做法是同一批被试做两条任务路径，顺序做拉丁方平衡，一半人先 A 后 B，另一半反过来，这样学习效应会被摊平。样本量小的时候不要报平均值差 0.3 秒这种精度，报中位数和每个人的变化方向更诚实。

2.2 指标口径：四个客观量加两个主观量，先定死再开测

指标口径必须在测试前写进方案，不能等数据收完再回头解释。我见过最典型的翻车是"任务完成率"这一项：有人把"完成了但中途求助过"算成功，有人算失败，两组数据放一起就没法比。所以每个指标都要带一句判定规则。

SUS 的计分规则要写在报告的方法部分，不然读者不知道你的分是怎么来的：奇数题（第 1、3、5、7、9 题）用得分减 1，偶数题用 5 减得分，十项求和后乘 2.5，得到 0 到 100 的分数。这个分数是量表分不是百分制成绩，报告里别写成"可用性 82 分，良好"，只能说"高于该量表的行业参考基准"，并且把参考基准的来源交代清楚。

认知负荷这一项容易被写虚。合理的写法是让被试在任务结束后立刻对六个维度各打一个分（脑力需求、时间压力、努力程度、受挫程度、绩效感受、体力需求），当场收，不要事后回忆。维度分可以只报均值，但报告里要说明这是自评，不能等同于客观负荷。

提示：指标数量控制在六个以内。指标一多，每个被试的测试时间会拖到四十分钟以上，疲劳会直接污染后面的数据。

2.3 技术选型：原型要能吐数据，工具要能留证据

选型只看一件事——这个工具能不能产出可以贴进报告的证据。纯图片原型做出来好看，但测试时所有数据都得靠人肉记，一旦主试走神就丢一条。工具对比按这个标准排一遍就清楚了。

我一般的分工是：实验三用纸面原型，成本低、改起来快，重点是把卡点找出来；大实验用 Web 前端或桌面 GUI 做高保真，因为只有能埋点的原型，才拿得到时长、错误次数、路径这类客观量。前端技术栈不必复杂，原生 HTML + JavaScript 加 localStorage 就够，别为了埋点去搭一套后端服务，测试现场网络不稳的时候那是自找麻烦。

还有一条经验：原型里每一个可点击区域都给它一个稳定的标识，别用"按钮 1、按钮 2"这种按顺序命名的东西。改版之后按钮顺序一变，历史日志就对不上号了，这个坑我在第一次做迭代对比时踩得很实。

3. 基础实验报告：七段式骨架与可直接跑的采集脚本

基础实验报告的长度不必长，六到十页足够，但结构必须齐。评审看的不是文采，是有没有把"做了什么、看到什么、说明什么"三件事分开写清楚。下面这套骨架我用了很多次，改参数就能套到不同实验上。

3.1 七段式骨架：每段都要有证据

第二段和第四段是最容易失分的地方。被试信息写成"同学若干"，评审没法判断样本是否有偏；数据只贴一张截图，没有单位、没有样本量，读者没法核对。我通常会在报告开头放一张被试信息表，只写编号、年龄段、相关经验年限，不写姓名和身份，既匿名又可追溯。

分析段有个常见的写法问题：只报"平均时长 32 秒"，然后下结论说效率可以接受。这个结论没有参照物。要么给对照组，要么给上一版的数据，要么给任务本身的合理上限（比如按步骤数估算理论最短时间）。三者至少有一样，结论才立得住。

任务描述里不能带操作答案，这条听起来简单，实际特别容易违反。写成"点击右上角的设置按钮进入偏好页"就把答案给出去了，被试只是执行指令，测不出任何东西。合格的写法是"把界面的字号调大"，只说目标，不说路径。

3.2 埋点采集：一个能直接跑的日志脚本

基础实验阶段不必上全家桶，一个几十行的记录器就能把关键字段收齐。下面这段可以直接跑，被试在电脑上做任务，主试在关键节点按一下键。

# log_session.py —— 单机交互日志记录器 # 用途：被试每完成一条任务，写一行记录到 CSV，报告里的时长/点击/错误都从这来 import csv import time import uuid from datetime import datetime SESSION_ID = uuid.uuid4().hex[:8] # 会话号，报告里用它代替姓名做匿名标识 class TaskRecorder: def __init__(self, path="events.csv"): self.path = path self.t0 = None self.clicks = 0 self.errors = 0 def start(self): # perf_counter 是单调时钟，不受系统时间调整影响，测时长更稳 self.t0 = time.perf_counter() self.clicks = 0 self.errors = 0 def click(self): self.clicks += 1 def error(self, note=""): self.errors += 1 def stop(self, participant, task, note=""): duration = time.perf_counter() - self.t0 row = [ SESSION_ID, participant, task, round(duration, 2), self.clicks, self.errors, datetime.now().isoformat(timespec="seconds"), note, ] # 用追加模式，测试中断也不丢已记录的行 with open(self.path, "a", newline="", encoding="utf-8") as f: csv.writer(f).writerow(row) return duration if __name__ == "__main__": rec = TaskRecorder() rec.start() input("任务进行中，按回车结束...") rec.stop(participant="P03", task="T2_修改字号", note="中途求助一次")

字段含义要说得清：duration单位是秒，保留两位小数，报告里统一换算成秒或分钟，别一半秒一半毫秒；clicks是被试的点击总数，用来和任务的理论最少点击数对比，比值超过 2 就说明路径有问题；errors只记造成返工的操作，误触不记，否则错误率会被手抖污染；note留给主试写现场观察，比如"犹豫 5 秒后才发现入口"，这类信息事后补是补不出来的。

perf_counter而不是time.time()的原因值得在报告里写一句：前者是单调递增的，后者可能因为系统校时出现负的时长。这种细节写进去，评审会认为你真的跑过测试。

3.3 量表计分：SUS 与认知负荷别手算

十道题手算两三个人还能忍，人一多必然出错，方向一反就全错。用 pandas 三行就能算完，而且能把汇总表直接输出成报告要的格式。

# sus_score.py —— SUS 计分与汇总 import pandas as pd def sus_score(row): """row 为 10 个 1~5 的评分，返回 0~100 的量表分""" total = 0 for i, v in enumerate(row, start=1): # 奇数题正向计分减 1，偶数题反向用 5 减 total += (v - 1) if i % 2 == 1 else (5 - v) return total * 2.5 df = pd.read_csv("sus.csv") # 列：participant, q1 ... q10 items = [f"q{i}" for i in range(1, 11)] # 缺失值先检查，不要直接填 0，0 会被算成极端负向 missing = df[items].isna().sum().sum() print("缺失项数量:", missing) df["sus"] = df[items].apply(sus_score, axis=1) print(df[["participant", "sus"]].describe().round(2)) # 样本量小于 10 时，中位数比均值更能代表典型水平 print("中位数:", round(df["sus"].median(), 2))

参数说明：sus.csv每题一列、每人一行，分数写 1 到 5，不要预先做反向转换，反向转换在函数里做，这样原始数据永远可复查。describe()会给出均值、标准差、四分位，报告里贴这张表比贴十个分数更清楚。样本量小的时候（这门课的实验通常五到八人）我建议报中位数和极值，同时把每个人的分数列出来，别用均值假装自己是统计显著。

注意：SUS 不是越高越好地线性增长，60 出头和 80 出头在实际体验上的差别没有分数看起来那么大，报告里下结论要克制。

3.4 数据表结构：原始数据留档，报告才有复盘可能

一个人做实验很容易所有数据塞进一个 Excel，列越加越多，最后自己都分不清哪列是最初记录的、哪列是后来算的。分三张表能解决这个问题。

-- 会话表：一次测试一位被试一行 CREATE TABLE sessions ( session_id TEXT PRIMARY KEY, -- 与日志脚本里的会话号一致 participant TEXT NOT NULL, -- 被试编号，如 P03 prototype TEXT NOT NULL, -- 原型版本，如 v1 / v2 test_date TEXT NOT NULL, moderator TEXT ); -- 事件表：一条任务一行，原始记录不改动 CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, session_id TEXT REFERENCES sessions(session_id), task_code TEXT NOT NULL, -- 如 T2_修改字号 duration_s REAL NOT NULL, clicks INTEGER DEFAULT 0, errors INTEGER DEFAULT 0, help_count INTEGER DEFAULT 0, note TEXT ); -- 评分表：主观量表单独存，方便按版本对比 CREATE TABLE ratings ( session_id TEXT REFERENCES sessions(session_id), instrument TEXT NOT NULL, -- sus / nasa_tlx item TEXT NOT NULL, -- q1 ... q10 或维度名 score INTEGER NOT NULL );

分表的关键理由是版本对比。改版之后原型版本号变了，会话表里prototype一列就能把 v1 和 v2 的数据切开，事件表和评分表通过session_id关联，一条 SQL 就能出对比结果。原始表只追加不修改，算出来的分放视图或者新表，这样报告里的任何数字都能回溯到某一行原始记录。评审如果追问"这个 0.5 是怎么来的"，你能当场打开表指给他看，这比任何解释都有用。

4. 综合大实验：从选题收敛到两轮迭代的完整链路

大实验失败的方式高度相似：题目太大，做到一半发现测不了，最后拿几张漂亮截图凑成一份设计说明。能顺利走完的大实验，共同点是范围被压得很小——小到一个明确的用户、三到五条任务、两个版本。下面按执行顺序拆开讲。

4.1 选题收敛：把"我想做个 App"拆成三条可测任务

选题阶段唯一要产出的东西是任务清单，不是灵感。我一般按这个顺序推：先定一个人物（虚构代称即可，比如"每周要整理一次课程资料的学生"），再定一个场景（"晚上在宿舍用笔记本整理"），然后从这个场景里抽任务。任务必须是用户真要干的事，不能是"体验一下首页"这种测试用语。

时长上限的估算方法是：数一遍任务的理论最少操作步数，每步按 3 到 5 秒算，再乘 2.5 留出认知时间。这个上限写在报告里有两个好处，一是测试时能判断什么时候该介入，二是分析时能算出"实际时长与理论最短时长的比值"，效率就有了参照物，不用和空气比。

选题阶段还要提前想清楚一件事：这个题目有没有可比的两个版本。大实验要写迭代，就必须有 v1 和 v2。如果选题本身只能做一个版本（比如只有一个方案可选），那就在交互细节上留出对照组，比如两种信息排布、两种导航方式，用实验四的方法做。

4.2 信息架构与低保真：先做减法再做美化

低保真阶段最容易跑偏的是直接开始画界面。正确的顺序是先列页面清单，再定层级，最后才是画。页面清单用一张表控制数量，超过八个页面，五到八个被试的测试量就撑不住了。

优先级这一列不是给开发看的，是给测试脚本用的。低优先级页面不进第一轮测试，能省下大量时间；第一轮只测高优先级页面，把主路径的卡点先解决。

导航层级我一般压在两层以内。三层以上，被试在纸面测试里几乎必然迷路，而纸面原型迷路和真实产品迷路的原因往往不一样，前者是线索不够，后者是布局问题，混在一起分析会很乱。纸面测试找五个被试足够，方法是一张一张卡片给，让被试用手指出下一步点哪里，主试只记录不引导，第一下指错的位置就是卡点。

4.3 高保真原型与埋点：让原型自己记录过程

高保真阶段的重点不是好看，是能记录。下面这段是 Web 原型里用的埋点代码，把任务起止、点击、页面切换都写进浏览器本地存储，测试结束一键导出 CSV，不需要服务器。

// tracker.js —— 高保真原型埋点，数据存 localStorage，测试后导出 CSV const Tracker = (() => { const KEY = "hci_logs"; const sessionId = Math.random().toString(36).slice(2, 10); // 匿名会话号 let currentTask = null; let taskStart = 0; const push = (record) => { const logs = JSON.parse(localStorage.getItem(KEY) || "[]"); logs.push({ session: sessionId, ...record }); localStorage.setItem(KEY, JSON.stringify(logs)); }; return { // 主试点击开始，记录任务起点；performance.now 精度足够且不受校时影响 startTask(taskCode) { currentTask = taskCode; taskStart = performance.now(); push({ type: "task_start", task: taskCode, t: Date.now() }); }, click(targetId) { // targetId 用稳定标识，不要用按钮序号，改版后才对得上 push({ type: "click", task: currentTask, target: targetId, t: Date.now() }); }, endTask(success) { const duration = (performance.now() - taskStart) / 1000; push({ type: "task_end", task: currentTask, duration: +duration.toFixed(2), success: success ? 1 : 0, t: Date.now(), }); currentTask = null; }, // 测试结束后调用，把 JSON 转成 CSV 触发下载 exportCsv() { const logs = JSON.parse(localStorage.getItem(KEY) || "[]"); const header = "session,type,task,target,duration,success,t\n"; const rows = logs.map((l) => [l.session, l.type, l.task || "", l.target || "", l.duration ?? "", l.success ?? "", l.t].join(",") ).join("\n"); const url = URL.createObjectURL(new Blob([header + rows], { type: "text/csv" })); const a = document.createElement("a"); a.href = url; a.download = `logs_${sessionId}.csv`; a.click(); }, }; })();

几个参数的用意：sessionId每次页面加载生成一次，报告里用它对上被试编号，不出现姓名；performance.now()得到的是毫秒级单调时间，算时长比Date.now()稳；targetId必须是业务含义的稳定标识（如btn_share），不能是自动生成的序号，否则改版后历史日志无法对齐；success用 0/1 记录，是为了后面能直接求和算完成率。导出用 Blob 加<a download>，测试现场不依赖网络，这一点在实验室最实用。

提示：正式测试前用自己跑三遍全流程，确认每次点结束都能写进日志。埋点丢数据是最难补救的事故，事后没法重测同一批被试。

4.4 两轮迭代：改什么要有来源，改完要复测

迭代记录表是大实验里最能体现工程性的东西，比任何界面截图都有说服力。问题编号要能追到来源，严重度要有分级标准，改完必须有一列复测结果。

严重度分级我一般用四级：S1 是阻断主任务（做不下去），S2 是显著增加时长或错误，S3 是体验瑕疵但有替代路径，S4 是纯视觉问题。第一轮只改 S1 和 S2，S3 挑改动成本低的顺手做，S4 留到最后一轮。理由很实在：两轮迭代的窗口期通常只有两三周，什么都改等于什么都没验证清楚。

复测只测受影响的任务，不要整套重跑。比如 P-01 改了首页入口，就只重测 T2，其他任务在新版本上跑一遍确认没被改坏即可。报告里对比要写成"同一任务、不同版本"的形式，两组的中位数、完成率、错误次数并列，再给一句结论：改动解决了什么问题、还有没有遗留。这样的迭代记录，评审一看就知道你是按流程走的，不是事后编的。

5. 常见问题与排查：五个最容易翻车的地方

下面这五条是这门课里出现频率最高的翻车点，每一条都在答辩现场被追问过。我按"现象—原因—解决"写，方便对照自查。

5.1 报告写成操作流水账

现象是报告从"打开页面"写到"关闭页面"，每一步配一张截图，读完不知道结论是什么。原因是写作者把"我做了什么"当成了报告主体，而实验报告的主体是"数据说明了什么"，操作步骤只是让别人能复现的方法说明。解决办法是把每段都改成"证据 + 判断"的结构：贴完一组时长数据，紧跟一句这组数据支持或推翻了哪个假设，再跟一句由此发现的具体界面问题。截图数量砍掉一半，把省下的篇幅用来写分析和问题清单。判断标准很简单——随便删掉一段，如果删完结论不受影响，那段就是流水账。

5.2 被试全是同班同学，结论站不住

现象是五名被试里四个同专业、三个同宿舍，测试时互相已经见过原型。原因不是懒，是招募成本被低估了。同质样本会带来两个偏差：一是学习效应，前面的人用过，后面的人提前知道入口在哪；二是客气偏差，熟人不好意思说难用，评分普遍虚高。解决办法是定一条最低线：至少一半被试不能是设计者认识的人，招募时按"是否有同类产品使用经验"分层，测试前明确告知"测的是界面不是你，越挑刺越有价值"。如果实在只有同质样本，就在报告的局限性部分写清楚，并说明结论只在这个人群内成立，别硬推成普适结论。

5.3 改完版没复测，迭代成了自说自话

现象是报告里列了一堆改进，第二版截图很漂亮，但没有任何数据说明改完到底好了多少。原因通常是时间不够，或者觉得"改了肯定更好"。这个判断往往不成立，改动引入新问题的概率相当高，尤其是加了提示和状态之后，界面反而变吵。解决办法是把复测写进计划表而不是留到最后：第一轮测试结束当天就定复测范围（只测 S1、S2 涉及的任务），复测人数可以减到三人，只要能看出方向。报告里给出改前改后的同任务对比，哪怕样本小，也比没有数据强。

5.4 指标口径中途改，前后数据对不上

现象是 v1 的完成率 80%，v2 的完成率 60%，看起来变差了，实际是因为 v2 阶段把"提示后完成"从成功改成了失败。原因是口径没有在测试前固定，改着改着就忘了。解决办法是把指标定义写进方案首页，作为附录保留，后续任何调整都记一条变更说明，并注明"该变更仅影响第几轮之后的数据"。分析时宁可把两轮数据分开报，也不要把不同口径的数字放同一张图里比。这条经验在真实项目里同样成立，指标一旦开始漂移，整份报告的可信度就没了。

5.5 日志时间戳与任务编号错位，数据没法用

现象是导出 CSV 后发现任务编号全是空，或者时长出现负数、几万秒的异常值。常见原因有三个：任务开始时没有重置计时器，导致上一条任务的时长被累加；targetId用了会变的元素序号，改版后日志对不上；中途刷新页面，内存里的当前任务状态丢了而日志已经写进去了。解决办法是任务开始必须显式调用一次startTask，把当前任务和起始时间同时重置；标识统一用业务名而非位置序号；日志在每次写入后立即落盘到 localStorage，刷新后能续上。测试前用自己跑三遍全流程，检查导出的 CSV 里有没有空任务、异常时长，这一步花十分钟，能省掉事后无法补救的麻烦。

6. 验收与答辩：用一页指标表把"更好用"讲成证据

答辩时间通常只有八分钟，讲界面细节讲不完，也没人爱听。能拿到好反馈的讲法只有一种：先给结论，再给支撑结论的那张表。我一般会准备一页纸的汇总表，正反两面打印，讲的时候手上有东西指。

这张表的作用是把"我觉得更好用了"换成"六项指标里五项改善，一项持平"。讲解顺序建议按"结论—证据—代价"走：先说 v1 到 v2 主路径时长降了三成、完成率提了近二十个百分点；再挑一到两个具体改动说明因果，比如首页入口外露之后 T2 的时长从 96 秒掉到 61 秒；最后主动交代代价和局限，比如复测只有五人、SUS 分差不能当显著性讲、有一个 S3 问题没来得及改。主动说局限不会减分，被追问才承认才减分。

被问到"你怎么知道不是被试变熟练了"，标准答法是：两条任务路径做了顺序平衡，且 v2 复测只重跑受影响任务，前后间隔控制在一周内；同时坦率说明这是课程条件下的对照，不是严格实验设计。被问到"这个界面为什么这么排"，别答"因为好看"，答"纸面测试里三名被试在这个位置找不到入口，改到这里之后首步成功率达到 5/5"。所有回答都落回数据，答不上来的就说没测过、是下一轮要补的，这比现编一个理由安全得多。

还有个小技巧：把原始 CSV 和问卷一起放在附录里，答辩时如果有人质疑某个数字，直接翻到附录指出来。我带过的一次答辩里，评审随机挑了一个时长数据要求核对，当场翻到日志原始行，后面几个问题明显温和了很多。从那以后我每次交实验报告，都强制走一遍"数字能不能翻到原始记录"的自查，凡是翻不到出处的数字，要么补出处，要么删掉。希望这套结构帮到你，照着改改参数就能跑起来。

本文还有配套的精品资源，点击获取