人机交互设计大作业.zip：从文件结构到可用性测试的完整交付指南

简介：面向高校人机交互课程学生与需要完成交互设计项目的开发者，这份人机交互设计大作业资源包围绕企业食堂订餐系统的完整设计流程展开。包内含22个文件，涵盖docx文档、pptx演示文稿、PDF理论资料、HTML网页及原型压缩包等类型，整体大小17.62MB，兼顾需求分析、原型设计、代码规范与汇报展示等多个环节。内容从订餐系统需求分析、WBS任务分解，到交互原型、界面规范与模型理论均有涉及，并配有git使用指南、文件命名规范等过程性文档，可帮助读者快速理解人机交互设计大作业的完整输出结构。其中web目录包含可打开的页面文件，原型压缩包则保留可编辑的设计版本，便于二次修改与复用。目前已有4538人学习下载，适合用于课程设计参考、答辩准备或团队协作流程梳理，尤其是对订餐类交互系统感兴趣的人群。

1. 一份"人机交互设计大作业.zip"交出去之前：先搞懂评审拆开压缩包后想看什么

期末前夜把 Figma 链接、Axure 源文件、十几张截图和一份 8000 字的 Word 文档一股脑拖进文件夹，右键"压缩为 zip"就提交——这是人机交互设计大作业最常见的翻车现场。评审老师下载这份人机交互设计大作业.zip 后，第一件事不是逐张看图，而是先看文件树：能不能在 30 秒内定位到报告、原型 demo 和演示视频。这篇文章不讲空泛的"设计思维"，只讲一份拿得出手的 zip 该怎么组织内容、怎么写报告、怎么做可运行原型、怎么打包不出乱子，以及答辩现场怎么把 zip 里的东西讲明白。适合正在赶课程大作业的学生，也适合带毕设或课程设计的指导老师参考。

2. 拆解大作业.zip 的交付结构：先把文件树搭对，再往里面填内容

很多人写大作业的习惯是把所有材料先堆在桌面，最后一天才开始整理，结果压缩包里全是"新建文档""最终版2.0""未命名.png"。评审不是考古专家，不会帮你在乱糟糟的文件堆里找重点。正确的顺序是：写第一行字之前，先把空的目录树建好，每产出一个文件就丢进对应目录，最后打包时只做核对，不做整理。

这个习惯和写代码之前先建工程目录一模一样。目录结构本身就在表达你的设计流程，它让老师不点开任何文档，就已经看出你做了需求调研、原型迭代、测试评估这几件事。下面我把一套我用过四年的结构完整写出来，你可以直接抄。

2.1 文件树该怎么排：让老师 30 秒找到核心交付物

一套规范的顶层结构大概长这样：

交互设计大作业_学号_姓名/ ├── 01_需求与调研/ │ ├── 需求分析报告.pdf │ ├── 用户访谈记录.docx │ └── 竞品分析表格.xlsx ├── 02_设计过程/ │ ├── 设计报告.pdf │ ├── 原型迭代记录.docx │ └── 线框图_初版_v1/ ├── 03_交互原型/ │ ├── 可运行Demo/ │ │ ├── index.html │ │ └── assets/ │ └── 原型演示视频.mp4 ├── 04_测试与评估/ │ ├── 可用性测试报告.pdf │ ├── SUS量表原始数据.xlsx │ └── 测试任务记录.md └── README.txt

第一层目录用"序号_类别"命名，是因为文件管理器默认按名称排序，01、02、03、04 按顺序排列后，恰好构成一条阅读动线：先看需求，再看设计，接着打开原型体验，最后看测试证据。这个顺序和评审的打分逻辑一致，老师从左到右点一遍，你的工作过程就完整呈现了。

有几个细节容易踩坑。第一，命名里不要带空格和中文括号，因为很多学校的作业系统跑在 Linux 服务端，解压后中文可能乱码，带空格的文件名在命令行里还要转义，等于给助教增加操作成本。第二，README.txt 一定要写，内容不需要长，三段话就够：项目一句话简介、各目录里放什么、Demo 怎么启动。老师打开压缩包第一眼先看它，相当于是你的交付物地图。第三，过程稿不要和最终稿混放，草稿单独放一个"过程文件"目录或者干脆不放，让 04 之后永远只有最终交付物。

下面这张对照表可以帮你自查命名是否合格：

2.2 四类必备文件与命名规范：从需求文档到交互原型的目录清单

