从菲茨定律到可用性测试：人机交互实验报告与原型迭代-育师

简介：面向高校人机交互课程学习者与期末项目完成者，这套实验资料围绕二维交互画图板、语音交互、界面设计与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 自变量、因变量、控制变量：一张表定死

变量定不清，后面所有统计都是白算。做界面实验时，把这几类变量摊在一张表上，比在脑子里过一遍可靠得多。

表里最容易被忽略的是最后一行。混淆变量不会因为你没写就不存在，它只会悄悄混进结果里，让你在讨论段写不出一句有底气的话。控制它的手段无非三种：随机化条件顺序、用拉丁方做平衡、每个条件前加固定轮数的练习试次并把练习数据剔除。

还有一个常被忽略的区分：被试内设计和被试间设计。同一批人做所有条件，叫被试内，样本效率高但必须平衡顺序；不同人分到不同条件，叫被试间，没有顺序问题但个体差异会变成噪声。课程实验里九成用的是被试内，而九成的翻车也都出在忘了平衡。

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, start=1): 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. 复习清单：交稿前把报告倒着读一遍

复习这个方向，最有效的方式不是重看教材，而是拿自己那份报告做一次逆向检查。下面这张自查表按「最容易忘」到「最不容易忘」排序，交稿前从上往下过一遍。

然后试一个倒读技巧：从结论段往回读，每读到一句判断，就往前找支撑它的那个数字。读三遍基本能揪出所有「结论跑在数据前面」的句子——这是评审最容易抓住、也最难辩解的一类问题。倒读还有个副作用，会让你发现某些图其实可以删掉，因为它们不支撑任何一句结论。

最后说一个习惯。从那以后我每次做完实验，都会在收数据当天就把长表按「被试 × 条件」聚合一遍，看一眼极值和缺失，再决定要不要补测；等写完报告再回头看数据，往往已经来不及补了。这个动作花不到十分钟，但它把「数据能不能用」这个问题提前到了还能补救的时候。希望帮到你。

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

从菲茨定律到可用性测试：人机交互实验报告与原型迭代