QBUS5010 26S1｜Week 5交设计稿时你还没学会怎么做

这门课的考核设计藏着一个时间陷阱——Week 5 要交 30% 的 Individual Report，内容是给一个场景设计 Dashboard 的完整方案。问题在于，这个时候你只学了可视化理论（什么图表适合展示什么数据、用户体验原则、怎么吸引注意力），但完全没碰过 Dashboard 的实现技术。Web 和 Dashboard Technology 要到 Week 6-8 才开始教，Week 7 才第一次在 Tutorial 里动手做 Dashboard。

换句话说，Week 5 的设计稿要求你画出一个「理论上完美」的方案，但你根本不知道这个方案能不能实现、实现起来有多难。这不是让你先学理论再实践，而是让你在不知道约束条件的情况下做设计——就像让一个没开过车的人设计赛道。

📝 考核结构的时间错位

这门课的 4 个作业是这样排列的：

Individual Report 是第一个大作业，占 30%，看起来是让你展示「设计思维」和「用户体验理解」。但这个作业的真正难点不是理论，而是你不知道自己设计的东西能不能做出来。Week 5 时你只学了：Week 1 可视化背景和 Python 入门，Week 2 数据结构和数据处理，Week 3 可视化类型和 Plotting，Week 4 注意力捕捉原则和更多数据处理，Week 5 用户体验和更多 Plotting。

这些内容教你怎么选图表、怎么让用户看懂、怎么用 Python 画静态图。但 Dashboard 不是静态图——它是一个交互式的 Web 应用，需要处理实时数据、响应用户操作、在浏览器里跑起来。这些技术要到 Week 6（Web and Dashboard Technology 1）才开始讲，Week 7 Tutorial 才第一次让你用 Python 做一个能交互的 Dashboard 原型。

结果就是，Week 5 交设计稿的时候，你根本不知道「让用户点一下就切换图表」这个功能实现起来要写多少代码、会遇到什么坑。你以为自己设计了一个完美方案，到 Week 12 做 Group Project 的时候发现这个设计根本做不出来，或者做出来要花三倍时间。

💡 为什么会这样设计

这个时间安排不是失误，而是故意的。课程设计者想让你经历一次「理想与现实的碰撞」——Week 5 的时候你会画大饼（"我要做一个超炫的交互式地图，用户可以点击任意区域查看详细数据"），Week 7 开始学实现技术的时候你会发现现实没那么简单（"原来光是让地图显示出来就要配置这么多东西"），Week 12 做 Group Project 的时候你终于学会了权衡（"交互太复杂会拖累性能,核心功能够用就行"）。

但这个「教育意义」对你的分数没有帮助。Individual Report 占 30%，评分标准是「设计的合理性」和「对用户体验的理解」,不是「设计的可实现性」。也就是说,Week 5 交上去的方案可以天马行空,只要理论上说得通就能拿分。问题是到了 Week 12,Group Project 占 40%,评分标准变成了「Dashboard 能不能跑起来」「功能是否完整」「代码质量如何」——这时候你会发现 Week 5 设计的那些东西根本做不出来,或者做出来要砍掉一半功能。

更要命的是,Week 8 的 Project Evaluation（占 20%）要求你「评估一个现有 Dashboard 的设计并提出改进建议」。这个作业的 due 时间是 Week 8,刚好是你学完 Web and Dashboard Technology 三周课程之后。这意味着你要用刚学到的实现知识去回头看别人的设计,然后你会发现:「原来那些看起来很炫的功能背后要处理这么多技术细节」「这个设计表面简洁,实际上数据处理逻辑非常复杂」。

这三个作业连起来就是一个完整的认知升级循环:Week 5 你不知道约束,设计会偏理想化→Week 8 你学了实现,开始理解约束→Week 12 你要把理想和现实结合起来,做出一个既符合设计原则又能实际运行的 Dashboard。但问题在于,这个循环里的每一步都要交作业、都要占分,而你在 Week 5 的时候根本没有后面两步的认知基础。

🎬 前半学期要做什么

Week 1-5 的内容看起来是打基础,实际上是在铺垫 Individual Report 需要的理论框架。每周的 Lecture 教理论,Tutorial 教对应的 Python 实现,但这些实现都是「单个技能点」的练习,不是「完整系统」的构建。