压缩包里到底该装哪几类文件，取决于这门课想考察什么。绝大多数人机交互设计大作业要考察的是"你有没有完整走一遍以用户为中心的设计流程"，所以最少需要四类东西，正好对应上面的一级目录。

第一类是需求与调研，包括需求分析报告、用户访谈记录、竞品分析表格。需求分析报告建议导出成 PDF，因为 Word 在不同设备上打开排版会乱；访谈记录保留 docx 反而方便老师批注；竞品分析表格用 xlsx，最好带一列"可借鉴点"和"本设计对应方案"，不要只罗列竞品截图。访谈原始录音不要打包进 zip，体积大且有隐私问题，只需要放转录后的文字。

第二类是设计过程，核心是设计报告和原型迭代记录。设计报告是整份 zip 的正文，页数不限，但结构要清晰：背景与问题定义、用户研究、设计目标、信息架构、线框图、高保真、迭代记录。线框图部分不要只放最终版，把 v1、v2、v3 并列，能直观展示你的演进过程。原型迭代记录可以单独成文，我在第 3 章会细讲它怎么写。

第三类是交互原型，也就是可运行的 demo 和演示视频。这里有一个高频翻车点：只交 Axure 源文件。老师的电脑上不一定装了 Axure，你交一个 .rp 文件等于没交。必须导出一份纯 HTML/JS 的可运行版本，或者录一段 MP4 演示视频。如果两者都给，视频优先展示核心流程，HTML 让老师自己点。

第四类是测试与评估，包括可用性测试报告和原始数据。原始数据比结论重要，老师会翻你的 SUS 量表、任务完成率表格，判断你的测试是不是真的做了，还是编的。测试报告里写明测试时间、地点、人数、任务列表、测量指标、被试筛选条件，这些细节最能体现严谨性。

2.3 可交互原型 vs 静态图纸：为什么评审两者都要看

我见过两类极端作业：一类只有设计报告，里贴满截图，没有任何可交互的东西；另一类是只有一个 Axure 源文件，没有任何过程文档。前者的问题是"无法验证交互是否成立"，静态图纸上画得再漂亮，按钮能不能点、页面怎么跳转，老师看不到；后者的问题是"无法验证你是否有完整的设计流程"，你到底有没有做调研、有没有迭代，老师完全不知道。

正确的做法是让两者互相印证。设计报告里的线框图和高保真图，解决的是"你设计过什么"的问题；可交互 demo 解决的是"你的设计能不能跑起来"的问题。评审双线并行：先点开 demo 走一遍主流程，如果发现某个按钮点了没反应，会翻到设计报告里去找交互说明；如果报告里也没写，这处交互就等于没做。反过来，报告里写了十个功能点，demo 里只能跑到三个，也会被扣分。

所以压缩包里这两类内容必须同时存在，且要保持一致。demo 里的页面结构、文案、颜色，必须和报告里的高保真图对得上。不一致的结果比缺文件更糟，老师会认为你工作态度有问题。我的做法是：改一版设计，就同步更新报告截图和 demo，宁可多花十分钟，也不要留下两个版本对不上的痕迹。

3. 把设计过程写进报告：从用户研究到可用性测试的证据链怎么做

报告是大作业.zip 的灵魂，但很多人的报告写得像说明书：堆了一堆问卷截图、用户访谈记录、任务完成率表格，却没说清楚这些数据到底怎么影响了设计决策。评审想看的是"证据链"——你通过什么方法得到了什么结论，这个结论又怎么转化为具体的界面设计。这一章把报告里最关键的三个部分拆开讲。

3.1 用户研究部分：别只贴问卷截图，要讲出决策逻辑

用户研究是报告的第一块内容，也是最容易写成流水账的地方。典型写法是"我们设计了问卷，通过微信群发放，回收 50 份，其中男生 28 人，女生 22 人"，然后就没有然后了。这种写法等于告诉老师：你只做了数据收集，没有做分析。

我一般要求报告里每一个数据后面都要跟一句"所以"，形成闭环。比如：50 人中有 42 人每周使用二手交易平台 1 到 3 次，其中 30 人抱怨"找不到想要的物品"、22 人抱怨"图片加载慢"——所以本次设计把搜索与筛选作为首页核心模块，并对图片列表做懒加载优化。访谈记录同理，不要整段贴两个人的对话，而是提炼典型引用，然后说明这句话对应了哪个设计决策。

颗粒度也要控制。问卷只写总体结论和交叉分析的关键发现，交叉表放附录；访谈每一段引用后必须有分析，不能只引不加。记住，评审老师大概率不会逐字读你的用户研究部分，他找的是"数据到决策"的推导过程。每个设计决策至少能找到一条支撑数据，这个报告就算立住了。

