企业官网建设流程全解析

简介：面向人机交互课程学习者及需要完成实验报告、课程大作业的本科生，这份资料包围绕用户研究、界面设计、交互模式与可用性评估展开，覆盖二维交互画图板、语音交互程序、订单管理与BBS界面设计、VRML虚拟现实交互等实验，并包含最后综合大实验的完整参考。包内共86个文件、约24.97MB，以bmp界面素材、doc实验报告、ppt课件、cpp/h源码、pdf教程和wrl虚拟场景为主，兼有obj、exe等编译运行文件，便于对照源码、报告与演示材料还原实验过程。已有2487人学习，可用于梳理从需求分析、线框图、原型迭代到用户测试的完整流程，也能借鉴实验报告的组织方式、界面设计原则、反馈机制与评估思路，以及VRML和语音交互的具体实现，为课程作业和项目实践提供可复用的参考。

1. 先看地图：人机交互实验报告的四段证据链

人机交互实验报告以及最后的大实验，考的是你能不能把「用户—任务—界面—评估」四段串成一条别人能照着复现的证据链，并非某个原型工具用得多熟。很多人把实验报告写成截图合集，把大实验做成界面展览，分数自然卡在及格线附近。这门课真正的骨架是：用户研究定问题，任务分析定结构，设计原则定界面，评估数据定对错，四段各有方法和指标，缺一段报告就站不住。梳理下来会发现，期末大实验只是把这四段在一件完整作品上重跑一遍，篇幅变长、链路变完整，方法并没有换。这篇笔记适合正在赶实验报告、准备大实验答辩，或者考前想把整门课重新捋一遍的人。

2. 用户研究与需求：访谈、问卷到 Persona 的证据沉淀

这一章决定整份报告的上限。用户研究做虚了，后面的任务分析就是在编，评估也只能证明「你自己觉得好用」。重点是每一步都要留下可追溯的原始材料：访谈录音、问卷原始数据、观察笔记，这些是报告附录里的硬通货。

2.1 三种主流方法的取舍：访谈、问卷、观察各管什么

方法本身没有优劣，错配才致命。访谈擅长挖「为什么」，问卷擅长量「有多普遍」，观察擅长抓「说和做不一致」的地方。实验报告里最常见的翻车，是用问卷去问开放式的动机问题，或者用访谈去推全体用户的分布比例。

访谈的关键在提问方式。把「你觉得这个按钮是不是很难找」换成「上次你用这个功能是什么时候，当时怎么操作的」，答案的性质就完全变了。前者是在收集认同，后者是在收集事件。半结构化提纲一般控制在 8–12 个主问题，每个主问题下面备两三个追问，问完一轮再补问「还有吗」，往往会挖出最有价值的那条。

问卷设计的重点是题目要单向。一道题里塞两个判断，比如「界面简洁且操作流畅」，受访者勾了「同意」你根本不知道他同意的是哪半句。李克特 5 点或 7 点都行，但全套要统一，别一半 5 点一半 7 点。正式发放前找三五个人做预测试，看有没有人问「这题什么意思」，有就说明题目没写清。

2.2 从原始材料到 Persona 与用户旅程图

原始材料不能直接进正文，中间要做一次聚类。把访谈逐字稿里的原话剪成一条条卡片，按「目标 / 行为 / 痛点 / 现有替代方案」四类做亲和图聚类，同一类里反复出现的才值得抽象成结论。只出现一次的观点不是不能写，但要标明是个案。

Persona 的作用是把聚类结果人格化，让人一眼记住目标用户长什么样。一页纸通常包含：虚构代称与角色标签、一句能代表态度原话的引言、行为特征（使用频率、使用环境、设备偏好）、核心目标、主要痛点、技术熟练度。最容易犯的错是往里塞没有数据支撑的细节，比如凭空写「她喜欢在通勤路上使用」，结果评审一问数据来源就露馅。每个字段都应该能指回某条原始记录。

