An interactive IEQ dashboard that helps office managers detect ventilation problems before staff ever need to complain.
Modern buildings track dozens of comfort metrics continuously — temperature, CO₂, airspeed, humidity — yet most office managers only hear about problems after staff complain. By then, the discomfort has persisted for hours, productivity has already taken a hit, and whatever caused it has often become harder to fix.
Breath of Fresh Air turns raw IEQ (Indoor Environmental Quality) sensor data from the University of Sydney's SAMBA system into a clear, scannable dashboard — designed specifically for the non-technical office manager who needs answers at a glance, not a spreadsheet.
The IEQ Lab's SAMBA system captures 10 environmental metrics every 5 minutes across multiple floors, for a full year. That's an extraordinary volume of data. But without clear visualisation, it's invisible to the people who need it most.
"Although the IEQ Lab's SAMBA system continuously captures airflow, CO₂, and other comfort metrics every five minutes across all office zones, without clear, easy-to-digest visualisations, office managers can't detect under-ventilated areas until staff complain — by which time the problem has persisted, causing discomfort, health risks, and expensive emergency interventions."
External research backed this up — a 2016 study by Allen et al. found that cognitive performance in better-ventilated spaces was measurably higher: workers in "Green+" environments scored over 100% better on cognitive tests than those in conventional offices. The stakes aren't abstract.
I focused on three zones (48, 49, 50) from the SAMBA dataset — a full year of five-minute readings per zone. After running exploratory analysis in Tableau, five variables emerged as most meaningful for comfort monitoring:
Two key correlations shaped the entire dashboard design. First, there's a clear inverse relationship between CO₂ and airspeed — when airflow improves, CO₂ drops. Second, temperature and PMV track closely — warmer air reliably pushes PMV higher (towards "too warm"). These relationships aren't just interesting; they mean a manager who fixes airflow often fixes multiple metrics at once.
My target user is an older office manager — someone who values getting things done, not learning a new interface. Two research-backed principles shaped every choice:
Large fonts, big visuals. Rello et al. (2016) found comprehension improved significantly at font sizes 18+ — so I leaned into large numbers, bold gauges, and spacious layouts rather than information density.
Familiar contextual cues. The colour system was directly inspired by the NSW Fire Danger Rating signs — one of the most universally understood severity scales in Australia. Red means bad. Green means good. Nobody needs to learn it.
The dashboard lives on a single screen — no tabs, no drill-down navigation. A severity score gives an at-a-glance number. Gauge charts show the three key metrics. A zone map visualises spatial distribution. A monthly calendar lets managers track trends over time. Everything a manager needs is visible without scrolling.
After A1 feedback, I had a clear brief for what was missing: stronger call-to-action design and clearer interpretation aids. Here's how the design evolved:
Early Sketch → Initial Prototype
Hand-sketched layout with semicircle gauges for Temperature, CO₂, and Air Speed. Zone dropdown selector, severity score, time/date sliders, and a report/share CTA. Two views: detail panel and building floor map.
A1 Feedback → Key Changes
Added a "Today's Dashboard" status panel with live Current Status summary. Moved the zone map to the main screen. Improved gauge styling using Plotly.js with colour-coded arcs and labelled thresholds.
Usability Testing → Final Polish
Added "ⓘ" tooltip icons across all components. Introduced plain-English labels below gauges ("Comfortable", "Drafty", "Still"). Updated severity score with emoji and colour shifts. Improved spacing, contrast, and calendar interaction.
Testing ran in two rounds. The first — 3 design students — validated early prototype choices from A1 feedback. The second was more rigorous: 10 participants including 4 non-design adults representing the actual target audience of office managers.
Each participant completed three tasks:
Large numbers landed immediately
Even the adult participants grasped the severity score and gauge values without prompting. The single-page layout reduced navigation confusion to zero.
Colour system was universal
All participants correctly identified red as "bad" and green as "good" without any instruction — the Fire Danger Rating inspiration paid off.
Thresholds weren't obvious
Several participants didn't know whether 26°C or 567 ppm CO₂ was "acceptable". The visual was clear; the benchmark wasn't.
PMV was unfamiliar jargon
Non-design adults consistently paused at PMV. The label alone wasn't enough — context was needed.
The colours and smiley face helped, but I didn't know what number was considered too high for CO₂ or Air Speed.
— Usability testing participant
In response, I added tooltip "ⓘ" icons to every metric, plain-English labels under each gauge, and a "Did You Know?" callout in the sidebar that surfaced contextual facts (e.g. "Air speed below 0.1 m/s is considered still — try improving circulation!").
The biggest gap wasn't between the data and the interface — it was between my understanding of the data and the user's. I knew what 600 ppm CO₂ meant; my participants didn't. Usability testing made this gap impossible to ignore, and it's the kind of thing you simply cannot catch by testing with design students alone.
The Fire Danger Rating insight came early and held up throughout. When you anchor a new interface to something people already trust, you eliminate a whole category of confusion. Context borrowed from the real world is worth more than any custom icon system.
I also got more comfortable with Plotly.js than I expected. Working through async data loading, dual-axis graphs, and responsive gauge layouts taught me a lot about how data visualisation libraries actually behave in a browser — which is messier and more specific than the docs suggest.