Mezzo

Five semi-structured interviews with office workers across product, design, and engineering roles. All participants worked in open floor plans with return-to-office mandates. Interviews focused on meeting behavior, headphone use, volume awareness, and social dynamics around noise.

The room shortage is systemic, not incidental. One participant described submitting conference room shortage tickets daily for three weeks before giving up: "I think a lot of us have just gotten beaten down. We're like, okay, we'll just take meetings at our desks. It's fine." Desk meetings aren't a preference — they're the residue of infrastructure failure.

Social feedback operates on a gradient, not a binary. Participants described a range of signals: smiles from people who overhear and relate, unsolicited interjections into conversations, headphones going on silently, side-eye, audible sighs. Even the "positive" responses (smiling, commenting) signal that privacy has already been breached.

Volume awareness breaks down outside meetings too. Multiple participants described getting loud during informal desk conversations — not just headphone calls. One noted: "the more excited I get, the louder I get." The awareness gap extends to any animated exchange in shared space, confirming headphones as the most acute trigger, not the only one.

Content sensitivity compounds volume sensitivity. One participant described preferring to take a therapy call from her car rather than risk being overheard — a privacy concern layered on top of volume. The audience for this tool is already hyper-aware of being perceived. Design decisions that feel like surveillance would be disqualifying.

Self-selection confirmed from both sides. One participant said the tool sounded useful for others but not himself. Another asked: "I wonder if the biggest offenders would even be aware of their volume to try using this?" Both responses validate scoping to the considerate middle — people who want to adjust but lack feedback.

The earliest prototype functioned like a live volume meter — visualizing loudness continuously relative to a normalized range. Testing with five participants proved the concept was legible but revealed three structural problems.

The concept was immediately understood. Participants consistently described the system accurately: "It's measuring how loud you are." "It's keeping track of whether you're within your target range." Mental model clarity was not the issue. How the feedback behaved over time was.

Liveness and loudness were conflated. The prototype used the same visual channel for two different signals: is the system listening, and is the volume outside range? When feedback was subtle, participants couldn't tell whether nothing was happening or the system wasn't active. One noted: "It might be good to have another volume bar just so you know it's picking stuff up." → Led to the decision to separate liveness from escalation. The final system maintains a persistent listening state through gentle pulse animation and variant cycling, and only escalates visually when sustained deviation occurs. Supports Strategic Decision: Separated System Liveness From Loudness Feedback.

"Target volume" penalized natural voice variation. One participant had a naturally booming voice. Framing volume as a "target" implied a correct level — making louder voices inherently wrong. The framing shifted from preferred/ideal volume to: the speaking level you consider appropriate for the people around you. Calibration became contextual and user-defined, not normalized. Supports Strategic Decision: Expanded the "You're Fine" Range.

ARTIFACT: Calibration screen (calibration-landing.png) — Shows the reframed calibration copy: "Talk for a few seconds so Mezzo can learn the speaking level you consider appropriate for the people around you." Evidence that the "target volume" finding changed the actual product language.

Threshold tuning required a fundamental approach change. The original thresholds used absolute values (0.0009 range) — too narrow for real human variation. The system shifted to percentage-based multipliers (1.5x, 2x, 3x baseline) with a noise gate to filter silence during calibration. Early calibration also averaged ambient silence into the baseline, making thresholds too low. Fixing this required capturing speaking volume specifically during setup. Supports Strategic Decision: Expanded the "You're Fine" Range.

The architecture shifted from amplitude to containment. The early prototype directly mapped microphone input to continuous UI rendering — every fluctuation visualized, no distinction between liveness and escalation. The final system introduced a time-based state machine: the audio engine emits a single logical state (in range, out of range short, out of range sustained), and the UI renders only that state. The visual layer cannot read raw audio data or alter logic.

• Logic/UI separation — the audio engine emits only state; the UI cannot alter monitoring behavior
• Temporal escalation — brief spikes are ignored; escalation based on uninterrupted duration, not peak amplitude
• Distinct liveness channel — listening state always visible; escalation layered on top

ARTIFACT (HIGH PRIORITY): v1 → v2 architecture diagram — Two columns. Left: "Continuous Meter" (Mic Input → RMS → Normalized Scale → Continuous UI). Right: "Temporal State Machine" (Mic Input → RMS → Threshold Evaluation → State Machine → Single Logical State → UI Renderer). Arrow between them: "Shift from amplitude to containment." This is the strongest systems thinking evidence in the case study.

The visual metaphor evolved from deformation to ring stacking. The earliest visual concept explored an ink deformation model — a perfect circle that loses containment as volume increases, eventually spilling across the surface. While conceptually strong, deformation was illegible at small PiP sizes and felt jittery with real-time audio reactivity. The pivot to ring stacking — a stable base circle that gains concentric rings (ring-0 through ring-3) — preserved the containment metaphor while remaining legible across all window sizes. Light-to-dark surface inversion during sustained alerts provides the final escalation signal.