用户旅程图则是把时间维度加进来：阶段、用户行为、触点、当时的想法、情绪高低、痛点和机会点。情绪曲线是全图最有信息量的部分，那些明显下沉的谷底，就是你后面要设计的核心功能点。梳理下来会发现，一份好的旅程图基本已经把信息架构和主流程画出了一半。

2.3 需求转写与优先级：把「用户说的」变成「可验证的」

用户说的永远是需求语言，比如「我想快点找到上次的记录」。报告里要往下翻译两层：功能需求是「提供历史记录的快捷入口与检索」，可验证指标是「老用户在 3 次点击内、10 秒内找到 7 天前的某条记录」。没有指标的需求没法验收，也没法设计测试任务，这是很多实验报告丢分的地方。

场景剧本是转写的好载体。一段剧本写清五件事：谁、在什么情境下、想达成什么目标、现在用什么办法、卡在哪一步。写法上把自己代入，不要写成功能说明。优先级排序用 MoSCoW 就够用：必须有、应该有、可以有、这次不做。四档分完，大实验的范围自然就锁定了，不至于做到最后一周还在加功能。

提示：需求条目写完做一次自检，每条问一句「如果这条不满足，用户会怎么样」。答不上来的，多半是伪需求或者写得太笼统。

3. 任务分析与原型：从 HTA 拆解到可点击界面

用户研究告诉你问题在哪，任务分析告诉你结构该怎么分。这一章的重点是把「用户想干什么」拆成可数的步骤，因为后面评估时用到的任务完成率、任务时间、操作步数，全都依赖这里拆出来的层级。

3.1 层次任务分析 HTA：把目标拆到可数的操作

HTA 的核心是把一个高层目标逐级分解成子任务和操作，并用 plan 描述执行顺序。它的价值在于把「操作繁琐」这种模糊评价，变成一个可以数出来的数字：完成挂号要 4 层、17 步，其中 6 步是重复输入。

一个典型的拆解长这样：

0. 在自助终端完成一次挂号 1. 选择科室 1.1 浏览科室分类列表 1.2 或使用搜索框输入科室名 2. 选择医生 2.1 查看医生排班 2.2 查看医生简介 3. 选择就诊时段 4. 确认信息并支付 plan 0：执行 1-2-3-4；若 3 无可选时段，返回 2 重新选医生 plan 1：优先执行 1.2，失败时退回 1.1

写 HTA 有两个技术点常被忽略。一是停止规则，不要无限往下拆，判断标准是「继续拆能否带来新的设计洞察」，常用的经验判断是失败概率乘以失败代价，两者都低就停。二是 plan 必须写清楚分支和回退路径，只写顺序不写分支的 HTA 相当于没做分析，因为真实的卡点几乎都在分支上。

拆完拿红笔标三类步骤：可以不做的、可以合并的、可以交给系统自动完成的。这三类标出来的数量，就是你在报告里论证「新方案减少了多少操作」的直接依据。

3.2 GOMS 与 KLM：给「效率」一个可算的数

GOMS 是目标、操作符、方法、选择规则四件事的合称，属于认知层面的任务建模。真正能在实验报告里落地的是它的简化版 KLM，也就是击键层模型：把一次交互拆成若干标准操作符，每个操作符有公认的时间值，累加就得到专家用户完成该任务的预估耗时。

# KLM 预估：在搜索框输入 4 个字符并回车 TIME = {"K": 0.28, "P": 1.10, "B": 0.10, "H": 0.40, "M": 1.35} def klm(seq, system_response=0.0): """seq 为操作符序列；system_response 为实测的系统响应秒数""" return round(sum(TIME[op] for op in seq) + system_response, 2) # M 定位心理准备，P+B 移动并点击输入框，K 四次输入，M 思考，K 回车 print(klm(['M', 'P', 'B', 'K', 'K', 'K', 'K', 'M', 'K'], system_response=0.6)) # 输出 5.9，即专家路径预估约 5.9 秒