Week 1 教 Visualisation Context（可视化的应用场景、设计原则）和 Python Introduction 2（变量、循环、函数）。Tutorial 是 Python Introduction 1（更基础的语法）。这周的作用是让你理解「Dashboard 是用来解决什么问题的」,不是让你动手做。

Week 2 教 Data Structure（数据怎么组织、怎么存储）和 Data Handling with Python 1（用 Pandas 读取和处理数据）。Tutorial 是 Python Introduction 2。这周开始接触真实数据,但还是在做「读一个 CSV 文件,筛选几行,算个平均值」这种单点操作。

Week 3 教 Visualisation Types（柱状图、折线图、散点图各适合展示什么）和 Plotting with Python 1（用 Matplotlib 或 Seaborn 画图）。Tutorial 是 Data Handling with Python 1。这周你会做很多「给一堆数据,画一个图」的练习,但这些图都是静态的、孤立的,跟 Dashboard 的交互式、集成化完全不是一回事。

Week 4 教 Capturing Attention（怎么用颜色、布局、动画吸引用户注意力）和 Data Handling with Python 2（更复杂的数据清洗和转换）。Tutorial 是 Plotting with Python 1。这周的理论开始偏「设计」而不是「技术」,但你还是在画单张图,没有碰「把多个图组合成一个系统」的问题。

Week 5 教 User Experience（用户怎么理解信息、怎么设计交互流程）和 Plotting with Python 2（更高级的图表定制）。Tutorial 是 Data Handling with Python 2。这周结束之后你要交 Individual Report,内容是「给定一个场景（比如一个电商公司要监控销售数据）,设计一个 Dashboard 方案,包括用什么图表、怎么布局、用户怎么操作」。

你会发现,Week 1-5 的 Lecture 教了很多「为什么这样设计」的理论,Tutorial 教了很多「怎么用 Python 做单个操作」的技能,但从来没有教过「怎么把这些操作串起来变成一个能跑的系统」。Week 5 交设计稿的时候,你可以基于理论写出「用户点击地区下拉菜单,右边的柱状图自动更新显示该地区的销售数据」,但你不知道这个「自动更新」背后要怎么实现、会遇到什么技术限制。

⚠️ Individual Report的真正难点

这个作业的官方描述是「practice design thinking, user experience and visualisation skills by creating a design brief for a dashboard」。听起来是让你展示「设计思维」,实际上是在考验你能不能在信息不完整的情况下做决策。

Week 5 的时候你只学了「静态可视化」的技能——给一堆数据,选一个合适的图表类型,用 Python 画出来。但 Dashboard 的核心是「动态交互」——用户改变筛选条件,图表要实时更新；用户点击某个数据点,要弹出详细信息；多个图表之间要联动（点击地图上的一个区域,旁边的柱状图和折线图同步显示该区域的数据）。

这些交互功能不是「画图」能解决的,而是要用 Web 技术实现。具体来说,你需要:用 HTML/CSS 搭建页面布局,用 JavaScript 或 Python 的 Dashboard 框架（比如 Plotly Dash 或 Streamlit）处理用户操作,用回调函数（Callback）让图表根据用户输入动态更新,用数据库或 API 管理数据源。这些内容要到 Week 6-8 才教,Week 5 的时候你对这些技术一无所知。

结果就是,Individual Report 要求你设计一个「理论上完美」的方案,但你不知道这个方案实现起来有多复杂。你可能会设计一个「用户可以拖拽图表重新排列布局」的功能,听起来很炫,实际上这个功能要处理拖拽事件监听、布局重新计算、状态保存——对于 Week 7 刚开始学 Dashboard 的人来说,这个功能可能要花一周时间才能做出来。

更隐蔽的问题是,Week 5 的设计稿会影响你 Week 12 的 Group Project 思路。很多人会倾向于「把 Week 5 设计的方案在 Group Project 里实现出来」,但到那时候你会发现原来的设计要么太复杂做不完,要么技术上不可行需要大改。与其到 Week 12 推翻重来,不如在 Week 5 设计的时候就故意保守一点——只设计你确定能实现的功能,把那些「理论上很酷但不知道怎么做」的想法先放一边。