3.2 原型迭代记录：截图对比加修改理由，最容易拿分的章节

原型迭代记录是整份报告里性价比最高的一章，因为它不需要数据，只需要真实记录你改稿的过程。哪怕你从头到尾只改了三次，也比一次性给出完美终版更能体现设计能力。评审想看的是你怎么发现问题、怎么权衡方案、怎么做出取舍。

标准格式是一张对比表加一段说明文字。表格里放三个版本，每一行一个关键修改点：

这个表格的好处是让老师一眼看到你的思考过程：发现问题、定位原因、给出方案、验证效果。迭代不需要多，三四轮足够，每一轮的改动点都要具体。不要写"调整了整体风格"这种模糊描述，要写清楚改了哪个控件、为什么改、对用户行为有什么影响。没有测试支撑的修改，就写"根据竞品分析"或"依据尼尔森原则"，总之每个改动都要有出处。

3.3 可用性测试：任务完成率、出错率与 SUS 量表怎么报

可用性测试是很多学生最心虚的部分，因为看起来"不科学"。其实课程大作业不需要几十个被试，5 到 8 人就能得到有效结果，Nielsen 在 1993 年的经典论文里就说过，5 个用户能暴露约 80% 的可用性问题。关键是测试设计要规范。

报告里至少写清楚五件事：测试目的、被试信息（年龄、是否相关专业、有无同类产品使用经验）、测试任务（3 到 5 个，每个任务写成场景句，比如"你想买一台二手相机，请找到价格在 3000 到 5000 元之间的在售商品"）、测量指标（任务完成率、操作时间、出错次数）、测试环境。不要只写"测试顺利完成"，要把失败任务也列出来，失败才是迭代的依据。

SUS 量表是可用性测试最通用的标准化工具，10 道题，每题 1 到 5 分。计算时奇数题得分减 1，偶数题用 5 减，所有题处理后的分数相加再乘 2.5，满分 100，70 分以上属于可用性可接受范围。我习惯用一段小脚本处理原始数据：