这段代码的用途是给方案对比提供量化依据：把旧方案的路径和新方案的路径各算一遍，差值就是「效率提升」的数值。参数上要注意两点，K 的取值跟用户打字水平强相关，报告里必须写明你用的是哪一档，否则数字没法复现；M 的插入位置带有判断成分，一般只在需要决策或视线大幅转移的地方插一个，插多了时间会被高估。

KLM 的局限也要在报告里讲清楚：它只描述无差错的专家操作路径，不含视觉搜索、不含出错重试、不含认知负荷。所以它适合同一任务不同方案的相对比较，不适合当作绝对的用户耗时预测。

顺带把 Fitts 定律用上。目标获取时间与「距离除以目标宽度」的对数成正比，落到设计上就是两句话：高频操作的按钮要够大，且离上一次点击的位置要近。移动端的点击区域建议不小于 44×44 pt，这不是玄学，是误触率曲线的拐点。

3.3 设计原则与原型保真度：低保真验证结构，高保真验证观感

设计原则这一块，考试和答辩都爱考，但真正有用的是拿它当检查表用。把十条原则摊开，一条条对着自己的界面走一遍，能捞出一半的低级问题。

低保真原型（纸原型、线框图）验证的是信息架构和主流程，成本低、改起来快，用户面对粗糙的稿子反而更敢提意见。高保真可交互原型验证的是视觉层级和微交互，但它有个副作用：做得越精致，用户越不好意思批评，容易收到一堆「挺好的」。所以正确顺序是先低保真把流程跑通，再高保真确认观感，别一上来就做高保真。

重点在于保真度要和验证目标匹配，别为了好看提前消耗时间。大实验里通常是一轮纸原型走查加一轮高保真可用性测试，两轮之间必须有明确的修改记录，这条修改记录本身在报告里就是加分项。

4. 评估与数据：启发式走查、可用性测试与统计口径

到这一章，前面的设计全部变成待验证的假设。评估要回答的只有一件事：用户能不能顺利完成，卡在哪，有多严重。难点不在于跑一遍流程，而在于把主观感受转成能写进报告的、有口径的数据。

4.1 启发式评估：先自查再上用户

启发式评估是专家走查，3–5 名评估者各自独立过一遍界面，对照设计原则列出问题，再合并去重、评严重度。它便宜、快，适合在用户测试之前先把低级问题清掉，免得浪费被试时间。

严重度评级用 0–4 五档：0 是「不算问题」，1 是「外观层面，可以缓」，2 是「轻微，影响效率」，3 是「严重，用户会明显受挫」，4 是「灾难级，任务无法完成」。每条问题必须写清四件事：出现位置、违反了哪条原则、复现步骤、严重度。只写「首页有点乱」的条目，评审直接跳过。

最容易忽略的是评估者构成。设计者本人不能是唯一评估者，你对自己界面的容忍度会显著高于陌生人，很多问题在你眼里是「用户会懂的」。至少要凑三个背景不同的人：一个懂交互的、一个懂业务但不懂界面的、一个完全的目标用户。三个人的问题列表合并后去重，重合的那几条基本就是真问题。

启发式评估和可用性测试不是替代关系。前者发现的是「违反原则」，后者发现的是「真实卡点」。一个界面可以十条原则全踩，用户照样能用；也可以原则全守，用户还是找不到入口。报告里两段都写，才是完整证据。

4.2 可用性测试：任务、被试与出声思维

定性可用性测试的经典样本量是 5–8 人，理由是大问题在前几个人身上就会重复暴露。定量研究要谈比例和显著性，样本量得往 20 以上走，这一点在实验报告里必须写清楚，别用 5 个人的任务完成率去下「90% 的用户能完成」这种结论。

