图书馆智能温度感知系统
一个融合 IoT 硬件传感器、双端 Web 界面与云端架构的空间环境感知系统——通过用户调研驱动的迭代设计，把不可见的「热微气候」变成可看的信息，帮学生快速找到舒适的学习位置。
项目背景 & 目标用户（Why）
看不见的「热微气候」
图书馆开放式学习空间存在明显的「热微气候」——同一楼层不同区域温差显著，有些角落过冷，有些位置闷热。学生花费大量时间反复换座试错，却无法在入馆时快速判断哪个区域更舒适。更重要的是，传统空调系统采用单一温控设定，无法满足不同人群的差异化需求（研究表明，温度对不同性别的认知表现影响存在差异）。
问题的本质不是「温度控制」
软硬件一体的温度感知与反馈系统
通过 IoT 传感器实时采集各区域温度，LED 灯带在物理空间中直观显示冷热状态，大屏在图书馆大厅展示整层温度热力图，学生扫码进入移动端查看详情并提交冷热反馈。让温度「可见」，让选座「有据可依」。
目标用户
| 用户群体 | 特征 | 核心需求 |
|---|---|---|
| 长时间学习的大学生 | 日均图书馆学习 2-6 小时，对环境敏感 | 快速找到温度舒适的座位 |
| 图书馆运营管理方 | 需要数据支撑设施决策 | 根据有效反馈数据，优化空调策略 |
使用场景
学生入馆选座、长时间学习期间的舒适度反馈、图书馆设施管理参考。
设计过程（How）——从用户调研到 3 轮迭代
用户调研 → 需求洞察
调研方法：半结构化访谈 + 现场观察（Contextual Inquiry）
对来自不同院系的学生进行深度访谈，了解他们在图书馆中的环境体验。关键发现：
- 温度是影响学习体验最直接的因素，但用户缺乏感知渠道——「每次都是坐下来才知道冷不冷」
- 学生有各自的应对策略（带外套、换楼层），但都是「试错型」行为，缺乏信息支撑
- 图书馆现有信息屏内容静态，缺乏实时性和交互性
亲和图分析（Affinity Diagram）：将访谈数据编码归纳为三大主题——环境舒适度、学习氛围、空间设施需求。其中「温度不均且不可见」被识别为最核心的痛点。
问题定义 & 概念生成
团队头脑风暴产出 4 个方向：温度反馈系统、安静氛围提醒、遗失物提醒、Workshop 展示平台。经评估与导师反馈，选择智能温度感知与反馈系统——因为它最直接回应了调研中发现的核心用户需求。
技术验证 & 概念收敛
制作简易温度探测器，验证 ESP32 传感器 → LED 灯带 → Web 页面的数据通路是否可行。同时在 Figma 上完成初版界面设计。
发现的问题：LED 颜色在明亮环境中不易辨认；按钮功能语义不清晰。
完整系统实现 & 正式用户测试
目标是实现可运行的完整系统。
技术实现：
- 前端：React 框架开发大屏端（展示温度热力图 + 用户反馈汇总）和移动端（扫码查看详情 + 提交反馈）
- 硬件：组装 3 个传感器节点，1 个完整模块（含 LED + 物理按键），2 个数据采集节点
- 后端：Python 构建，实现传感器数据实时同步至 Web 端
- 架构升级：从本地服务器迁移到 AWS 云部署——解决了 ESP32 无法直接与云端通信的技术难题，重新设计了数据上传链路
用户测试（6 名长时间学习的学生）：
- Think-Aloud（思维出声）：用户边操作边说出想法，实时捕捉交互中的困惑
- Day Reconstruction（日重建）：用户在一天学习结束后回顾整体体验，获取跨时段的舒适度变化反馈
测试发现的 8 个核心问题：
| 编号 | 问题 | 来源 |
|---|---|---|
| 1 | 地图未展示完整楼层布局 | Think-Aloud |
| 2 | 按钮操作不符合用户预期（以为能调温度） | 用户反馈 |
| 3 | 按钮颜色不清晰，无法区分冷热 | Think-Aloud |
| 4 | 用户无法在地图上定位自己 | Day Reconstruction |
| 5 | 二维码用途不清晰，缺乏引导文字 | Think-Aloud |
| 6 | 反馈数字被误读为温度值 | 用户反馈 |
| 7 | LED 灯带缺乏颜色图例 | 观察 |
| 8 | 移动端与大屏数据不同步 | 技术测试 |
针对性迭代 & 最终交付
基于用户测试结果，对影响最大的问题进行定向修复：
- 反馈闭环强化：重写硬件控制代码，按下按钮后 LCD 屏幕即时显示「提交成功」，LED 灯带同步切换颜色，形成可见的反馈确认
- 语义优化：将按钮重新设计为直观的红色（太热）和蓝色（太冷），一眼可理解
- 信息层级优化：网页端加入解释文字和冷热图标，区分「反馈数量」和「温度数值」的视觉层级
- 数据同步修复：修复 API 接入错误，确保大屏与移动端读取同一数据源
产品设计（What）
系统架构
系统由三个核心端构成，形成「感知—展示—反馈」的完整闭环：
硬件端（传感器 + LED + 按钮） → Python 后端（AWS 云） → Web 前端（大屏 + 移动端）核心交互流程
入馆感知（大屏端）
- 学生在图书馆大厅看到温度展示大屏，热力图直观展示各区域冷热分布
- 汇总的用户反馈数据让温度信息更具可信度
深度查看（移动端）
- 扫描二维码进入移动端页面，查看各区域详细温度数值
- 可查看其他用户的冷热反馈数据，辅助选座决策
体验反馈（硬件端 + 移动端）
- 在座位旁的硬件终端按下红 / 蓝按钮，表达「太热 / 太冷」
- 移动端也可直接提交反馈，形成多渠道反馈入口
- 反馈数据实时更新到大屏和移动端，形成数据闭环
运营参考（管理端）
各区域温度趋势和用户反馈汇总，可为图书馆空调策略调整提供数据依据。
我的工作
跨领域协调与项目管理
作为 6 人团队的负责人，主导项目从调研到交付的全流程：
- 产品方向定义：在 4 个候选方案中，基于调研数据主导选择了温度感知方向，因为它最直接回应核心用户痛点
- 跨领域协调：团队涉及硬件（ESP32 / 传感器 / 3D 打印外壳）、前端 Web、后端云服务三个技术域，我负责协调各模块的接口定义、开发节奏和联调计划
- 用户测试组织：主导 2 轮用户测试的方案设计、参与者招募和结果分析，将测试发现转化为明确的迭代优先级
- 任务分配与协调：根据组员擅长内容，分配任务，组织和主持会议
从调研到关键决策
- 用户调研与洞察提炼：主导半结构化访谈和现场观察，通过亲和图分析提炼出「温度不可见是核心痛点」这一关键洞察
- 关键设计决策：推动按钮从「控制工具」到「感受记录」的功能重定义——这不是简单的功能调整，而是对产品核心价值的重新定义
- 评估方法选择：选择 Think-Aloud（捕捉即时困惑）+ Day Reconstruction（捕捉长时段体验变化）的组合方法，匹配了图书馆「长时间停留」的场景特征
React 双端 + 架构迁移
- 双端前端架构：基于 React 构建大屏展示端和移动端两套界面，大屏端侧重热力图可视化，移动端侧重交互和反馈
- 技术方案决策：评估团队能力后，推动 CSS 方案从 Sass 切换到 TailwindCSS，提升开发效率
- 架构迁移：参与推动系统从本地服务器到 AWS 云端的架构升级，修改前端数据源配置，实现跨设备实时访问
技术亮点
| 技术点 | 实现方式 | 解决的问题 |
|---|---|---|
| IoT 数据采集 | ESP32 温度传感器 + 物理反馈按钮 | 实时采集各区域温度，并在物理空间中直观展示冷热状态 |
| 双端 Web 界面 | React（大屏端 + 移动端） | 大屏提供全局视图吸引注意，移动端提供详情和反馈入口 |
| 云端部署 | Python 后端 + AWS | 从局域网到云端的架构升级，实现设备上电即可远程访问 |
| 多渠道反馈 | 硬件按钮 + 移动端表单 | 降低反馈门槛，硬件端「一按即达」，移动端「随时可提交」 |
| 三端通信 | 后端 API 串联前端与硬件端 | 优化用户体验的过程，减少交互的割裂感 |
反思与收获
做得好的地方
- 用户调研驱动设计：从访谈中提炼出「温度不可见」的核心洞察，确保产品方向与真实需求对齐，而非基于团队假设
- 按钮功能的重新定义：当发现「控制温度」不可行时，没有放弃按钮设计，而是将其重新定义为「感受记录」——体现了设计思维中「约束即机会」的理念
- 评估方法与场景匹配：选择 Think-Aloud + Day Reconstruction 的组合，精准匹配了图书馆长时段使用的场景特征，获得了更全面的用户反馈
- 跨领域技术协调：作为 PM 协调硬件、前端、后端三个技术域的开发，确保各模块接口对齐、按时联调
可以改进的地方
- 硬件外壳的原型策略：过早投入 3D 打印，未先用低保真材料（纸盒 / 泡沫板）验证尺寸和装配，导致大量返工。教训是：物理原型同样需要从低保真开始
- 展示前的风险管理：最终展示前一小时仍在调试硬件适配，反映了在「功能完善」和「外观精致」之间的优先级判断不够果断。在有限时间内，核心交互的稳定性永远优先于形式上的完整
- Prototype 3 评估不够充分：由于时间限制，Prototype 3 仅做了团队内部走查，未再组织正式用户测试。理想情况下应至少做一轮快速验证，但是在最终展览上也算是完成了最后一轮评估