但这样又会丢分,因为 Individual Report 的评分标准里有「creativity」和「innovation」。评分的人是老师或助教,他们知道怎么实现,他们看到一个保守的设计会觉得你「没有充分展示设计思维」。所以这个作业的最优策略不是「设计得完美」,而是「设计得刚好够炫但又不至于完全做不出来」——但 Week 5 的你根本不知道这个边界在哪。

💰 组队决定40%

Group Project 占 40%,Week 12 交,内容是「做出一个能跑的 Dashboard + 一个演示视频 + 一份设计报告」。这个作业是小组完成,Week 8 的 Project Evaluation 实际上就是组队的开始——你们要选一个现有的 Dashboard 进行评估,这个选择会直接影响后面 Group Project 的方向（很多组会基于 Week 8 评估的 Dashboard 做改进或重新设计）。

Week 8 组队的时候,课程刚教完 Web and Dashboard Technology 的三周内容（Week 6-8）,你们对 Dashboard 的实现技术有了基本了解,但还没有做过完整项目。这时候组队,大家的技能水平差异会非常明显:有些人 Python 基础扎实,Week 1-5 的编程练习做得很顺；有些人之前完全没编程经验,Week 1-5 一直在补基础,刚勉强跟上进度。

更要命的是,Week 8 的时候你们还没学 Advanced Topics（Week 10-11 教的高级内容,比如复杂数据处理、性能优化、高级交互功能）。这意味着组队时你根本不知道队友在「做复杂功能」的时候能不能顶上来。可能你们在 Week 8 评估一个简单 Dashboard 的时候配合得很好,到 Week 10-12 真正开发的时候发现有人完全做不了复杂部分,最后变成一两个人扛全部代码。

而且这门课的 Group Project 不只是「写代码」,还包括「设计报告」和「演示视频」。设计报告要求你们解释「为什么这样设计」「用了哪些设计原则」「怎么保证用户体验」——这部分需要有人能把 Week 1-5 的理论和 Week 6-12 的实现结合起来讲清楚。演示视频要求展示 Dashboard 的功能、操作流程、设计亮点——这需要有人会做视频剪辑、配音、字幕。

所以 Week 8 组队的时候,不能只看「谁 Python 写得好」,还要看「谁理论理解得深」「谁能把技术翻译成设计语言」「谁有做展示的经验」。但 Week 8 的时候你们根本没时间互相深入了解,Project Evaluation 作业本身就要花时间做,组队基本上是「课上随机组」或「认识的人抱团」。

🎯 AI政策的真相

这门课所有作业都允许用 AI,看起来很宽松。但 Dashboard 这种东西,AI 能帮你写代码,不能帮你调试运行。你让 ChatGPT 写一个「用 Plotly Dash 做一个销售数据 Dashboard」,它能给你一段代码,但这段代码放到你电脑上跑,大概率会报错——可能是库的版本不对,可能是数据格式跟代码假设的不一样,可能是回调函数的逻辑有 bug。

Week 1-5 的 Homework 是编程练习,AI 能帮上忙,因为这些练习都是「给定输入,输出一个结果」的封闭问题。你把题目要求复制给 AI,它给你代码,你跑一下,对了就交,错了再让 AI 改。但 Week 6 之后的 Dashboard 开发是开放问题,没有「标准答案」,你要自己决定用什么技术栈、怎么组织代码、怎么处理边界情况。AI 能给你参考方案,但最终调试、优化、整合的工作还是要你自己做。

更关键的是,Week 12 的 Group Project 要录演示视频。视频里你要展示 Dashboard 的每个功能、解释设计思路、回答可能的问题。如果你的 Dashboard 是 AI 写的,你对代码逻辑一知半解,到做视频的时候你会发现自己讲不清楚「为什么这样实现」「遇到这个问题怎么解决的」。评分的人一看就知道你没有真正理解自己做的东西。

所以 AI 政策宽松不代表这门课轻松。它只是把难度从「写代码」转移到了「理解代码」和「整合系统」。Week 1-5 你可以靠 AI 刷 Homework,但 Week 6 之后如果你一直依赖 AI,到 Week 12 你会发现自己做不出一个能跑的 Dashboard,或者做出来了但完全讲不清楚原理。