Modeling a confirmation action for voice

WHAT THIS TESTS The interviewer wants to see modality-independent thinking: a design system should describe intent and behavior, not just visual widgets. Voice forces this abstraction.

A GOOD ANSWER COVERS 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.

COMMON WRONG ANSWERS 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.

LIKELY FOLLOW-UPS 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?

ONE 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.