Google Conversation Design Guide (Assistant Actions)
Google’s design guide for building voice-first Assistant Actions.
License: CC BY 4.0 — confirmed via the license footer present on every page in the guide (code samples separately carry Apache 2.0, not relevant to the design guidance drawn on here).
Key points
- What is conversation design? frames conversation design as its own discipline synthesizing voice UI, interaction design, visual design, audio design, and UX writing — not a voice layer added to an existing graphical flow. States plainly that “the logic that works for a graphical interface is almost never going to work as-is for a conversational interface.” Calls for a system persona specific enough to have a recognizable voice but brief enough to keep in mind while writing dialogue.
- Learn about conversation draws design rules from real human turn-taking: signal a turn is over by asking a question, ask only one question at a time, and don’t re-request information already volunteered. Cites conversational-timing research — turns average about 2 seconds with ~200ms gaps between speakers, a near-universal figure across cultures and even sign language, evidence that listeners predict a turn’s end rather than just reacting to silence.
- Discovery covers four ways a person finds a voice Action (explicit invocation, an invocation phrase naming a task, an implicit/built-in-intent match, or a web link) and the design levers for each: a persona-fitting, easy-to-pronounce name; specific rather than generic invocation phrases; and a greeting whose specificity matches how the Action was reached.
- Language is the style-guide page: keep responses concise, use plain everyday words over jargon, vary repeated phrasing rather than replaying identical text, use contractions, lead a request with its reason, and prefer action-oriented verbs (pick, select, choose) over screen-specific ones (tap, swipe) that assume a device a voice-only speaker doesn’t have.
- Confirmations distinguishes confirming a parameter from confirming an action, and three handling levels (explicit, implicit, none) calibrated to the cost of a misunderstanding — implicit parameter confirmation is the routine case, explicit confirmation reserved for high-cost cases like a transaction, deletion, or an address read back before shipping.
- Errors covers three failure types — no match (misheard input), no input (silence), and system errors — with a shared principle of rephrasing rather than repeating verbatim, escalating to concrete examples or narrower options on a second failed attempt, and ending the exchange after two failed “no match” attempts rather than pushing for a third.
- Earcons defines an earcon as a brief non-verbal audio cue, usable only once its meaning is already clear without an explanation — “if you feel like you have to teach users what an earcon means, don’t use an earcon” — kept to a small, consistent, brand-matched set.
- Visual components overview frames a visual (card, carousel, list, media response, table) as a supplement designed after the spoken flow already works on a screenless device, never a replacement for the accompanying spoken or on-screen prompt, and always paired with tappable suggestion chips.