简介面向人机交互课程设计/大作业场景压缩包以社区食堂/企业订餐系统为项目案例整合了从需求分析、原型设计到展示答辩的完整作业链路适合计算机相关专业学生参考选题、搭建作品或梳理设计文档。压缩包共22个文件大小约17.62MB以docx文档为主涵盖需求分析、代码规范、命名规范、Git使用指南等说明同时包含pptx答辩演示、HTML原型入口、PDF模型理论、JPG图表等覆盖项目开发各阶段所需材料。内容中还嵌有订餐系统可交互原型、README辅助说明及相关目录结构便于理解人机交互设计如何落地为可演示作品。该资源已有4538人学习对需要快速完成人机交互大作业或完善现有方案的学生有较高参考价值。1. 从「人机交互设计大作业.zip」说起一门课、一套完整交付物人机交互设计大作业最折磨人的不是画原型而是搞不清一门课到底要交什么。这份以企业食堂订餐系统为背景的「人机交互设计大作业.zip」把需求分析文档、WBS 拆分图、模型和理论 PDF、订餐原型、演示 PPT 以及一套带 WEB-INF 的 web 示例全部打包在内。对正在做人机交互大作业的学生它是一份能对照梳理自己项目的结构参考对赶进度的小组它展示了从「用户需求」到「可点选 Demo」的完整链路。它不替你做设计决策但能把「这门课在考察什么」一次讲清楚用户建模、交互流程、可用性评估再加上工程协作规范——这四块恰好也是答辩时老师追问最多的四个方向。2. 拆开 zip 看家底七类文件的分工与先验货再动手拿到任何「xxx 大作业.zip」我都劝你先别急着解压跑代码。大作业包在网盘、微信、U 盘之间倒腾三五手是常态我见过太多次解压到一半报错、7-Zip 突然弹密码框、解压完目录全是乱码的情况。这三件事都发生在真正「动手」之前却直接决定后面所有工作能不能继续。所以第 2 章先干三件事验包、识伪加密、处理编码。2.1 先验货完整性、伪加密与中文乱码最稳的验包方式是用 7-Zip 先测一遍压缩包结构别直接双击# 测试压缩包完整性不写日志只看最终结果 7z t 人机交互设计大作业.zip # 或者用 Info-ZIP 的 unzip 做校验 unzip -t 人机交互设计大作业.zip7z t会逐条读取压缩包内每个文件条目的 CRC 值。如果输出里出现There are errors或missing zip entry字样说明包在传输或上传过程中已经损坏直接解压大概率缺文件。这种情况我的建议是别折腾修复工具——回到最初的下载源重新下载一次比任何修复脚本都靠谱这是血泪经验。如果7z t报错但 7-Zip 又能列出文件名只是打开时弹密码框而你确认这个包从来没设过密码那八成是遇到了 zip 伪加密。伪加密的本质是压缩包条目的「通用位标志」第 0 位被置 1文件本身并没有真正的加密头解压工具读到这个标志位就以为需要密码。先确认一下# 列出详细条目信息看每个文件的加密标志和压缩方法 7z l -slt 人机交互设计大作业.zip | grep -E Path|Encrypted|Method如果大量文件显示Encrypted 但Method一栏是Store或Deflate而不是AES-256基本可以断定是伪加密。修复思路很直接把本地文件头和中央目录里的加密标志位清掉。下面这段脚本只做一件事——遍历 zip 里所有的PK\x03\x04本地文件头和PK\x01\x02中央目录头把头部偏移 6 处的通用标志位第 0 位清零import struct import sys def clear_fake_encryption(src, dst): with open(src, rb) as f: data bytearray(f.read()) # 本地文件头 PK\x03\x04 与中央目录头 PK\x01\x02 # 两者的通用位标志都位于头部偏移 6 处占 2 字节 for sig in (bPK\x03\x04, bPK\x01\x02): pos 0 while True: pos data.find(sig, pos) if pos -1: break flag_off pos 6 if flag_off 2 len(data): flags struct.unpack(H, data[flag_off:flag_off 2])[0] if flags 0x0001: # 第 0 位是加密标志 data[flag_off:flag_off 2] struct.pack(H, flags 0xFFFE) pos 1 with open(dst, wb) as f: f.write(data) if __name__ __main__: clear_fake_encryption(sys.argv[1], sys.argv[2])用法是python3 fix_zip.py 人机交互设计大作业.zip 输出.zip。逻辑说明zip 格式里本地文件头和中央目录头的通用位标志位置固定脚本按签名逐条定位、逐个清位不会动文件内容数据。参数说明第 0 位0x0001是加密标志 0xFFFE表示把这一位写成 0 而保留其他位。注意这个脚本会把所有加密位全部清掉所以只适用于「你确定这个包没有真实密码」的场景。如果压缩包确实被密码保护过清完标志位解压出来也是损坏的文件没有后悔药。还有一类高频问题是中文乱码。Windows 上默认压缩工具产出的 zip文件名常是 GBK 编码在 Linux 或 macOS 上直接unzip会看到一堆乱码目录名。Info-ZIP 的 unzip 支持指定编码unzip -O GBK 人机交互设计大作业.zip -d 输出目录macOS 自带的 unzip 未必带-O参数装过 Homebrew 的话brew install unzip换一个或者干脆用 7-Zip 解压多数情况能自动识别。这一步做完文件层面才算真正可用。2.2 documents 文件夹四份文档各管一段交付解压干净之后根工程目录是human-computer-interaction-master核心内容集中在documents子目录。整体结构大概是human-computer-interaction-master/ ├── README.en.md ├── documents/ │ ├── 企业食堂订餐系统.pptx │ ├── 订餐系统需求分析.doc │ ├── WBS.jpg │ ├── git使用指南.docx │ ├── 文件命名规范.docx │ ├── 代码规范.docx │ ├── 模型和理论.pdf │ ├── Diary │ └── presentation_template.pptx ├── 订餐系统_原型1.zip └── web/ ├── WEB-INF/ ├── index.html └── README.md这份大作业的文档设计很有代表性四样东西正好对应 HCI 课程考核的四个维度文件对应考核点答辩时大概率被问订餐系统需求分析.doc用户建模与需求挖掘「你的目标用户是谁依据是什么」WBS.jpg项目规划与工作量拆分「这个任务为什么拆成这些阶段」模型和理论.pdf理论是否落到设计「你用的启发式评估是第几条」命名规范 / 代码规范 / git 指南工程协作能力「组员怎么合代码提交记录规范吗」很多小组把需求分析写成功能清单这是最典型的翻车姿势。需求分析文档的正确打开方式是回答三个问题谁在用角色、在什么场景下用情境、遇到什么问题痛点功能只是推导出来的结果。后面第 3 章我会把「场景推导功能」的写法展开讲。2.3 过程类文件Diary 和规范文档是隐性加分项documents 里还有两个容易被忽略的文件Diary和几份规范 docx。Diary 在人机交互课程里一般叫设计日志记录的是每周「做了什么、为什么这么做、遇到了什么阻力」。别小看它老师在判定「这是不是从别人工程里改的」时最看重的就是过程记录。哪怕你现在才补也建议按「时间 决策 理由」三段式补每段 35 句就够重点是写出决策理由。文件命名规范.docx和代码规范.docx是最容易被当成凑数文件的材料。实际上它们决定了小组协作能不能顺利多人合包时如果命名不统一原型最终版_v3_really_final.zip这种文件名一多光对齐版本就能耗掉一个晚上。我一般建议小组在第一天就定死三件事文件命名用「模块名_日期_作者」、代码缩进统一、commit message 带前缀feat / fix / docs。3. 把需求分析写成能答辩的东西食堂订餐系统的设计链路这一章是整个项目包的灵魂企业食堂订餐系统的人机交互设计链路。我按「需求 → 理论 → 拆解 → 原型」四步走每一步都能在documents里找到对应的材料。重点不是照抄原包内容而是把「为什么这么做」讲出自己的逻辑。3.1 需求分析文档的四个段落角色、场景、痛点、功能打开订餐系统需求分析.doc先看它有没有按「背景 → 用户 → 场景 → 功能」组织。一份能过答辩的需求分析至少要能填出下面这张表用户角色核心场景一句话痛点推导出的功能企业员工午间 10 分钟窗口期完成选餐排队久、选择困难菜品分类筛选、预下单、一键复购食堂管理员备餐前拿到准确订餐量备多浪费、备少不够订单汇总看板、份数统计财务人员月末核对餐补对账靠手工 Excel补贴额度、导出报表注意这张表的阅读方向是从左往右每个功能都必须能从「场景 痛点」推导出来而不是拍脑袋想的。答辩老师最爱问的一句就是「这个功能你为什么做」如果你能当场指回「因为财务月末对账要花两天」这个问题的分数就拿到了。如果原来的 doc 里没有用户角色表按下面这种结构补一段进去就够用## 1. 用户角色与场景 ### 1.1 企业员工高频用户 - 场景工作日 11:50 午休10 分钟内完成选餐 - 痛点窗口排队 15 分钟菜品选择困难 - 功能菜品分类、预下单、一键复购逻辑说明每一段都遵循「角色 → 场景 → 痛点 → 功能」的推导链。参数说明高频用户这类标记词决定了功能优先级答辩时可以说「我们优先保障高频场景所以预下单放在主流程首页而报表导出放在二级页面」。食堂订餐的场景非常成熟角色边界清楚很适合做 HCI 大作业——这也是原包选它的原因。你只需要把角色换成自己系统的实际用户推导链完全可以复用。3.2 模型和理论.pdf 怎么落进设计模型和理论.pdf 里通常涵盖尼尔森十大可用性启发式、诺曼设计原则、心智模型这类 HCI 核心理论。大作业拿高分的关键不是把十条理论背下来而是每条理论都能指到一个具体界面设计上。下面是我从原包原型里读出来的几组对应关系理论一句人话落到食堂订餐系统的具体位置尼尔森第 1 条系统状态可见性用户点了任何东西都要有反应加入购物车后角标 1提交后显示「已受理」诺曼反馈与映射操作和结果要对得上点「提交订单」后出现取餐码而不是停留原页面心智模型流程要符合用户对「订餐」的已有预期选菜 → 确认 → 支付 → 取餐码不要跳步希克定律选项越多决策越慢菜品分类不超过 5 类首页只露出高频套餐菲茨定律目标越大越容易点中「提交订单」按钮加大取餐码使用大号字体拿「取消订单」举例订单确认页必须有明确的取消入口而且取消之后要有确认弹窗——这对应尼尔森第 3 条「用户控制和自由」用户误操作后需要一条逃生通道。这种「理论 → 界面」的映射在答辩 PPT 里一页放一条比放十页理论截图有用得多。理论段还有一个用途写可用性评估。答辩时可以说「我们请了 3 位同学按尼尔森启发式逐条走查原型发现状态可见性不足于是加了购物车角标和订单状态条」。这句话同时用上了理论 PDF 和原型两份材料信息量很大。3.3 WBS 拆分把大作业拆到能按天收工WBS.jpg是工作分解结构图。HCI 大作业的 WBS 不用拆到文件级拆到「工作包」级就够关键要让老师看出你有规划意识。参考原包的拆分逻辑我建议按四个工作包分配精力工作包交付物建议时间占比完成标志需求分析需求分析.doc 用户角色表25%每个功能都能追溯到场景原型设计订餐系统_原型1.zip40%主流程 4 步可完整点通演示与答辩企业食堂订餐系统.pptx25%10 分钟讲完且留 3 分钟提问工程规范命名规范、git 指南、Diary10%组员合包无冲突注意 WBS 的拆分粒度拆到「原型设计」这一层是合适的。如果你把「原型设计」继续拆成「画登录页」「画菜品页」「画订单页」反而会把自己困在细节里。粒度太细的 WBS 在课程作业里会被质疑「工作量注水」——老师一眼就能看出这是为了拆而拆。正确的做法是每个工作包都对应一个「完成标志」而不是一堆没有验收标准的动作。3.4 从原型 1 到可演示原型迭代的三个版本意识订餐系统_原型1.zip的命名说明它只是第一版原型。真正能撑起答辩的原型迭代至少要有三个版本意识低保真线框画信息架构、高保真静态定视觉、可交互原型跑流程。原包里的原型 1 属于「可交互」那一档它重点不是漂亮而是主流程能点通。如果原型是用工具导出的Axure 或墨刀常见做法导出后通常是一堆 HTML 文件如果老师要求现场演示我建议把最关键的主流程做成 4 个画面以内的演示链路首页选餐 → 确认订单 → 支付成功 → 取餐码。这 4 步对应第 4 章 web 目录里的页面结构也对应 3.2 里那张「心智模型」行——主流程越短越符合用户预期。4. 让评审看到能点的 Demoweb 目录与本地启动web目录是整个压缩包里唯一能「跑起来」的东西也是答辩时最容易出状况的地方。很多小组在这里翻车现场双击 index.html 页面白屏或者报错 404。原因多半是没搞清这个目录到底是静态原型还是 Java Web 工程。4.1 先判断是静态原型还是 Java Web 工程看目录结构就能判断如果web下只有index.html、README.md和图片素材那是纯静态原型双击就能开如果出现了WEB-INF目录就要再往里看一层。WEB-INF是 Java Web 应用的标准目录里面通常有web.xml如果有classes或lib子目录说明这是一个 JSP/Servlet 工程必须用 Tomcat 才能跑。在课程原型场景下WEB-INF更可能只是工程结构的复刻——静态页面放在WEB-INF外的根目录WEB-INF里只放说明或配置。判断方法很笨但有效# 检查 WEB-INF 里有没有编译产物和配置 find web/WEB-INF -type f | head -20如果WEB-INF下只有一个web.xml或者干脆是空的那把它当成静态站处理就行如果出现classes目录或一堆.class文件就得走 Tomcat 路线。千万不要直接双击WEB-INF下的页面——WEB-INF是被 Servlet 容器保护的目录任何 Web 服务器都不会直接把里面的文件发给浏览器这是它存在的意义。4.2 三种启动方式按你的答辩环境选我一般按现场条件选启动方式。最省事的是 Python 自带的 HTTP 服务器cd web python3 -m http.server 8080 # 浏览器打开 http://localhost:8080/index.html这种方式适合静态原型一行命令起服务断网也能跑。如果演示机器没有 Python用 Node 的npx serve或者把目录扔进 VS Code 的 Live Server 插件都行。如果确认是 Java Web 工程需要走 Tomcat# 把整个 web 目录复制到 Tomcat 的 webapps 下 cp -r web /path/to/apache-tomcat/webapps/hci # 启动 Tomcat 后访问 http://localhost:8080/hci/index.html这里最容易踩的坑是端口冲突和路径大小写。8080 被占用时改conf/server.xml里的 Connector portwebapps/hci这个上下文名在 URL 里必须和目录名完全一致大小写都不能差。答辩现场网络是玄学所以我强烈建议本地起服务后先把关键页面截图存一份在 PPT 里万一现场起不来至少有图可讲不冷场。提示演示前先确认访问的是webapps根目录下的index.html而不是WEB-INF内部的页面。后者的访问会被服务器直接拒绝。4.3 index.html 里的主流程三步走完一个订单web 目录的 index.html 如果按「选餐 → 确认 → 结果」三个区块组织说明原型的交互设计是过关的。典型结构长这样!DOCTYPE html html langzh-CN head meta charsetUTF-8 title企业食堂订餐系统 - 演示/title /head body !-- 顶部状态栏对应「系统状态可见性」 -- header classtop-bar span今日供应两荤两素 例汤/span span工号 1024余额 ¥86.50/span /header !-- 主流程三个区块对应三步hidden 控制显隐 -- main classorder-flow section idstep-menu !-- 菜品卡片列表点击加入购物车 -- /section section idstep-confirm hidden !-- 订单明细支持修改数量与取消 -- /section section idstep-done hidden !-- 支付结果与取餐码 -- /section /main /body /html三个section用hidden属性做页面内切换这是静态原型模拟多页流程最常见的做法好处是不跳转、不会 404坏处是刷新会回到第一步——演示时手指不要碰到刷新键。如果想在页面内加「加入购物车」和「下一步」的切换逻辑纯前端就够了// 三步切换选餐 → 确认 → 结果 const steps [step-menu, step-confirm, step-done]; let current 0; function goTo(index) { steps.forEach((id, i) { document.getElementById(id).hidden i ! index; }); current index; } // 事件委托点击带 style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />
