Modeling a confirmation action for voice
abstracting intent from visual UI.
model confirmation as a modality-agnostic intent, add voice tokens (prompts, accepted phrases, reprompts, timeouts), and map intent to each modality.
What's really being asked
The interviewer wants to see modality-independent thinking: a design system should describe intent and behavior, not just visual widgets. Voice forces this abstraction.
The full answer
Reframe the button click as an abstract intent, say a confirm action with confirm and cancel outcomes, decoupled from any rendering. On a screen that intent renders as a button; on voice it becomes a spoken dialog. To support voice you add new specification and token types: a prompt phrase the system speaks, a grammar of accepted user utterances (yes, yeah, confirm, do it) and their negatives, reprompt phrasing for no response, error or no-match handling, timeout durations, and a confidence threshold for accepting recognition. You may also add earcons or audio cues as tokens. The intent is the stable contract; each modality has its own token set that fulfills it. This keeps screen, voice, and future modalities consistent in meaning.
The mistakes people make
Assuming voice support is just text-to-speech of the button label, which ignores recognition grammar, reprompts, and timeouts. Hardcoding voice flows separately with no link to the visual confirmation intent. Forgetting error and no-match handling, which dominate real voice UX.
What usually comes next
How do you handle low-confidence recognition or no response? How do you keep the voice and visual confirmations semantically in sync? What accessibility overlap exists with screen readers?
A concrete example
You define an intent confirmDelete. The screen modality renders a Confirm button. The voice modality references tokens: prompt Are you sure you want to delete this?, accepted utterances yes/confirm/delete it, a reprompt I did not catch that, do you want to delete?, a 6-second timeout, and a confidence threshold. Both modalities resolve to the same confirmDelete outcome, so behavior stays consistent across screen and voice.
Interview question
What does properly supporting a voice confirmation action require beyond reading the button label aloud?
- a.Converting every CSS color token into an audio frequency
- b.Storing the spoken phrase as the button's only accessible label
- c.Removing the visual button entirely from the design system
- d.A modality-agnostic intent plus voice tokens for prompts, accepted utterances, reprompts, and timeoutsCorrect
Why? this is the answer
Voice needs recognition grammar, reprompts, timeouts, and confidence handling tied to an abstract intent, not just speaking a label. Colors-to-audio and deleting the button are irrelevant distractions.
Just read this? Test yourself on what you have been reading.
Read the original → parallelhq.com
- #design-systems
- #voice-ui
- #tokens
- #multimodal
- #intent-design
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design-systems — each one lists the topics its interview covers.
See open roles