任务设计是全场最容易翻车的环节。任务必须目标导向，不能带操作路径。「请点击左上角的搜索框，输入关键词并回车」是操作说明，不是任务；「请找到上周买过的那款耳机并再次下单」才是任务。任务卡上只写情境和目标，不写步骤，主持人也不许提示。

主持人的行为准则就三条：不引导、不救场、用中性追问。用户卡住时最想问「你看到那个按钮了吗」，忍住。可以问的是「你现在在想什么」「你期望这里发生什么」。用户一旦提问「我是不是该点这里」，标准回应是「你觉得呢」。这些话术看起来机械，但它是保证数据可信的前提。

出声思维分同步和回溯两种。同步出声思维能抓到当下的判断，代价是会略微拖慢操作，测任务时间时要单独说明；回溯式访谈在任务结束后立刻进行，边放录像边问，适合补上「当时为什么犹豫」。实践里常把两者结合：操作时要求尽量说，卡住时不打断，结束后再回头问。

记录表按任务一行，字段包括：是否完成（完成 / 部分完成 / 失败）、耗时、出错次数、求助次数、卡点描述。部分完成要定义清楚标准，比如「完成了下单但选错了规格」，这类数据在讨论部分比成功失败二元判断有用得多。

4.3 量表与统计：SUS、NASA-TLX 与显著性检验

SUS 是十道题的五点量表，奇数题正向、偶数题反向，计分方式见下面的代码。它的原始总分是 0–40，乘 2.5 映射到 0–100，注意这个分数不是百分比，别在报告里写成「可用性 82%」。经验参考值是均值 68 左右，80 以上算好，70 以下说明有明显问题。

def sus_score(responses): """responses：长度 10 的列表，按题号 1..10 顺序传入，取值 1-5""" if len(responses) != 10 or any(not 1 <= r <= 5 for r in responses): raise ValueError("需要 10 个 1-5 的整数") total = 0 for i, r in enumerate(responses, start=1): # 奇数题正向计分减 1，偶数题反向用 5 减 total += (r - 1) if i % 2 == 1 else (5 - r) return total * 2.5 # 0-40 映射到 0-100 print(sus_score([4, 2, 5, 1, 4, 2, 4, 2, 5, 2])) # 输出 85.0

这段逻辑里唯一容易错的是方向。偶数题本身就是负向表述，比如「我觉得这个系统没必要这么复杂」，用户勾「非常同意」代表体验差，必须反向计分。方向搞反不会报错，只会让分数虚高十几分，而且很难自查出来，答辩时被问一句「你这分数怎么算的」就露馅了。

NASA-TLX 测的是负荷，六个维度：脑力要求、体力要求、时间压力、绩效感受、努力程度、挫败感，各维度 0–100 打分，可以只报原始均值（Raw TLX），也可以在报告里说明加权方式。它和 SUS 互补：SUS 测结果好不好用，TLX 测用起来累不累。

有了数据就要谈检验。同一批用户先后用旧版和新版，属于配对设计；两组不同用户各用一版，属于独立组设计。前者用配对 t 检验或 Wilcoxon 符号秩检验，后者用独立样本 t 或 Mann-Whitney U。三组以上用方差分析或 Friedman 检验。选哪个取决于正态性，样本量小的时候先做 Shapiro-Wilk。

from scipy import stats # 同一批被试先后使用旧版与新版，SUS 分数，配对设计 old = [72.5, 65.0, 80.0, 55.0, 67.5, 75.0, 62.5, 70.0] new = [85.0, 77.5, 87.5, 70.0, 80.0, 82.5, 75.0, 82.5] diff = [n - o for n, o in zip(new, old)] print(stats.shapiro(diff)) # 正态性检验，p 大于 0.05 才考虑 t 检验 print(stats.ttest_rel(old, new)) # 配对 t 检验，输出统计量与 p 值 print(stats.wilcoxon(old, new)) # 不满足正态时的非参数替代

