Most voice agent reviews I've read grade on two things: does the transcription work, and does the response sound natural. That's a speech-quality checklist, not a trust checklist. It tells you nothing about whether the thing is safe to put in front of someone who doesn't know it's a language model, or whether it fails gracefully when it inevitably misunderstands.
I've spent the last few months building a research instrument for evaluating voice agent behavior — not benchmarking latency or word-error-rate, but the relational behavior: what the agent does at the moments where trust is actually won or lost. I'm publishing the framework here, honestly labeled as a framework: a structured way to look at a voice interaction, not a set of finished findings with numbers attached. If you're designing or shipping a voice agent, these are the six places I'd tell you to look before you ship.
Why speech quality isn't the right unit of analysis
A voice agent can have flawless TTS and still be a bad interaction, because voice removes almost every visual affordance we normally rely on to communicate system state. There's no spinner, no "typing…" indicator, no button that says "end conversation," no visible list of what the thing can and can't do. Everything has to be communicated through timing, wording, and turn-taking, or it isn't communicated at all. That's a UX problem before it's an engineering one, and it needs its own evaluation lens — the six dimensions below, each a place where a voice interface makes an implicit claim about what kind of thing it is, whether the designer intended it to or not.
The six dimensions
1. Conversation journeys. Map the actual paths a user takes through a session — not the happy-path script, the real branches: someone who starts a task and abandons it, someone who circles back after a tangent, someone who tries to correct course three turns in. If you've only designed for the linear happy path, you've designed for a minority of real sessions.
2. Memory and forgetting. What does the agent remember across turns, and — just as important — what does it visibly forget, and does it say so? A voice agent that silently drops context earlier in the conversation isn't just annoying, it's dishonest about its own state. If memory resets between sessions, disclosing that is a design decision, not an edge case to skip.
3. Silence and hesitation. Dead air in a voice interface reads as a signal whether you intend it to or not — a pause can mean "processing," "confused," or "broken," and users can't tell which unless you design for it. This is one of the most under-designed surfaces in voice UX because it has no visual equivalent to steal patterns from. Filler audio, explicit "thinking" cues, or honest latency disclosure all count as real design choices — silence by default is not neutral.
4. Interruption and clarification. Can the user interrupt? Does the system interrupt itself to ask a clarifying question when confidence is low, or does it plow ahead on a guess? Barge-in handling is usually treated as a pure engineering problem — can the mic detect speech over playback — but the UX question is separate: when the agent could interrupt to clarify, does it choose to, and how does that choice get made?
5. Misunderstanding recovery. Every voice agent will misunderstand something. The design question is what happens next: does it ask a targeted follow-up, does it guess and move on, does it apologize and restart, does it quietly fail? Recovery behavior is where users form their most durable judgment about whether a system is trustworthy — a single graceful recovery can undo several turns of frustration, and a single bad one can end the session.
6. Trust formation. This is the composite dimension — how the previous five accumulate (or don't) into a user's willingness to rely on the agent for something that matters. It's also the one I'd flag as hardest to evaluate honestly, because self-reported trust and observed behavior (does the person actually delegate the next task to it) frequently diverge. Anyone running this kind of evaluation should build in a way to check both, not just ask "did you trust it?" at the end.
The design stance underneath the framework
The six dimensions are a diagnostic tool. What you do with what you find depends on a stance, and mine is the same one I use for any AI-adjacent interface: consent before capability, disclosure over deception, oversight as a required step rather than a setting the user has to find.
Concretely, that means a few things that are easy to skip under deadline pressure:
- Disclose that it's an AI, early, in a way that doesn't require the user to ask. The moment of disclosure matters as much as the fact of it — "I'm an AI" said thirty seconds into a rapport-building exchange lands differently than the same sentence said in the first breath. If your product depends on the user forgetting they're talking to a model, that's not a growth hack, it's a design failure.
- Treat structural trust separation as a UX principle, not just a security one. In prompt-injection defense, you keep system-level instructions and user-supplied content in different trust tiers so one can't silently override the other. The same logic applies to conversational trust: what the system claims about itself (capabilities, memory, certainty) should be structurally distinguishable from what it's inferring or guessing, and the user should be able to tell the difference by ear, not just by asking.
- Make oversight a required step for consequential actions, not an optional confirmation dialog. If the voice agent can take an action with real consequences — booking, purchasing, sending, deleting — the check-before-act moment should be a structural part of the flow, not a "are you sure?" that a rushed user learns to say yes to on reflex.
Using this as a checklist
If you're evaluating your own voice agent, or someone else's, before it ships, walk at least one non-happy-path journey end to end on purpose; find every place the agent goes silent for more than a second or two and ask what that silence is communicating; force a misunderstanding and watch what happens next instead of only testing the scripted demo path; check whether disclosure happens early and unprompted rather than on request; and identify every consequential action the agent can take, then confirm oversight is structural rather than a dialog box a rushed user learns to dismiss.
None of this replaces measuring latency or transcription accuracy. It's the layer above that — the one that decides whether a technically competent voice agent is also one people should actually trust.
I'm Josué — a UX and product designer working at the intersection of interaction design and applied AI, currently building out a research practice around voice-agent behavior and AI explainability. More at perex.design.
Top comments (0)