Voice scenarios mapped end to end
SmartHQ Voice Assistant
Hands-free control for the connected kitchen.
Overview
Hands-free appliance control, made visible.
Context
A task-based assistant for ovens and refrigerators—not a generative chatbot. I designed the flows, interface, and motion. To respect confidentiality, this case study focuses on selected design decisions rather than a complete product specification.
Voice extends appliance control into moments when touching the display is inconvenient.
Scope
A connected interaction system across voice, screen, motion, and sound.
Assistant states designed (Wake, Listening, Processing, Confirmation, Success, Timeout, Error)
Earcons distinguishing key moments
Core Problems
Voice removes the interface users usually rely on to understand a system.
No persistent state on screen — users can't glance and know what's happening
Every request could branch four ways — success, ambiguity, timeout, or failure
Sound and motion had to agree — a visual cue and an audio cue saying different things breaks trust instantly
Scenario 01 — Shopping List
HMW let voice write to the same list as barcode scanning, without feeling like a second system?
Initial version
SmartHQ fridges already let people build a shopping list by scanning a barcode. The first version of the voice path treated voice as its own list — separate from what scanning produced.
What review revealed
In review, that separation created doubt about whether spoken and scanned items ended up in the same place.
What changed and why
The revised flow merged both inputs into a single list at the data level, and added one confirmation step for ambiguous requests — 'add milk' needs to ask which milk, but only once, and only when it's genuinely unclear.
Scenario 02 — Long, Open-Ended Questions
HMW recognize when a request needs a longer answer and hand it off to SmartHQ without breaking the conversation?
Short appliance commands could stay compact. Open-ended questions—like asking what ingredients are needed for an apple pie—needed a longer answer, so the assistant transferred the request into SmartHQ’s conversation view.
The flow makes activation, transfer, and response distinct so the user can see that the request is still moving forward.
Scenario 03 — Timeout
HMW make a timeout feel conclusive, not broken?
Designing a timeout that feels conclusive—not broken.
Sketches tested brightness, directional wipes, and a disappearing horizon before motion studies refined the final exit.
Brightness and expansion
The horizon brightens before expanding out of view.
Brighten, then expand
Directional wipe
The active horizon exits laterally across the display.
Directional wipe
Flatten and return
The horizon settles back into the appliance interface.
Clear return to the appliance
Sound as behavior
Every tone signals what happens next.
Timing and Interaction
- Interruptible
Stops when another sound or user action takes priority.
- Duck
Lowers one sound while another needs attention.
- On-Demand
Plays only after an explicit user action.
- Autoplay
Begins automatically after a system event.
- Sequential
Plays a defined series in a fixed order.
- Conditional
Plays only when context or preferences allow it.
Earcons & Audio Feedback
- One-Shot
Plays once from start to finish.
- Loop
Repeats until the system explicitly stops it.
- Fade
Gradually raises or lowers volume.
- Stinger
Introduces a longer sequence without repeating.
- Crossfade
Transitions smoothly between two sounds.
Reflection
What this work clarified about designing across teams and systems.
Coordination is a deadline problem.
This was my first project spanning multiple teams—voice, visual, sound, software, and hardware all building from the same logic. A delay in one flow didn't just slow me down; it held up sound testing, engineering handoff, and reviews downstream.
Vision meets constraint.
The most polished version of an idea isn't always the one that ships. The real design work happened in the negotiation between what looked best and what was feasible to build.
Consistency carries the brand.
Voice, motion, and sound were built by different people on different timelines, but still needed to sound like one product. Keeping that thread visible was as much my job as any single screen.
Some decisions outlive the project.
Not every component was built just for this feature. The earcon set and the state-transition motion language were designed to extend into the broader design system.