简介面向高校人机交互课程学习者与期末项目完成者这套实验资料围绕二维交互画图板、语音交互、界面设计与VRML虚拟现实四组实验展开并配套综合性大实验帮助读者完成从需求分析、界面布局、原型制作到用户测试的完整训练。包内共86个文件约24.97MB含6份doc实验报告、5份ppt课件、5组cpp与h源码及obj/pdb等编译中间文件、22张bmp界面素材、2份pdf教程和2个wrl虚拟现实场景另有语音SDK参考文档与TTS示例便于对照实验步骤复现并做二次修改。已有2487人学习。资料覆盖订单管理、BBS、飞机订票查询等界面设计案例也提供VRML入门教程与示例场景读者可参考报告结构、评估思路、源码组织与原型实现方式适合课程实验提交、大作业选题以及交互设计方案复盘。1. 一张人机交互的知识地图实验报告和最后大实验其实是同一条链很多人把人机交互的实验报告和最后大实验当成两件事前者是写文档后者是做原型。实际上它们位于同一条链的两个位置一条为「人—任务—界面」的认知线关注用户怎么感知、决策、出错另一条为「设计—原型—评估—迭代」的工程线关注界面如何被改到能用。实验报告是把这条链上某一次观测写成可复现的证据大实验是把整条链走一遍并留下修改痕迹。这份材料适合两类人期末要交报告、要答辩的以及正在复习、需要把零散概念连成网的人。地图先记住一句话所有实验设计都在回答「我改了什么、我测了什么、别的变量控住了没有」所有评估方法都在回答「谁在什么任务上卡住了、卡得多严重」。2. 实验报告的骨架假设、变量、数据表三件套实验报告写得像流水账多半是在动笔时才开始想「我要证明什么」。真正决定分数的部分在动手做实验之前就已定型一句可检验的假设、一张变量对照表、一份不用返工的数据表结构。这三样定死后面的统计和讨论只是顺着往下推。2.1 八段式结构里哪几段真正决定分数课程报告的段落顺序基本固定但评分点分布极不均匀。下面这张表把每段「必须回答的问题」和最常见的缺失列在一起写之前先对照看一遍。| 段落 | 必须回答的问题 | 最常见缺失 | | 引言 | 要验证什么、为什么值得验证 | 只有背景铺陈没有可检验的假设 | | 方法 | 别人照着写的内容能不能复现 | 缺指导语原文、缺条件顺序安排 | | 结果 | 数据长什么样、差异是否稳健 | 只放图不放描述统计无效应量 | | 讨论 | 结果支持还是推翻了假设 | 把局限写成客套话不解释异常数据 | | 结论 | 一句话能带走什么 | 重复结果段没有收敛到设计建议 |假设的写法有个硬标准可检验、有方向、带指标。「布局 A 更好用」不是假设是口号「布局 A 的任务完成时间显著短于布局 B且错误率不高于 B」才是假设——它规定了比较对象、指标和方向也提前堵死了事后挑数据的路。方法段最容易失分的地方是「指导语」。被试听到的每一句话都会影响行为所以指导语要原文照录包括你怎么解释任务、允不允许提问、有没有告诉被试可以随时终止。这部分写全了报告立刻从「学生作业」变成「可复现的实验」。2.2 自变量、因变量、控制变量一张表定死变量定不清后面所有统计都是白算。做界面实验时把这几类变量摊在一张表上比在脑子里过一遍可靠得多。| 变量类型 | 具体例子 | 记录方式 | | 自变量 | 布局方案A/B、目标尺寸三档、菜单广度4/8/16 | 条件编号写进每一行数据 | | 因变量 | 完成时间、错误率、点击次数、量表得分 | 每次试验一行不合并 | | 控制变量 | 屏幕分辨率、指针速度、字号、任务内容 | 固定值写进方法段 | | 混淆变量 | 学习效应、疲劳、练习量、被试间能力差异 | 用平衡顺序和练习试次压住 |表里最容易被忽略的是最后一行。混淆变量不会因为你没写就不存在它只会悄悄混进结果里让你在讨论段写不出一句有底气的话。控制它的手段无非三种随机化条件顺序、用拉丁方做平衡、每个条件前加固定轮数的练习试次并把练习数据剔除。还有一个常被忽略的区分被试内设计和被试间设计。同一批人做所有条件叫被试内样本效率高但必须平衡顺序不同人分到不同条件叫被试间没有顺序问题但个体差异会变成噪声。课程实验里九成用的是被试内而九成的翻车也都出在忘了平衡。2.3 数据表怎么设计才不用返工数据表的格式在实验开始前就该定下来因为一旦开始录数据改表头等于重做。推荐用「长表」一行一次试验所有条件混在一列里用字段区分。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只有每个条件结束时填一次其余行留空。为什么不推荐宽表每个条件一列因为条件数一旦变动就得改表头而且缺数据会变成空格统计时很难区分「没测」和「测了为 0」。长表还有个好处能直接接分组聚合。import pandas as pd # 一行一次试验的长表先聚合到「被试 × 条件」再进统计检验 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 值必然漂亮——这是整个方向里最典型的踩坑方式之一而且很难在结果段自查出来。参数上要注意unstack()之后行是被试、列是条件配对检验要求两列长度一致缺数据的被试要么整行剔除要么在报告里说明处理方式。3. 经典实验范式菲茨定律、希克定律与布局对比课程实验报告里出现频率最高的三类题目本质是三种不同的测量对象菲茨定律测「指向动作的难度」希克定律测「选项数量带来的决策成本」布局对比测「整体方案在真实任务下的绩效」。前两个是可控的经典范式第三个是把前两个的指标组合起来做一个综合判断。3.1 菲茨定律实验ID、MT、TP 三个量怎么算菲茨定律描述的是「从起点移动到目标并点击」这件事有多难。核心量是难度指数 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): 难度指数 ID单位 bit。 distance_px起点到目标中心的距离 width_px目标沿运动方向上的尺寸横排按钮量宽竖排量高 if distance_px 0 or width_px 0: raise ValueError(距离和目标宽度都必须为正数) 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)参数上有三个坑值得单独说。第一距离和目标宽度的单位必须统一都用像素或都用毫米混着算出来的 ID 没有意义。第二W 取的是「沿运动方向」的尺寸一排横向排列的按钮量的是宽度一列纵向排列的菜单项量的是高度。取错了ID 会系统性偏大或偏小。第三2D/W 必须大于 1否则 ID 为负或为零说明这个任务对用户毫无难度测出来的时间只是在测手抖。一般把 ID 设计在 1 到 7 bit 之间覆盖「很容易」到「需要专注」的区间。throughput函数里那句注释是本节的真正重点。很多人先算所有条件的平均 ID 和平均 MT再一除得到 TP这在数学上不等于「各自算再平均」条件之间难度差异越大两者偏得越远。答辩被问到这一句答不上来基本就露馅了。3.2 希克定律与菜单选择选项数量不是线性成本希克定律讲的是决策时间随选项数量的增长方式选项越多决策越慢但增长是对数的不是线性的。常见形式是 RT a b·log2(n 1)n 是等概率选项数。这条定律最常被用在菜单设计的争论上一个大而扁的菜单还是几个小而深的层级纯按公式推似乎宽而扁更优因为多一层就要多一次决策。但真实界面里选项不是同时可见的用户还得做视觉扫描和寻找所以纯希克定律只适用于「所有选项同时呈现、位置随机、彼此无视觉层级差异」的场景。设计这类实验时把「决策时间」和「视觉搜索时间」分开记录会更严谨可以用两种条件一种是选项位置固定熟手靠位置记忆一种是每次随机必须逐个读两者的差值就近似视觉搜索的贡献。这个设计思路写进讨论段比单纯复述公式有分量得多。3.3 布局对比实验把「感觉更好用」变成可测的数布局对比是最后大实验里最常见的题目形态也是最容易做成主观感想的一类。要让它站得住指标要提前定且至少覆盖绩效和主观两侧。| 指标 | 采集方式 | 需要提前定死的事 | | 任务完成时间 | 从首次点击到目标达成 | 起点和终点的判定规则 | | 错误率 | 错误点击数 / 总点击数 | 什么算错误误点后算不算重来 | | 操作步数 | 完成任务经过的界面数 | 返回算不算一步 | | 指针移动距离 | 采样点累加 | 采样率会影响结果需固定 | | 主观负荷 | 六维度负荷量表测试后立即填 | 填表时机要统一 | | 偏好排序 | 两方案二选一或排序 | 偏好不能替代绩效数据 |设计上建议每个条件至少十次有效试验前面加固定轮数的练习并把练习数据剔除条件顺序用拉丁方平衡避免所有人都是先做 A 后做 B——先做的那个一定吃亏因为界面还不熟。这个「吃亏」在数据上表现为 A 的完成时间系统性偏长而你很可能把它解释成「A 的设计更差」这就是典型的把混淆变量当结论。4. 评估与迭代三种评估方法和最后大实验的完整链路原型做出来只是开始能不能毕业看的是评估。三种方法的分工很明确启发式评估靠专家经验快速扫雷成本最低认知走查靠逐步推演不需要真实用户适合极早期可用性测试靠真实用户做真实任务最贵也最有说服力。三者不是替代关系是按阶段递进的关系。4.1 启发式评估十条原则怎么变成问题清单十条原则背下来不难难的是把它们变成一条条能落到具体界面上的检查问句。下面这版对照表是按「问句化」整理的走查时逐条念出声即可。| 原则 | 检查问句 | 典型问题 | | 状态可见 | 系统现在在做什么用户一秒内能看出来吗 | 保存无反馈、加载无进度提示 | | 贴合现实 | 用词是不是用户自己的语言 | 出现内部代号、字段名、缩写 | | 用户可控 | 误操作能不能撤回 | 删除无二次确认、无撤销入口 | | 一致性 | 同一个动作在不同页面是不是同一个说法 | 「确定/保存/提交」混用 | | 错误预防 | 能不能在出错之前拦住 | 日期让用户自由文本输入 | | 识别优于回忆 | 需要的选项是不是摆在眼前 | 要用户记住上一步的编号 | | 灵活高效 | 有没有给熟手留一条捷径 | 只能一步一步点无批量操作 | | 极简设计 | 屏幕上有没有和当前任务无关的元素 | 装饰图表挤占主操作区域 | | 错误恢复 | 报错有没有说清原因和下一步 | 「操作失败请重试」 | | 帮助文档 | 帮助是不是出现在用户需要的位置 | 帮助入口埋在三级菜单里 |流程比表格更重要。正确做法是三到五名评估者各自独立走查、各自列问题然后才合并去重先讨论再走查会迅速收敛到同一种视角问题数量直接砍半。合并之后按「出现频率 × 严重程度」分级严重度可以用四级一级是外观瑕疵二级是轻微不便三级是阻碍任务完成四级是可能导致数据丢失或误操作。最后输出一张问题表每行写明位置、触犯的原则、严重度、修改建议——这张表就是大实验迭代阶段的输入。4.2 认知走查四个问题逐屏过一遍认知走查不需要用户靠的是评估者把自己代入一个具体用户沿着一条具体任务逐屏问四个问题用户会不会尝试达成这个效果界面提供的操作和用户的目标对不对得上用户能不能注意到正确的操作是可用的可见性够不够用户会不会把这个操作和想达成的效果联系起来映射清不清楚执行之后用户能不能看出操作已经生效有没有反馈四问的顺序不能乱因为它对应的是「形成目标—寻找操作—建立映射—评估结果」这条认知链。任何一问卡住都记一个设计缺口并注明是「通过 / 失败 / 存疑」。存疑不要强行判通过标记出来留到可用性测试里验证。这套方法最适合低保真阶段纸面原型上做认知走查改一笔成本几乎为零等到高保真做完再走查改一个交互可能牵动整条流程。带血泪经验的一条是走查时一定要挑「第一次使用」的用户视角而不是「已经用了三天」的自己。4.3 可用性测试任务脚本、发声思考与量表计分可用性测试最容易做错的地方不在数据分析在任务脚本。脚本写的是目标不是步骤。看下面这一组对比反例点击右上角的设置图标然后选择通知选项把开关关掉。 正例假设你不想再收到这类提醒了请把提醒关掉。反例里每一步都写明了位置和操作测的其实是「用户能不能照着指令点」测不出任何可用性问题。正例只给目标用户怎么找到入口、会不会迷路、会不会点错才是要观察的东西。主持人全程只说两句话「你现在在想什么」和「继续」。任何一次「你可以试试左边那个」都会让这一轮数据作废。样本量上有个常用的经验值同一类用户群、同一类任务五名被试大约能暴露大部分约八成以上的可用性问题。这个数字经常被误用成「五个人就够了」——它成立的前提是用户群单一、任务类型集中。如果你的产品有两类差异很大的用户五个人分摊到两类里就不够了。主观量表最常用的是十题版的系统可用性量表。这十题里有一半是正向描述、一半是反向描述计分时必须反向翻转这一步是重灾区def sus_score(responses): 十题系统可用性量表计分。 responses长度为 10 的列表每题原始分 1~5。 奇数题1/3/5/7/9正向贡献 原始分 - 1 偶数题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 区间。这里有个必须说清的点这个分数不是百分比不能说「可用性 80%」。它只是一个约定区间的分数业界常拿 68 分当平均参考线八十分以上算比较顺但样本量只有五个人时单看均值意义有限更该看的是每个人在哪几题上给了低分——那几题指向的才是具体问题。4.4 最后大实验的六步链路每一步的产出和验收标准大实验失分往往不是因为做得少而是因为阶段之间没有咬合原型做得很漂亮但需求说不清来自哪里测试做了一堆但改了什么没有记录。把六步的产出和验收标准列清楚进度和成文都会轻松很多。| 阶段 | 主要产出 | 判定通过的标准 | | 选题 | 一句话问题陈述 目标用户描述 | 能说清「谁在什么场景下被什么卡住」 | | 用户研究 | 三到五份访谈记录、需求清单 | 每条需求都能追溯到某条原始记录 | | 任务分析 | 层次任务分析表或用户旅程图 | 每个任务有明确起点和终点 | | 低保真 | 纸面或线框原型 | 认知走查无三级以上缺口 | | 高保真 | 可点击原型 | 主流程能独立走通五人测完 | | 迭代与成文 | 问题清单、修改对照表、报告 | 每个问题都有处理结论 |两点取舍经验。一是别在高保真上过度投入视觉精细度和可用性没有必然关系把时间花在第二轮测试上收益更高。二是迭代记录要做成「问题—修改—验证」三列而不是只写「已优化」答辩时被追问「你怎么知道改好了」能翻出第三列的人立刻占优。5. 易漏易错点五个让报告掉档的细节5.1 条件顺序没平衡学习效应冒充了设计差异易漏点被试内设计里所有被试都按「先 A 后 B」的顺序做结果 A 的完成时间偏长报告写成「A 方案更难用」。为什么漏数据本身没有异常两组均值确实差着统计检验也显著从数字上完全看不出问题。学习效应藏在顺序里不做平衡就永远暴露不出来。怎么补一半被试走 A→B另一半走 B→A也就是最基础的拉丁方平衡每个条件前加固定轮数的练习试次并剔除练习数据分析时把「顺序」当成一个额外因素看一眼如果顺序的主效应很大说明平衡没做好得在讨论段如实说明。5.2 量表反向题没翻转分数全反了易漏点十题量表里反向题直接按原始分累加算出来的分数看着像模像样方向和真实感受相反。为什么漏正向题和反向题混排录入时逐行敲数字很容易一路顺着敲下去而且错误结果仍然落在合理区间内不会报错、不会越界属于典型的黑匣子错误。怎么补把计分写成函数参考 4.3 的实现奇数题减一、偶数题用五减输入前先断言范围录完随机抽两三份手工复算一遍对不上就整批重来。这一步花五分钟能省掉答辩现场被要求现场重算的尴尬。5.3 任务脚本里藏了操作提示测试变成了教学易漏点脚本写「点击右上角设置选择通知关闭开关」用户顺利完成成功率 100%报告写「界面易于使用」。为什么漏脚本读起来非常自然像是正常的任务描述写的人自己意识不到已经把所有决策都替用户做完了。而且成功率漂亮没人会去质疑。怎么补写完脚本做一次自查——把脚本里所有方位词和控件名划掉看剩下的句子还能不能构成一个完整目标。不能就重写。测试时主持人只记录不提示用户问「是不是点这里」回一句「你觉得呢」即可。5.4 只报 p 值不报效应量和样本处理易漏点结果段写「p 0.05差异显著」然后直接下结论说方案 A 明显更好。为什么漏显著性检验是最容易出结果的一步软件一点就有数字而效应量、置信区间、异常值处理这些「不显著但重要」的东西教材上往往一笔带过。怎么补每个主要比较都配一个效应量并在方法段写清样本量、剔除标准和剔除数量。样本量只有八到十人的课程实验里p 值本身很不稳定多报一个效应量能让结论的可信度上一个大台阶。顺便说前文提到的「拿几百行 trial 直接做检验」也是同一类问题的变体——先把数据聚合到被试层面再谈显著性。5.5 原型做太早太细来不及迭代易漏点第二周就开始抠高保真细节到测试阶段只剩三天测出来的问题一个都改不完报告里只能写「后续可优化」。为什么漏做界面比想需求有成就感工具又顺手很容易一头扎进去。等到发现方向错了沉没成本已经很大改不动了。怎么补把「低保真通过认知走查」设成硬门槛没通过不许进高保真高保真只做能走通主流程的最小集合装饰性内容留到最后。测试排期往前挪至少留出两轮修改时间——第一轮改大问题第二轮验证改得对不对这个节奏比任何视觉细节都值钱。6. 复习清单交稿前把报告倒着读一遍复习这个方向最有效的方式不是重看教材而是拿自己那份报告做一次逆向检查。下面这张自查表按「最容易忘」到「最不容易忘」排序交稿前从上往下过一遍。| 序号 | 检查项 | 不合格的表现 | | 1 | 假设有方向、有指标 | 只有「更好用」这类描述 | | 2 | 指导语原文完整 | 方法段只有「被试按指示完成任务」 | | 3 | 条件顺序已平衡 | 所有人顺序一致报告不提顺序 | | 4 | 数据已聚合到被试层面 | 直接用 trial 行数当样本量 | | 5 | 量表反向题已翻转 | 没有计分函数手工敲的数字 | | 6 | 每个比较都有效应量 | 只有 p 值 | | 7 | 剔除标准写清 | 只说「剔除异常值」不说怎么判 | | 8 | 任务脚本无操作提示 | 脚本里出现方位词和控件名 | | 9 | 问题清单有严重度分级 | 一长串问题不做优先级 | | 10 | 迭代记录有「验证」列 | 只写「已优化」 | | 11 | 局限段解释异常数据 | 局限写成「样本量较小」一句带过 | | 12 | 图表有单位和误差线 | 只有均值柱无离散程度 |然后试一个倒读技巧从结论段往回读每读到一句判断就往前找支撑它的那个数字。读三遍基本能揪出所有「结论跑在数据前面」的句子——这是评审最容易抓住、也最难辩解的一类问题。倒读还有个副作用会让你发现某些图其实可以删掉因为它们不支撑任何一句结论。最后说一个习惯。从那以后我每次做完实验都会在收数据当天就把长表按「被试 × 条件」聚合一遍看一眼极值和缺失再决定要不要补测等写完报告再回头看数据往往已经来不及补了。这个动作花不到十分钟但它把「数据能不能用」这个问题提前到了还能补救的时候。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/25 15:29:42 · 阅读 1.2k 从菲茨定律到可用性测试：人机交互实验报告与原型迭代
简介面向高校人机交互课程学习者与期末项目完成者这套实验资料围绕二维交互画图板、语音交互、界面设计与VRML虚拟现实四组实验展开并配套综合性大实验帮助读者完成从需求分析、界面布局、原型制作到用户测试的完整训练。包内共86个文件约24.97MB含6份doc实验报告、5份ppt课件、5组cpp与h源码及obj/pdb等编译中间文件、22张bmp界面素材、2份pdf教程和2个wrl虚拟现实场景另有语音SDK参考文档与TTS示例便于对照实验步骤复现并做二次修改。已有2487人学习。资料覆盖订单管理、BBS、飞机订票查询等界面设计案例也提供VRML入门教程与示例场景读者可参考报告结构、评估思路、源码组织与原型实现方式适合课程实验提交、大作业选题以及交互设计方案复盘。1. 一张人机交互的知识地图实验报告和最后大实验其实是同一条链很多人把人机交互的实验报告和最后大实验当成两件事前者是写文档后者是做原型。实际上它们位于同一条链的两个位置一条为「人—任务—界面」的认知线关注用户怎么感知、决策、出错另一条为「设计—原型—评估—迭代」的工程线关注界面如何被改到能用。实验报告是把这条链上某一次观测写成可复现的证据大实验是把整条链走一遍并留下修改痕迹。这份材料适合两类人期末要交报告、要答辩的以及正在复习、需要把零散概念连成网的人。地图先记住一句话所有实验设计都在回答「我改了什么、我测了什么、别的变量控住了没有」所有评估方法都在回答「谁在什么任务上卡住了、卡得多严重」。2. 实验报告的骨架假设、变量、数据表三件套实验报告写得像流水账多半是在动笔时才开始想「我要证明什么」。真正决定分数的部分在动手做实验之前就已定型一句可检验的假设、一张变量对照表、一份不用返工的数据表结构。这三样定死后面的统计和讨论只是顺着往下推。2.1 八段式结构里哪几段真正决定分数课程报告的段落顺序基本固定但评分点分布极不均匀。下面这张表把每段「必须回答的问题」和最常见的缺失列在一起写之前先对照看一遍。| 段落 | 必须回答的问题 | 最常见缺失 | | 引言 | 要验证什么、为什么值得验证 | 只有背景铺陈没有可检验的假设 | | 方法 | 别人照着写的内容能不能复现 | 缺指导语原文、缺条件顺序安排 | | 结果 | 数据长什么样、差异是否稳健 | 只放图不放描述统计无效应量 | | 讨论 | 结果支持还是推翻了假设 | 把局限写成客套话不解释异常数据 | | 结论 | 一句话能带走什么 | 重复结果段没有收敛到设计建议 |假设的写法有个硬标准可检验、有方向、带指标。「布局 A 更好用」不是假设是口号「布局 A 的任务完成时间显著短于布局 B且错误率不高于 B」才是假设——它规定了比较对象、指标和方向也提前堵死了事后挑数据的路。方法段最容易失分的地方是「指导语」。被试听到的每一句话都会影响行为所以指导语要原文照录包括你怎么解释任务、允不允许提问、有没有告诉被试可以随时终止。这部分写全了报告立刻从「学生作业」变成「可复现的实验」。2.2 自变量、因变量、控制变量一张表定死变量定不清后面所有统计都是白算。做界面实验时把这几类变量摊在一张表上比在脑子里过一遍可靠得多。| 变量类型 | 具体例子 | 记录方式 | | 自变量 | 布局方案A/B、目标尺寸三档、菜单广度4/8/16 | 条件编号写进每一行数据 | | 因变量 | 完成时间、错误率、点击次数、量表得分 | 每次试验一行不合并 | | 控制变量 | 屏幕分辨率、指针速度、字号、任务内容 | 固定值写进方法段 | | 混淆变量 | 学习效应、疲劳、练习量、被试间能力差异 | 用平衡顺序和练习试次压住 |表里最容易被忽略的是最后一行。混淆变量不会因为你没写就不存在它只会悄悄混进结果里让你在讨论段写不出一句有底气的话。控制它的手段无非三种随机化条件顺序、用拉丁方做平衡、每个条件前加固定轮数的练习试次并把练习数据剔除。还有一个常被忽略的区分被试内设计和被试间设计。同一批人做所有条件叫被试内样本效率高但必须平衡顺序不同人分到不同条件叫被试间没有顺序问题但个体差异会变成噪声。课程实验里九成用的是被试内而九成的翻车也都出在忘了平衡。2.3 数据表怎么设计才不用返工数据表的格式在实验开始前就该定下来因为一旦开始录数据改表头等于重做。推荐用「长表」一行一次试验所有条件混在一列里用字段区分。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只有每个条件结束时填一次其余行留空。为什么不推荐宽表每个条件一列因为条件数一旦变动就得改表头而且缺数据会变成空格统计时很难区分「没测」和「测了为 0」。长表还有个好处能直接接分组聚合。import pandas as pd # 一行一次试验的长表先聚合到「被试 × 条件」再进统计检验 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 值必然漂亮——这是整个方向里最典型的踩坑方式之一而且很难在结果段自查出来。参数上要注意unstack()之后行是被试、列是条件配对检验要求两列长度一致缺数据的被试要么整行剔除要么在报告里说明处理方式。3. 经典实验范式菲茨定律、希克定律与布局对比课程实验报告里出现频率最高的三类题目本质是三种不同的测量对象菲茨定律测「指向动作的难度」希克定律测「选项数量带来的决策成本」布局对比测「整体方案在真实任务下的绩效」。前两个是可控的经典范式第三个是把前两个的指标组合起来做一个综合判断。3.1 菲茨定律实验ID、MT、TP 三个量怎么算菲茨定律描述的是「从起点移动到目标并点击」这件事有多难。核心量是难度指数 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): 难度指数 ID单位 bit。 distance_px起点到目标中心的距离 width_px目标沿运动方向上的尺寸横排按钮量宽竖排量高 if distance_px 0 or width_px 0: raise ValueError(距离和目标宽度都必须为正数) 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)参数上有三个坑值得单独说。第一距离和目标宽度的单位必须统一都用像素或都用毫米混着算出来的 ID 没有意义。第二W 取的是「沿运动方向」的尺寸一排横向排列的按钮量的是宽度一列纵向排列的菜单项量的是高度。取错了ID 会系统性偏大或偏小。第三2D/W 必须大于 1否则 ID 为负或为零说明这个任务对用户毫无难度测出来的时间只是在测手抖。一般把 ID 设计在 1 到 7 bit 之间覆盖「很容易」到「需要专注」的区间。throughput函数里那句注释是本节的真正重点。很多人先算所有条件的平均 ID 和平均 MT再一除得到 TP这在数学上不等于「各自算再平均」条件之间难度差异越大两者偏得越远。答辩被问到这一句答不上来基本就露馅了。3.2 希克定律与菜单选择选项数量不是线性成本希克定律讲的是决策时间随选项数量的增长方式选项越多决策越慢但增长是对数的不是线性的。常见形式是 RT a b·log2(n 1)n 是等概率选项数。这条定律最常被用在菜单设计的争论上一个大而扁的菜单还是几个小而深的层级纯按公式推似乎宽而扁更优因为多一层就要多一次决策。但真实界面里选项不是同时可见的用户还得做视觉扫描和寻找所以纯希克定律只适用于「所有选项同时呈现、位置随机、彼此无视觉层级差异」的场景。设计这类实验时把「决策时间」和「视觉搜索时间」分开记录会更严谨可以用两种条件一种是选项位置固定熟手靠位置记忆一种是每次随机必须逐个读两者的差值就近似视觉搜索的贡献。这个设计思路写进讨论段比单纯复述公式有分量得多。3.3 布局对比实验把「感觉更好用」变成可测的数布局对比是最后大实验里最常见的题目形态也是最容易做成主观感想的一类。要让它站得住指标要提前定且至少覆盖绩效和主观两侧。| 指标 | 采集方式 | 需要提前定死的事 | | 任务完成时间 | 从首次点击到目标达成 | 起点和终点的判定规则 | | 错误率 | 错误点击数 / 总点击数 | 什么算错误误点后算不算重来 | | 操作步数 | 完成任务经过的界面数 | 返回算不算一步 | | 指针移动距离 | 采样点累加 | 采样率会影响结果需固定 | | 主观负荷 | 六维度负荷量表测试后立即填 | 填表时机要统一 | | 偏好排序 | 两方案二选一或排序 | 偏好不能替代绩效数据 |设计上建议每个条件至少十次有效试验前面加固定轮数的练习并把练习数据剔除条件顺序用拉丁方平衡避免所有人都是先做 A 后做 B——先做的那个一定吃亏因为界面还不熟。这个「吃亏」在数据上表现为 A 的完成时间系统性偏长而你很可能把它解释成「A 的设计更差」这就是典型的把混淆变量当结论。4. 评估与迭代三种评估方法和最后大实验的完整链路原型做出来只是开始能不能毕业看的是评估。三种方法的分工很明确启发式评估靠专家经验快速扫雷成本最低认知走查靠逐步推演不需要真实用户适合极早期可用性测试靠真实用户做真实任务最贵也最有说服力。三者不是替代关系是按阶段递进的关系。4.1 启发式评估十条原则怎么变成问题清单十条原则背下来不难难的是把它们变成一条条能落到具体界面上的检查问句。下面这版对照表是按「问句化」整理的走查时逐条念出声即可。| 原则 | 检查问句 | 典型问题 | | 状态可见 | 系统现在在做什么用户一秒内能看出来吗 | 保存无反馈、加载无进度提示 | | 贴合现实 | 用词是不是用户自己的语言 | 出现内部代号、字段名、缩写 | | 用户可控 | 误操作能不能撤回 | 删除无二次确认、无撤销入口 | | 一致性 | 同一个动作在不同页面是不是同一个说法 | 「确定/保存/提交」混用 | | 错误预防 | 能不能在出错之前拦住 | 日期让用户自由文本输入 | | 识别优于回忆 | 需要的选项是不是摆在眼前 | 要用户记住上一步的编号 | | 灵活高效 | 有没有给熟手留一条捷径 | 只能一步一步点无批量操作 | | 极简设计 | 屏幕上有没有和当前任务无关的元素 | 装饰图表挤占主操作区域 | | 错误恢复 | 报错有没有说清原因和下一步 | 「操作失败请重试」 | | 帮助文档 | 帮助是不是出现在用户需要的位置 | 帮助入口埋在三级菜单里 |流程比表格更重要。正确做法是三到五名评估者各自独立走查、各自列问题然后才合并去重先讨论再走查会迅速收敛到同一种视角问题数量直接砍半。合并之后按「出现频率 × 严重程度」分级严重度可以用四级一级是外观瑕疵二级是轻微不便三级是阻碍任务完成四级是可能导致数据丢失或误操作。最后输出一张问题表每行写明位置、触犯的原则、严重度、修改建议——这张表就是大实验迭代阶段的输入。4.2 认知走查四个问题逐屏过一遍认知走查不需要用户靠的是评估者把自己代入一个具体用户沿着一条具体任务逐屏问四个问题用户会不会尝试达成这个效果界面提供的操作和用户的目标对不对得上用户能不能注意到正确的操作是可用的可见性够不够用户会不会把这个操作和想达成的效果联系起来映射清不清楚执行之后用户能不能看出操作已经生效有没有反馈四问的顺序不能乱因为它对应的是「形成目标—寻找操作—建立映射—评估结果」这条认知链。任何一问卡住都记一个设计缺口并注明是「通过 / 失败 / 存疑」。存疑不要强行判通过标记出来留到可用性测试里验证。这套方法最适合低保真阶段纸面原型上做认知走查改一笔成本几乎为零等到高保真做完再走查改一个交互可能牵动整条流程。带血泪经验的一条是走查时一定要挑「第一次使用」的用户视角而不是「已经用了三天」的自己。4.3 可用性测试任务脚本、发声思考与量表计分可用性测试最容易做错的地方不在数据分析在任务脚本。脚本写的是目标不是步骤。看下面这一组对比反例点击右上角的设置图标然后选择通知选项把开关关掉。 正例假设你不想再收到这类提醒了请把提醒关掉。反例里每一步都写明了位置和操作测的其实是「用户能不能照着指令点」测不出任何可用性问题。正例只给目标用户怎么找到入口、会不会迷路、会不会点错才是要观察的东西。主持人全程只说两句话「你现在在想什么」和「继续」。任何一次「你可以试试左边那个」都会让这一轮数据作废。样本量上有个常用的经验值同一类用户群、同一类任务五名被试大约能暴露大部分约八成以上的可用性问题。这个数字经常被误用成「五个人就够了」——它成立的前提是用户群单一、任务类型集中。如果你的产品有两类差异很大的用户五个人分摊到两类里就不够了。主观量表最常用的是十题版的系统可用性量表。这十题里有一半是正向描述、一半是反向描述计分时必须反向翻转这一步是重灾区def sus_score(responses): 十题系统可用性量表计分。 responses长度为 10 的列表每题原始分 1~5。 奇数题1/3/5/7/9正向贡献 原始分 - 1 偶数题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 区间。这里有个必须说清的点这个分数不是百分比不能说「可用性 80%」。它只是一个约定区间的分数业界常拿 68 分当平均参考线八十分以上算比较顺但样本量只有五个人时单看均值意义有限更该看的是每个人在哪几题上给了低分——那几题指向的才是具体问题。4.4 最后大实验的六步链路每一步的产出和验收标准大实验失分往往不是因为做得少而是因为阶段之间没有咬合原型做得很漂亮但需求说不清来自哪里测试做了一堆但改了什么没有记录。把六步的产出和验收标准列清楚进度和成文都会轻松很多。| 阶段 | 主要产出 | 判定通过的标准 | | 选题 | 一句话问题陈述 目标用户描述 | 能说清「谁在什么场景下被什么卡住」 | | 用户研究 | 三到五份访谈记录、需求清单 | 每条需求都能追溯到某条原始记录 | | 任务分析 | 层次任务分析表或用户旅程图 | 每个任务有明确起点和终点 | | 低保真 | 纸面或线框原型 | 认知走查无三级以上缺口 | | 高保真 | 可点击原型 | 主流程能独立走通五人测完 | | 迭代与成文 | 问题清单、修改对照表、报告 | 每个问题都有处理结论 |两点取舍经验。一是别在高保真上过度投入视觉精细度和可用性没有必然关系把时间花在第二轮测试上收益更高。二是迭代记录要做成「问题—修改—验证」三列而不是只写「已优化」答辩时被追问「你怎么知道改好了」能翻出第三列的人立刻占优。5. 易漏易错点五个让报告掉档的细节5.1 条件顺序没平衡学习效应冒充了设计差异易漏点被试内设计里所有被试都按「先 A 后 B」的顺序做结果 A 的完成时间偏长报告写成「A 方案更难用」。为什么漏数据本身没有异常两组均值确实差着统计检验也显著从数字上完全看不出问题。学习效应藏在顺序里不做平衡就永远暴露不出来。怎么补一半被试走 A→B另一半走 B→A也就是最基础的拉丁方平衡每个条件前加固定轮数的练习试次并剔除练习数据分析时把「顺序」当成一个额外因素看一眼如果顺序的主效应很大说明平衡没做好得在讨论段如实说明。5.2 量表反向题没翻转分数全反了易漏点十题量表里反向题直接按原始分累加算出来的分数看着像模像样方向和真实感受相反。为什么漏正向题和反向题混排录入时逐行敲数字很容易一路顺着敲下去而且错误结果仍然落在合理区间内不会报错、不会越界属于典型的黑匣子错误。怎么补把计分写成函数参考 4.3 的实现奇数题减一、偶数题用五减输入前先断言范围录完随机抽两三份手工复算一遍对不上就整批重来。这一步花五分钟能省掉答辩现场被要求现场重算的尴尬。5.3 任务脚本里藏了操作提示测试变成了教学易漏点脚本写「点击右上角设置选择通知关闭开关」用户顺利完成成功率 100%报告写「界面易于使用」。为什么漏脚本读起来非常自然像是正常的任务描述写的人自己意识不到已经把所有决策都替用户做完了。而且成功率漂亮没人会去质疑。怎么补写完脚本做一次自查——把脚本里所有方位词和控件名划掉看剩下的句子还能不能构成一个完整目标。不能就重写。测试时主持人只记录不提示用户问「是不是点这里」回一句「你觉得呢」即可。5.4 只报 p 值不报效应量和样本处理易漏点结果段写「p 0.05差异显著」然后直接下结论说方案 A 明显更好。为什么漏显著性检验是最容易出结果的一步软件一点就有数字而效应量、置信区间、异常值处理这些「不显著但重要」的东西教材上往往一笔带过。怎么补每个主要比较都配一个效应量并在方法段写清样本量、剔除标准和剔除数量。样本量只有八到十人的课程实验里p 值本身很不稳定多报一个效应量能让结论的可信度上一个大台阶。顺便说前文提到的「拿几百行 trial 直接做检验」也是同一类问题的变体——先把数据聚合到被试层面再谈显著性。5.5 原型做太早太细来不及迭代易漏点第二周就开始抠高保真细节到测试阶段只剩三天测出来的问题一个都改不完报告里只能写「后续可优化」。为什么漏做界面比想需求有成就感工具又顺手很容易一头扎进去。等到发现方向错了沉没成本已经很大改不动了。怎么补把「低保真通过认知走查」设成硬门槛没通过不许进高保真高保真只做能走通主流程的最小集合装饰性内容留到最后。测试排期往前挪至少留出两轮修改时间——第一轮改大问题第二轮验证改得对不对这个节奏比任何视觉细节都值钱。6. 复习清单交稿前把报告倒着读一遍复习这个方向最有效的方式不是重看教材而是拿自己那份报告做一次逆向检查。下面这张自查表按「最容易忘」到「最不容易忘」排序交稿前从上往下过一遍。| 序号 | 检查项 | 不合格的表现 | | 1 | 假设有方向、有指标 | 只有「更好用」这类描述 | | 2 | 指导语原文完整 | 方法段只有「被试按指示完成任务」 | | 3 | 条件顺序已平衡 | 所有人顺序一致报告不提顺序 | | 4 | 数据已聚合到被试层面 | 直接用 trial 行数当样本量 | | 5 | 量表反向题已翻转 | 没有计分函数手工敲的数字 | | 6 | 每个比较都有效应量 | 只有 p 值 | | 7 | 剔除标准写清 | 只说「剔除异常值」不说怎么判 | | 8 | 任务脚本无操作提示 | 脚本里出现方位词和控件名 | | 9 | 问题清单有严重度分级 | 一长串问题不做优先级 | | 10 | 迭代记录有「验证」列 | 只写「已优化」 | | 11 | 局限段解释异常数据 | 局限写成「样本量较小」一句带过 | | 12 | 图表有单位和误差线 | 只有均值柱无离散程度 |然后试一个倒读技巧从结论段往回读每读到一句判断就往前找支撑它的那个数字。读三遍基本能揪出所有「结论跑在数据前面」的句子——这是评审最容易抓住、也最难辩解的一类问题。倒读还有个副作用会让你发现某些图其实可以删掉因为它们不支撑任何一句结论。最后说一个习惯。从那以后我每次做完实验都会在收数据当天就把长表按「被试 × 条件」聚合一遍看一眼极值和缺失再决定要不要补测等写完报告再回头看数据往往已经来不及补了。这个动作花不到十分钟但它把「数据能不能用」这个问题提前到了还能补救的时候。希望帮到你。本文还有配套的精品资源点击获取