报告里除了 p 值，还要写效应量 Cohen's d，配对设计用差值均值除以差值标准差，0.2、0.5、0.8 大致对应小、中、大。样本量只有八个的时候，p 值很容易不显著，这时候诚实写「趋势明显但未达显著」比硬凑结论好。数据分布也要交代：任务耗时通常右偏，报中位数比报均值稳，真要报均值就配上标准差和样本量。

5. 易漏点与易错点：量表计分、任务引导与基线缺失

这些坑的共同点是「不报错」：流程照跑、数据照出、报告照交，分数就是不高。逐个说清怎么补。

5.1 计分与量表：三个算错就白做的地方

SUS 反向题没反向，这是头号杀手。为什么容易漏：题目顺序是正负交替的，抄模板的时候只抄了题面没抄计分规则，或者用表格公式时把偶数行漏了。怎么补：写死一个函数或一个 Excel 列，输入原始 10 个数字就出分，并且拿一组已知答案的样例做单元自测，比如全选 3 应该得 50 分，这个数字能立刻验证方向对不对。

把 SUS 分数当成百分比讲。为什么容易漏：0–100 的区间太像百分比，写「可用性达到 85%」读起来很顺。怎么补：报告里统一写成「SUS 得分 85」，并在首次出现时加一句说明它是复合指数而非百分比。这个细节评审很在意，因为它直接反映你有没有读懂量表。

NASA-TLX 六个维度直接算术平均。为什么容易漏：看着像六个同权重的题。怎么补：要么明确声明采用 Raw TLX 并对等权重做说明，要么按两两比较得到的权重加权。用哪种都行，不写清楚不行。

5.2 实验执行与报告：两处最容易被扣分的细节

任务描述泄露操作路径。为什么容易漏：写任务卡的时候自己脑子里已经在演示操作，笔一滑就把步骤写进去了，读起来还很自然。怎么补：写完任务卡后做一次「反读」，看这句话能不能照着一步步操作；能，就说明写的是说明书不是任务。改法是把手段全部删掉，只留情境和目标。

没有基线就下结论。为什么容易漏：大实验只做了自己的新方案，没有对照组，于是只能说「用户反馈良好」。怎么补：三种低成本基线任选其一——同一批被试先用现有产品跑一遍，或者用纸原型和最终版做前后对比，或者用 KLM 算出的理论耗时做参照。有基线才有「改善了」这句话的资格。

还有一条隐性失分点：只放截图不看闭环。报告里出现的问题，后面必须跟一条「改了什么、复测结果如何」。哪怕只改了两条、复测只找了三个人，这个闭环也比堆十张精美截图有说服力。梳理下来会发现，评审看的从来不是你做了多少界面，而是你能不能证明这些界面是被数据推着改出来的。

6. 复习清单：把大实验拆成可交付的七步

复习时与其从头翻讲义，不如拿一张交付物清单倒推自己缺哪块。下面这张表是我自己按周拆的，每一步都有明确的产出物，做不出来就说明对应章节没掌握。

对着清单逐条打勾的时候，重点看三处最容易空的：有没有做基线对比、有没有复测闭环、统计部分有没有写清样本量和分布。这三处只要缺一处，整份报告的「证据链」就断了一节，其余部分做得再漂亮也补不回来。

一个小技巧：把 SUS 计分和统计检验提前写成两段固定脚本，数据一进来就跑，别留到最后一天。数据结果出来之前，讨论部分一个字都别写，人的本能是先有结论再找数据，顺序反了必然出现「数据不支持结论」的尴尬。

血泪经验是评审提问基本集中在两句话上：「你怎么确定这是真问题」和「你凭什么说改好了」。前者指向原始材料的可追溯性，后者指向基线与检验。提前把这俩问题的答案各写三行放在答辩稿首页，剩下的时间就可以安心讲设计细节了。

从那以后我每次开新项目，都强制先把评估口径定下来再动手画界面，接口和量表一起设计，省下的返工时间比想象中多。希望帮到你。

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