responses = [ [5, 4, 4, 3, 4, 3, 5, 4, 4, 3], # 用户1的10道题得分 [4, 4, 3, 4, 4, 3, 4, 3, 3, 4], # 用户2 [5, 5, 4, 3, 5, 2, 4, 4, 5, 3], # 用户3 ] for idx, r in enumerate(responses, 1): odd_sum = sum(r[i] for i in range(0, 10, 2)) # 奇数题: 得分减1 even_sum = sum(r[i] for i in range(1, 10, 2)) # 偶数题: 5减得分 sus = (odd_sum - 5 + 25 - even_sum) * 2.5 print(f"用户{idx} SUS = {sus:.1f}")

逻辑说明：SUS 的标准算法中，奇数题正向计分（减 1），偶数题反向计分（5 减），两项分别求和后相加，再乘 2.5 换算成百分制。脚本里 odd_sum 对第 1、3、5、7、9 题求和，再统一减 5，等价于逐项减 1；even_sum 对第 2、4、6、8、10 题求和，用 25 减，等价于逐项做 5 减。如果算出来总分低于 60，说明你的设计还需要大改，不要强行解释，直接写"基于测试结果，我们在 v3 中进行了以下修改"，反而能体现迭代意识。

4. 用 Figma 或 Axure 做一版能跑的 demo：选型、导出参数与兼容性

原型工具选什么，取决于你手里的时间和习惯。Figma 适合页面流线线框流程快、团队协作方便的，Axure 适合要表现复杂条件分支和动态效果的。课程大作业层面，两者都能满足要求，但导出方式差异很大，这里把常见做法和参数设置拆开讲。

4.1 Figma 原型连线与分享链接：导出前必调的三个参数

Figma 做可点击原型，核心操作是在 Prototype 模式下给 Frame 之间连线。选中一个按钮，右侧会出现一个小圆点，拖到目标页面就建立一次跳转。连线本身不难，容易翻车的是导出前的三个参数。

第一个是 Flow 起点，必须在 Prototype 面板里点一下某个 Frame 上的小圆圈，把它设为 Starting Frame。如果不设置，导出的原型从哪个页面开始是随机的，老师打开可能直接落在空白画板。第二个是背景填充，Figma 导出 HTML 预览时默认用深色背景，高保真页面如果没有铺满 Frame 背景色，演示时四周一圈黑色非常难看，建议给顶层 Frame 设置浅灰或白色背景，和页面保持一致。第三个是分享权限，导出时要选 Prototype 而不是 Design，否则老师拿到的是左侧有编辑栏的编辑界面，而不是干净的演示视图。

Figma 导出 HTML，通过菜单 Share 里的 Present Prototype 生成链接，也可以下载桌面版后用插件导出离线包。离线包是一整个文件夹，压缩时别只压里面的 HTML 文件，要连 assets 目录一起压进去。给老师的 README 里写清楚：解压后双击 index.html，如果浏览器拦截了本地脚本，用 Chrome 的"允许本地文件访问"选项放行一次。

4.2 Axure 动态面板与变量：把条件分支做成看得见的交互

Axure 的交互能力比 Figma 强，代价是学习曲线陡。大作业里最常用的两个机制是动态面板和变量，很多评审眼中的"交互复杂度"都靠它们撑起来。动态面板适合做弹窗、切换、折叠这类同一区域多状态的内容；变量适合做登录状态切换、表单输入回传这类需要"记住用户操作"的场景。

举一个登录后导航栏变化的例子：拖入一个 Dynamic Panel，添加两个 State，State1 放未登录状态（显示"登录"按钮），State2 放已登录状态（显示用户名和"退出"）。选中登录按钮，添加交互用例：Click or Tap → Set Panel State → State2，触发方式选 Push，方向选向左滑动。这样点击后导航栏会有一个过渡动画，演示观感比干巴巴的跳变好很多。

Axure 导出 HTML 是 Publish → Generate HTML Files。参数里面有两个值得注意：Page 后缀选 html，不要选 php 之类的动态后缀，纯静态文件在任何 Web 环境下都能跑；浏览器兼容选 All Browsers，避免只在 Chrome 下正常而在评审的 Edge 上错乱。Axure 生成的 HTML 是一堆 .js 和 .html 文件，必须保持目录完整，压缩时选中整个生成的文件夹，不要只拖一个 index.html。

4.3 导出 HTML 或录制演示视频：给老师一个不依赖账号的 demo

无论用哪个工具，最终交付形态只有两种最稳：离线 HTML 文件夹，或 MP4 演示视频。HTML 的好处是老师可以自己点，坏处是遇到底层交互报错时你不在现场；视频的好处是稳定展示核心流程，坏处是无法体验完整交互。我的习惯是两者都交，视频控制在 3 分钟以内，只讲主流程和亮点。

录视频如果手头没有 OBS，用 ffmpeg 也能完成桌面录制，命令如下：

ffmpeg -f gdigrab -framerate 30 -i desktop -c:v libx264 -pix_fmt yuv420p demo.mp4

参数说明：-f gdigrab是 Windows 下的桌面录制输入设备，Linux 上换成x11grab，macOS 上换成avfoundation；-framerate 30控制帧率，课程演示 30 帧足够，60 帧徒增文件体积；-c:v libx264指定 H.264 编码，兼容性最好；-pix_fmt yuv420p把色彩格式转成 4:2:0，避免部分播放器出现花屏或无法解码。录制时鼠标不要乱晃，每个页面停留 3 秒以上，点按动作要慢，宁愿录长一点后期剪辑，也不要录完发现关键按钮没点到。

5. 打包与解压的坑：zip 伪加密、中文乱码与损坏排查

文件内容都做好了，最后一步右键压缩，看起来最简单，实际上坑最多。这一章全部是血泪经验，每一条我都亲自踩过或者帮学生排查过，按"现象 → 原因 → 解决"写清楚。

5.1 zip 伪加密：没设密码却弹密码框，多半是 flag 位被改了

现象：老师和同学下载压缩包后双击，弹窗要求输入密码，但你很清楚自己压缩时根本没设密码。用 7-Zip 打开却能直接看到文件列表。这就是典型的 zip 伪加密。

原因：zip 格式中每个文件头里有一个"通用位标志"字段，它的第 0 位代表是否加密。伪加密是指该标志位被人为置为 1，但文件数据实际没有加密。网上下载的一些模板、工具生成的 zip 会用这招来制造"付费解锁"假象，如果大作业素材里有从这类站点下载的图片模板，打包时会把这个标志继承下来。真正的加密数据需要密码才能读出内容，而伪加密只是骗过不了解格式的软件。

解决：判断和修复都可以用一段 Python 脚本，核心逻辑是对比本地文件头和中央目录的加密标志位：

import struct import zipfile def parse_local_file_flags(zip_path): """读取每个文件在本地文件头里的通用位标志""" flags = {} with open(zip_path, 'rb') as f: data = f.read() offset = 0 while True: idx = data.find(b'PK\x03\x04', offset) if idx == -1: break flag = struct.unpack('<H', data[idx+6:idx+8])[0] name_len = struct.unpack('<H', data[idx+26:idx+28])[0] extra_len = struct.unpack('<H', data[idx+28:idx+30])[0] name = data[idx+30:idx+30+name_len].decode('utf-8', errors='replace') flags[name] = flag offset = idx + 30 + name_len + extra_len return flags with zipfile.ZipFile('人机交互设计大作业.zip') as zf: local_flags = parse_local_file_flags('人机交互设计大作业.zip') for info in zf.infolist(): local_bit = bool(local_flags.get(info.filename, 0) & 0x1) central_bit = bool(info.flag_bits & 0x1) if local_bit != central_bit: print(f"伪加密: {info.filename}") elif local_bit and central_bit: print(f"真加密: {info.filename}")

逻辑说明：zipfile 读取的是中央目录里的 flag，而资源管理器弹出密码框时读取的是本地文件头里的 flag。如果同一个文件两个位置的加密位不一致，说明中间被工具改动过，属于伪加密。修复方法是用 7-Zip 打开压缩包，全选文件后重新解压到新目录，再用 7-Zip 重新打包，新生成的 zip 会重写所有文件头，伪加密位自然消失。注意：zip 伪加密不具备任何安全性，不要指望它保护内容，它能造成的唯一后果就是打不开。

5.2 中文文件名乱码：Windows 自带压缩与 7-Zip 的编码差异

现象：在 Windows 上用系统自带的"压缩为 zip 文件夹"生成压缩包，发到 Mac 或 Linux 上解压后，原本的中文文件名变成一串乱码，比如"设计报告"变成"设计æ¥å"。

原因：Windows 自带压缩工具写入文件名时使用本地语言编码（简体中文系统是 GBK），且不设置 zip 格式的 UTF-8 标志位。7-Zip 和 macOS 自带解压默认按 UTF-8 解码，GBK 字节被按 UTF-8 解析，就成了乱码。这是编码约定不一致导致的，不是文件损坏。

解决：最稳妥的办法是打包时统一用 7-Zip，并强制写入 UTF-8 文件名。命令行方式：

7z a -tzip -mcu=on 人机交互设计大作业.zip ./交互设计大作业_学号_姓名

参数说明：-tzip指定打包为 zip 格式，-mcu=on表示使用 UTF-8 编码文件名，这样在任何系统上解压都不会乱码。如果已经收到一个乱码压缩包，Linux 下有unzip -O GBK可以指定解码字符集；Windows 下用 7-Zip 打开后，在设置里把"文件名编码"切换为 GBK 再解压。Python 层面有一个经典修复姿势，zipfile 读出的文件名如果是乱码，可以按 CP437 重新编码再解码：

import zipfile with zipfile.ZipFile('乱码.zip') as zf: for info in zf.infolist(): raw = info.filename.encode('cp437') # zipfile 默认按 cp437 解码 try: name = raw.decode('utf-8') except UnicodeDecodeError: name = raw.decode('gbk', errors='replace') print(name)

这段脚本用于排查而不是修复，确认了正确的文件名后，用脚本重命名解压出来的文件即可。最省心的做法还是前面说的：统一用 7-Zip 加-mcu=on打包，从源头消灭乱码。

5.3 附件超限怎么办：分卷压缩与自解压的正确用法

现象：学校作业系统限制单个附件 50MB，你的演示视频压完还有 120MB，READM 里放了网盘链接老师又说不行。

原因：短视频时代，录屏 3 分钟 H.264 编码的 1080p 视频确实很容易超过这个体积。很多人的第一反应是把 zip 压缩等级拉到最高，但对于视频编码文件，zip 压缩几乎没有效果，因为 H.264 内部已经压过一遍。

解决：先压视频，再打包文件。视频用 HandBrake 转码，编码选 H.264，质量参数 CRF 设 23 到 26，分辨率降到 1080p，帧率保持 30，这样体积通常能压到原来的三分之一。如果还超限，再考虑分卷压缩：

7z a -v50m -t7z 大作业.7z ./交互设计大作业_学号_姓名

参数说明：-v50m表示每个分卷最大 50MB，-t7z使用 7z 格式来获得更好的压缩率。分卷生成的是 大作业.7z.001、大作业.7z.002 等多个文件，需要全部上传，评分系统如果不支持分卷上传，这条路就走不通。另一种常见做法是做成自解压文件：7z a -sfx 大作业.exe ./交互设计大作业_学号_姓名，老师双击 exe 自行解压，不需要装解压软件，但部分学校系统禁止上传 exe 附件。如果所有本地交付手段都受限，最后妥协是把演示视频单独放网盘，README 里写明提取码，并在正文先说明这件事，不要等老师自己发现。

另外说一句，Win10 右键菜单里的"压缩为 zip 文件夹"用的就是系统自带压缩，既不支持分卷也不支持 UTF-8 文件名，建议课程作业场景一律绕开它。

5.4 解压报错 unexpected end of data：损坏压缩包的急救

现象：同学反馈说压缩包解压到一半报错，提示unexpected end of data，或者"压缩包已损坏是否尝试恢复"。

原因：zip 是流式格式，每个文件的压缩数据独立存储。报这个错通常有三种可能：下载中断导致文件末尾缺失、用微信或网盘传输时被截断、U 盘在文件写入完成前被拔出。它不意味着整个压缩包都废了，往往是某一两个文件的数据段损坏，其余文件可能完好。

解决：先用 7-Zip 打开损坏的压缩包，它读取时如果还能列出文件列表，就直接全选解压，7-Zip 会跳过损坏文件并提示警告，这样至少能救出大部分文档和图片。如果连文件列表都打不开，在 Linux 上可以尝试用 zip 自带的修复模式：

zip -FF 损坏.zip --out 修复.zip

-FF尝试扫描压缩包内的文件结构并重建中央目录，它只对"文件数据完整但目录区损坏"有效；如果数据本身被截断，截断点之后的文件无法恢复。所以你不动，机器也救不回来，最实用的后悔药是提交前在本地留一份未解压的原始文件夹，压缩包只是交付物，不是唯一的副本。我现在的习惯是：压缩前在项目目录里跑一次find . -type f | wc -l，记录文件总数，提交后把压缩包下载回来再解压一次，核对数量和首页能否打开。这套流程十五分钟，能避免答辩现场打不开 demo 的最坏情况。

6. 答辩现场把 zip 里的内容讲出彩：三分钟演示脚本与追问预案

交付物没问题，最后还差临门一脚：演示。很多人在台上打开压缩包，花两分钟翻文件树，再点开报告念一页，时间就没了。正确的做法是压缩包只当备份，答辩全程演示可交互 demo，把报告数据放在手边备用。

6.1 三分钟演示脚本：按"问题-方案-验证"推进

时间分配建议：30 秒讲背景和核心用户诉求，90 秒演示三个关键交互流程，剩余 60 秒讲测试结论和迭代效果。演示前把鼠标停在首页的搜索框入口，不要现场找按钮；每演示完一个流程，说一句"这个页面的改动来自可用性测试第 X 条结论"。如果要打开 HTML demo，先在地址栏或文件管理器里把路径准备好，不要现场翻目录。视频演示适合放在最后 30 秒作为补充，不要一上来就放视频，评委想看到的是真人点按的现场反馈。

6.2 高频追问与应答预案：配色、字体与交互范式

老师最爱问的三类问题是：为什么用这套配色、为什么这个按钮放在这里、为什么用这种交互范式。每类问题背后都是同一个要求：你的设计决策要有依据，不能"我觉得好看"。配色就答竞品分析和用户偏好调研，引用报告里那个数据；按钮位置就答 Fitts 定律，说明目标大小和距离对操作效率的影响，再补一句测试数据作为验证；交互范式就答你比较过哪几种方案，测试或点评中哪个指标更好。不确定的资料不硬答，说"这个我记得报告第 X 部分有记录，稍后我指给您"比现场编一个理由好得多。

6.3 给未来的自己留一份可复现的交互设计资产

答辩结束不要急着删文件。把整套交付结构存一份备份，里面除了最终版，再保留三样东西：Figma 或 Axure 源文件、可用性测试的原始数据、一份标记了"如果重做会改哪里"的备忘。我自己的教训是，有次答辩前一天发现导出的 HTML 里中文字体全变成方块，原因是 Axure 导出时没勾选嵌入字体，从此提交前必做三件事：换一台没装设计的电脑解压并双击 index.html、用手机流量重新下载一次压缩包、核对文件数。这份流程不能保证不翻车，但能保证翻车发生在家里而不是答辩现场。希望帮到你。

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