人机交互课程实验全复盘：从Fitts定律到期末项目实战

简介面向人机交互课程的完整实验与项目资料包适合计算机、设计类本科生对照课程要求完成课内实验与期末综合大实验。包内含有多份实验报告如语音交互、界面设计等、配套PPT课件、VRML虚拟现实交互实验文件以及订单管理系统、飞机订票查询系统等界面设计文档覆盖用户研究、界面设计原则、可用性评估等核心知识点。资源共86个文件以bmp截图、Word/PPT文档、C源码及PDF说明为主另有WRL虚拟场景、可执行程序和压缩包整体约25MB目录结构清晰便于按实验模块查阅。已有2480人学习下载既能帮助理解人机交互理论也能直接借鉴实验报告格式、设计思路与代码实现其中的语音程序、BBS系统设计等实例尤其适合需要系统完成课内实验和综合大实验的学生。 人机交互这门课说穿了就是教你两件事怎么设计出用户愿意用、用得顺的界面以及怎么证明你的设计确实好用。我学期里一口气完成了五个小实验加一个期末大实验实验报告累计写了接近两万字踩过的坑比写过的代码还多。这篇不打算复读课本定义而是把整个课程项目的设计与实操流程完整复盘一遍目标用户是正在跟同类课程较劲、或者打算用一套完整实验报告加期末项目去拿高分的同学。无论你是技术背景还是设计背景这套流程都通用而且我最大的感受是老师更看重过程里的分析方法而不是原型有多花哨。1. 先看全局实验报告与大实验组成的训练体系1.1 课程实验设计的底层逻辑人机交互课程通常把考核拆成两块平时实验报告和期末大实验。很多人拿到任务就想着“赶紧做个App”但课程真正想训练的能力不是 UI 设计而是“以用户为中心”的评估思维。五个小实验恰好构成一个完整能力链条认知建模类实验Fitts定律、GOMS解决“设计的理论依据从哪来”启发式评估和认知走查解决“不找真人也能发现设计问题”可用性测试则解决“真人用了到底好不好用”的最终验证。这里要先想明白一件事实验报告不是实验过程的流水账。一套合格的实验报告本质上是一份“有假设、有数据、有结论”的实证文档。比如 Fitts 定律实验重点不在于你测了多少次点击而在于你能否用回归拟合出的系数解释按钮大小和间距的设计取舍。报告的价值恰恰体现在分析与结论而不是过程记录本身。这个观念一旦建立后面的所有实验报告都会好写很多因为你知道每份报告需要一个核心观点来串联。1.2 报告写作的核心套路我前半个学期都是拿到模板往里填数据后来发现那种写法分数一直在中游徘徊。后来总结出一个固定套路先交代实验目的和理论假设再说明实验设备、被试、材料、实验程序设计然后给出数据处理方法和结果图表最后做讨论与结论。看上去像学术论文的简化版但这就对了人机交互实验报告本质上就是一份小型实证论文。按这个结构写出来的报告逻辑不容易散老师批改时也容易抓到重点。在这个框架里有两个容易被忽视的部分特别加分。第一是“假设的提出”哪怕只是“较大按钮会显著缩短点击时间”这种明显假设也要明确写出来这能体现你是带着问题做实验而不是机械操作。第二是“讨论部分”要主动对异常数据给出解释比如某个被试的点击时间明显偏大可能是误操作或者注意力问题这种解释会显得你真正理解了实验而不是只会跑数据。1.3 工具清单我一路用什么搞定工具选对能省一半时间。我用到的东比较简单实验程序用纯 HTML JavaScript 自己写计时用 performance.now() 而不是 setTimeout精度有保障数据分析用 Python 的 scipy.stats.linregress 做回归图表用 matplotlib原型设计全程用 Figma免费、组件库多、还能直接做可点击交互问卷和 SUS 量表用问卷星收集后台直接导 Excel省去手动录入的错误。这套组合下来从基础实验到期末项目不需要额外购买任何付费工具。很多同学纠结“要不要学专业可用性测试设备”我的建议是眼动仪这类设备课程里有就体验一下没有也不影响你掌握核心方法。2. 五个基础实验逐一拆解操作要点与报告写法2.1 Fitts定律实验用鼠标点出回归曲线Fitts定律可以说是人机交互领域最著名的经验模型公式表达为 MT a b * log2(D/W 1)。D是目标距离W是目标宽度MT是平均点击时间。它的价值在于你可以提前估算一个操作需要多少时间从而设计出更符合人体运动特征的界面而不用等产品上线后再来优化。我的实验设计是这样屏幕上先出现一个起点圆用户点击起点后再随机出现目标圆。目标距离D取 100、200、400 像素三档目标宽度W取 20、40、80 像素三档两两组合成 9 个条件每个条件重复 20 次按随机顺序呈现逐条记录点击时间。总共 180 次点击跑完大约需要 15 分钟我在中间安排两次休息避免疲劳影响后续数据质量。数据处理核心是线性回归。把 log2(D/W 1) 作为自变量、平均点击时间作为因变量用 scipy.stats.linregress 拟合出 a 和 b 两个参数。我跑出来的一组典型结果是 MT 0.087 0.132 * IDR²接近 0.95说明 Fitts 定律在这套实验条件下拟合得很好。代码其实很短import numpy as np from scipy.stats import linregress # id_values: 每个条件的 index of difficulty # mt_values: 对应的平均点击时间秒 slope, intercept, r_value, _, _ linregress(id_values, mt_values) print(fMT {intercept:.3f} {slope:.3f} * ID, R² {r_value**2:.3f})这条公式不是摆设。我把它用来比较两个设计方案的效率假设“删除”按钮宽度从 24px 扩大到 40px用户鼠标移动距离固定为 200px那么操作时间约从 0.65 秒降到 0.55 秒。单次看只差 0.1 秒但如果是高频删除操作累计差异相当可观。这种从数据到设计含义的推演就是报告里最值钱的段落。实操有两个坑必须提醒第一浏览器普通定时器计时不准要用 performance.now()否则时间戳误差会被回归分析放大第二起点圆要固定在屏幕中央同一位置不然距离 D 根本不可控整个实验等于白做。我第一版程序就是因为起点随机分布数据出来乱成一团重测了一次才恢复正常。2.2 GOMS模型把界面操作拆成工厂流程图GOMS 是一种经典任务分析模型全称是 Goals、Operators、Methods、Selection rules。它把用户操作拆成最小“操作符”比如移动鼠标、击键、心理等待等再为每个操作符赋一个经验时长最后累加出任务预测时间。用一句话理解它就像工业工程里的动作分析只不过对象换成了界面操作。我选的实验任务是“新用户注册流程”。为了做对比我设计了两个版本A版本是传统表单页输入手机号、密码、验证码再点击注册B版本是极简版只输入手机号和验证码密码用手势绘制。GOMS 拆解下来A版本的预测时间约 26.8 秒B版本约 16.4 秒B明显更快。但这项实验的价值不只是“B赢了”而是你会被迫把每个步骤摊开来看。拆解过程中发现 A 版本里“阅读并同意用户协议”这一步没有明确反馈用户会多犹豫一两秒B版本里手势绘制步骤缺少容错提示误操作时用户可能反复绘制反而增加时间成本。写报告时建议把 GOMS 步骤表做成表格例如操作符动作描述估计时间(秒)累计时间(秒)移动鼠标从页面顶部移动到手机号输入框0.80.8击键输入11位手机号2.23.0点击切换到密码输入框0.53.5............报告里我特意强调 GOMS 适合比较两个方案的相对效率不适合评估用户主观感受和满意度不要把“用户觉得好看”这类结论硬塞进这个模型那是问卷和访谈该干的事。2.3 启发式评估让评估者按“准则清单”找茬启发式评估是一种不需要用户参与、由评估者依据 Nielsen 十条启发式准则逐条检查界面的方法。我给学校教务系统做了一次评估总共圈出 23 条问题按严重程度分级后有 4 条灾难性问题、7 条主要问题、9 条次要问题和 3 条小问题。最典型的灾难性问题是“表单提交失败后没有明显提示用户不知道自己是否提交成功”对应准则就是“系统状态可见性”。实操中最关键的一点是评估者必须独立工作评估过程中不要互相讨论。我第一次找两位同学一起评结果大家边评边聊找出的问题高度重叠还漏掉了不少明显缺陷。后来严格按流程来每名评估者先单独完成记录再汇总去重“问题覆盖率”立刻上来了。报告里除了问题清单还要写明严重程度评定标准。我沿用了 Nielsen 的 0-4 级量表0 表示非问题1 表示美观性问题2 表示次要可用性问题3 表示主要可用性问题4 表示可用性灾难。每一条问题都配了截图哪怕只是手机翻拍屏幕也比纯文字强太多。有一个细节很多人忽略启发式评估适合发现问题但不擅长验证问题是否真实存在。所以我的结论里明确写了“本评估发现的问题需在后续可用性测试中进一步验证”这样报告的逻辑闭环更完整也不会让人觉得结论过于绝对。2.4 认知走查扮演一个“什么都不懂”的用户认知走查和启发式评估一样不找真实用户但出发点不同它重点检查新手用户的学习成本。我评估的是图书馆座位预约系统的预约流程按照四个经典问题逐步检查用户是否知道当前目标用户能否在界面中直接找到对应操作操作之后用户能否感知到反馈用户能否理解反馈的含义走查时发现问题都藏在细节里。“常见问题”入口放在页面底部且颜色很淡新手用户基本不会注意到点击“确认预约”后只弹了一个提示框却没有说明人不到会怎样用户根本不清楚自己会不会被记违约。这些结论完全是从“新手视角”推出来的和启发式评估找到的问题并不完全重复两者正好互补。写报告时我把每次“走查步骤”写成表格字段包括步骤描述、用户心理过程、潜在问题、改进建议。用户心理过程写得越具体越加分比如“用户看到‘常见问题’字样时会以为这只是 FAQ 页而不是查询违约规则的入口”。这种表达体现的是真正的用户思维而不是开发者思维。实操心得只有一条走查时一定要刻意忘掉你已经知道的系统逻辑。顺畅的地方不用记卡住的地方全要写你愣住的每一秒背后都是一个潜在设计问题。2.5 可用性测试把实验室方法搬到真实场景可用性测试是整个课程里最接近真实科研的部分也是期末大实验的核心评估工具。小实验阶段我拿一个校园二手交易小程序练手找了 5 名同学当被试正好符合 Nielsen “5 个用户就能发现绝大多数问题”的经验法则。测试流程跑了一遍完整链路先签知情同意书和背景问卷给三分钟熟悉产品再依次完成三个任务每个任务记录完成时间、成功失败情况、困惑点和操作路径最后填 SUS 系统可用性量表并做简短访谈。全程用录屏软件加外置录音记录事后对照录像逐条整理行为时间线比现场手记精准很多。数据出来后照例做统计三个任务总体完成率 80%平均任务时间 62.5 秒SUS 得分 68.3刚好踩在“可接受”的及格线上。最关键的是我发现了一个规律完成失败的被试几乎都卡在“发布商品”的信息填写顺序上成功被试里也有两人绕了一圈才找到入口。如果不记录操作路径很难定位到这个具体步骤。这份实验报告里我特别强调“任务顺序做了随机化”目的是排除学习效应避免被试做完任务一后对界面更熟悉导致任务二数据虚高。这种严谨细节写进报告会明显提升整体印象分。3. 期末大实验自习室座位预约系统的完整实战3.1 选题与需求调研先确认真的有人疼期末大实验千万别做“自己想要的产品”要做“真实用户确实需要的东西”。我选了自习室座位预约系统原因很实际学校图书馆自习室常年抢座管理员和学生对“占座”问题抱怨已久这是一个真实、高频、范围可控的痛点场景非常适合在一学期里完成从需求到评估的完整闭环。需求调研我用了问卷加访谈的组合线上问卷回收 87 份线下访谈 6 位不同使用频率的学生。问卷主要摸清使用场景、频率和核心痛点访谈则用来追问“占座”的具体细节。调研结果凝聚成三个关键词查座难、预约慢、违约不透明。我又在此基础上做了用户画像以大二学生李明为主辅以研一用户和偶尔来馆的教师用户保证功能设计具备包容性。这里提醒一点访谈不是聊天要准备半结构化提纲。我按顺序问了三个问题你昨天在图书馆用座位的全过程是怎样的过程中最烦的三件事是什么如果只能保留一个功能你要什么第三个问题特别狠它直接逼出用户内心真正的核心诉求比“你觉得这个功能重要吗”这样的量表有效太多。3.2 原型设计的迭代路径从纸面到可点击需求明确后我没有直接开 Figma而是先用纸笔画了三版低保真线框图。第一版按“后台管理系统”的思维来画结果给同学看时被吐槽像教务网站第二版改成卡片式首页突出今日空闲座位和快捷预约第三版加入扫码签到和违约提醒等关键状态页。每一版都会请同学看十分钟让他们边看边说问题。纸面迭代虽然看起来原始但只花不到两天就避免了后期在高保真原型里推翻重做的巨大工作量。高保真原型我用 Figma 制作。整体走浅色主题主色定为蓝色 #2B6CB0正文 16px操作按钮最小高度 44px这是移动端触控的基本安全尺寸。组件直接借用社区流行的开源组件库再统一替换色板和字体。核心流程做好后我把五个关键页面串成了可点击原型首页、座位筛选列表、预约确认页、扫码签到页、个人信息与违约记录页。这个阶段最实用的经验是不要一上来做全部门先把“预约今晚 18:00-20:00 座位”这条主路径做到闭环再补分支功能。我第一版原型就是贪多导航栏塞了七个入口结果被试反而找不到主功能。后来砍到四个主入口保留预约、签到、记录、我的任务完成率立刻上升。3.3 评估实验用6个用户找到12个问题高保真原型完成后我按小实验学到的方法正式做了一次可用性测试。被试招募 6 人覆盖三类用户2 名重度自习用户、2 名中度用户、2 名基本没用过预约系统的新手。正式测试包含三个任务预约明天上午 9 点到 11 点三层靠窗座位到馆后完成扫码签到查看一条违约提醒并处理。测试环境用的是原型链接加录屏避免线下设备差异干扰数据。结果统计下来任务一完成率 100%平均耗时约 41 秒任务二只有 4 人顺利完成另外两人在首页找不到签到入口任务三完成率 100%但平均耗时明显偏长因为用户要进“我的-违约记录”才能看到提醒入口。SUS 平均得分 74.2比小实验的 68.3 乐观但问题清单上 12 个问题仍然集中在导航可发现性上。根据数据我把“签到”和“违约提醒”入口都提升到首页核心功能区增加一个“今日待办”卡片直接展示待签到预约和未读提醒。用一句话概括把高频动作放到用户视线和拇指最容易到达的位置。改完后我让之前两位失败用户重测了一遍两人均顺利完成任务平均时间缩短约 30%。迭代前后的数据对比是整个期末大实验报告里最有说服力的段落。没有这个对照你只能空口说“我改进了”有了数据整个设计决策就能立住。4. 常见问题排查与评分加分技巧4.1 报告写作中容易翻车的地方我改过同学的实验报告也回头检查过自己前期的报告翻车点集中在三类。第一类是把实验报告写成操作说明书事无巨细写怎么点按钮却缺失假设和结论第二类是数据堆砌把原始记录整段粘贴却不画直方图、散点图和误差线老师根本看不下去第三类是结论过度明明只有 5 个用户样本却写成“这说明所有人都喜欢这个设计”学术上站不住脚必然扣分。报告里的表格不是装饰品。每次涉及对比数据我都会用表格把两个方案的完成率、平均时间、错误次数、SUS 分值并列展示一张好的对比表胜过三段文字。提交前对照一个自查清单是否有明确假设、是否有原始数据和数据处理过程、结果是否有图表、讨论是否解释了异常点、结论是否局限在样本范围内。这个清单用下来每次至少能保住 15% 的印象分。4.2 现场实验与演示的临场处理期末大实验通常要上台演示最常见的翻车姿势是现场操作高保真原型时点到错误状态页面转半天没有响应。我的处理办法是提前录制一段操作视频时长控制在 90 秒以内放在演示 PPT 第一页讲完背景和需求后直接播放视频里只走三条主路径画面流畅、节奏紧凑基本不会出幺蛾子。另一个临场原则是现场真实用户测试环节绝对不能给提示。我发现很多同学看到被试卡住就忍不住说“你点这里”“从这里进”测试结果直接报废。正确做法是记录被卡位置继续观察等全部任务结束再统一提问。如果被试实在无法完成允许其跳过并标记为“用户放弃”这本身就是一个非常有价值的有效数据。现场答辩时还有一个技巧准备一页“迭代对比”图左边放改进前截图和失败率右边放改进后截图和提升数据。先承认产品有问题再讲怎么用数据驱动改进这种讲法比从头到尾吹产品多好用要高明得多。4.3 加分项让老师和同学一眼看到专业度最后说几个不费力但很加分的细节。第一实验材料要齐全。知情同意书、背景问卷、任务脚本、SUS 量表、原始数据处理脚本统一打包放在一个项目文件夹里。即使老师不打开这份完备感也会在评分时产生影响。第二图表规范。散点图要有横纵轴标签和单位柱状图要有误差线字体统一用无衬线体线宽不低于 1.5 像素。学术审美的本质是简洁、清晰、不花哨和做 PPT 一个道理。第三开放数据脚本。我把自己用 Jupyter Notebook 做回归分析和 SUS 计算的完整代码放在报告附录每行都写了注释。课程不要求交代码但主动展示分析过程的人会被默认更严谨这个隐性印象分很值。回头再看这门课我最深的体会是人机交互实验报告和期末大实验的真正价值不是做出一个能运行的页面而是逼着你建立一套“用户行为可以观察、可以测量、可以改进”的方法论。小实验练的是各项分析工具大实验练的是完整流程二者叠加之后哪怕未来不做交互设计在任何产品决策面前我都会下意识先问一句“用户会怎么看待这件事”。还有一个保留到现在的习惯所有设计上线前我一定找至少两位从没见过这个功能的新用户跑一遍主流程看他们卡在哪个环节这比我坐在电脑前自己预想问题要准确得多。这个习惯就是这门课留给我的最大财富。本文还有配套的精品资源点击获取