Distribution constraint forced a platform pivot. The browser extension required multi-day platform approval and produced inconsistent microphone permission flows across browsers. Rebuilding as a standalone web app with PiP capability eliminated both problems and enabled faster iteration within the 6-day timeline. Supports Strategic Decision: Pivoted From Browser Extension to Web App.

ARTIFACT: Mic permission screen (mic-permissions-needed.png or mic-permissions-needed-desktop.png) — Shows the trust copy at the first permission gate: "Mezzo listens only to volume, never to what you say. Nothing is recorded or saved." Evidence of trust design at the most sensitive interaction point.

PiP as container choice, not mode switch. The Document Picture-in-Picture API was chosen specifically because Mezzo needs to run during meetings without taking focus. Two PiP modes exist: compact (smallest possible window, circle fills the space, rings clip at edges) and expanded (mirrors the full card layout with heading, circle, button, microcopy). A resize observer detects which mode to render. The main tab shows a "Running in a mini window" screen with a status indicator while PiP is active. Monitoring continues uninterrupted regardless of container — PiP is a display decision, not a system state change.

ARTIFACT (HIGH PRIORITY): PiP states comparison — Three-up showing the same feedback state across containers: main tab (monitoring-within-range.png), compact PiP (pip-within-range.png), and the "Running in mini window" handoff state (picture-in-picture-running.png). Second row could show the outside-range states across PiP: pip-outside-range-2.png and pip-outside-range-3-sustained-blinking.png. Demonstrates that the same interaction model works at any size.

Logic–UI separation as an architectural constraint. The audio processing pipeline was treated as immutable throughout the build. The visualization component is a pure consumer: it accepts a volume level and a baseline, then handles ring selection, variant cycling, theme switching, and pulsation independently. This separation means the same component renders identically in the main tab, expanded PiP, and compact PiP. Changes to presentation never affect monitoring behavior.

Trust enforced through state management. Concrete implementation patterns that enact the ephemeral design posture:

• Monitoring runs in PiP or the main tab — never both simultaneously
• Closing PiP stops monitoring entirely; no hidden listening
• Calibration data is cleared on tab close; no persistent audio data
• Privacy microcopy appears on every screen: "Nothing is recorded or saved. Monitoring stops when you close this tab."
• The landing page is completely static — no microphone detection until the user explicitly opts in

Each pattern traces to the same principle: trust is earned by what the system is structurally incapable of doing, not by what it promises. Supports Strategic Decision: Ephemeral by Design.

Five participants reviewed a video walkthrough of the final prototype. All five understood what the tool does from the walkthrough alone. Tone was read as neutral and supportive — no one felt judged.

Screen sharing breaks the privacy promise. Two participants independently flagged the same issue: during screen share, the volume indicator becomes visible to the entire meeting.

This is the sharpest unresolved survivability risk. Design response: PiP provides partial mitigation; wearable haptics remain an open exploration for presenters.

Sustained loudness needs a stronger signal. One participant wanted clearer indication of extended loudness beyond moment-to-moment feedback.

This validates the temporal escalation model. The ring stacking and surface inversion in the final build directly address this feedback.

The tool works for the willing, not the unaware. Two participants raised the same concern: the loudest people may never seek out a tool like this.

Acknowledged as a known constraint, not a design failure.

Additional signals: 4/5 requested native integration (Zoom, Teams, taskbar). Multiple participants suggested always-on background operation rather than deliberate launch — validating the PiP approach as a step in that direction.

Effectiveness cannot be measured through loudness reduction. Volume depends on meeting type, topic intensity, social dynamics, and personality. Metrics like "average loudness reduction" or "time spent out of range" would conflate passion with failure and undermine the product's own framing. Mezzo isn't trying to make people quiet — it's trying to make them aware at the right moment.

• Adoption & return (behavioral signal) — Do people come back? Repeat sessions, PiP usage rate, monitoring duration per session.
• Engagement with feedback (interaction signal) — Do people notice and respond? Time between entering "outside range" and session end, PiP usage after sustained feedback.
• Self-reported usefulness (outcome signal) — A lightweight post-session survey: "Was Mezzo helpful in this conversation?" Triggered intermittently, not every session.

Anonymous tracking preserves the trust architecture. A random, anonymous ID stored locally in the browser. Not tied to identity, not shared across sites or devices. No audio, names, or IP-based identification collected. Privacy language is explicit and plain: "Mezzo uses anonymous usage data to improve the product. No audio or personal information is ever collected."