Design guidelines

Design a conversation to guide users through your transactional flows. We've provided reference examples that you can use as a guide when designing your own transactional Actions.

Examples

Design tips

  • Make sure the dialogs sound natural and conversational — the way a real person would talk.

  • The text spoken by your TTS/voice does not have to exactly match the text shown in your chat bubbles. It works well if the chat bubbles are a subset of the spoken dialog.

  • Greet your visitors and get them engaged. Ask what they need and offer a few suggestion chips to get them started.

  • Before inviting the user to add items to the cart, do a backend check by adding slot filling and using the actions.type.TransactionRequirementsCheckResult slot type to confirm the user has payments set up for their Google Assistant.

  • Be prepared to respond to the same issues with voice as with other mobile or web experiences. For example, offer a similar item when you're out of a certain size or color, or invite users to sign up to be notified when the item is back in stock.

  • Note that the order summary is built with the data you pass via the API. The "Pay with Google" label helps users understand that Google facilitated the payment.

  • When requesting info from your users, like their address info, first let them know why you are making the request and how it will benefit them.

  • Google will present the purchase authorization method (either no auth required, password, or fingerprint) based on the user's settings. Sometimes our risk assessment will kick off an additional auth step like confirming CVV for a card.

  • After the payment is complete, be sure to send a receipt and an order confirmation. It's important that users understand that you are the merchant of record, and will follow up with all details about the order, not Google.

  • By default transactions can be performed on either a surface with a screen (such as an Android phone) or a voice-only surface (such as a Google Home).

    • To best support voice-only transactions, take extra care to design a good conversational experience that walks users through the full transaction experience.

    • Note that some transactions intents may require a screen. Most of these (e.g. adding a new delivery address, fixing payment issues, account linking) will be handed off to the phone automatically. If there are any additions to the conversation that are best displayed on a screen (e.g. presenting rich responses for card building, displaying a merchant ToS or privacy policy), you should check if the current surface supports the RICH_RESPONSE or WEB_LINK capabilities, and transfer to a new surface if not.

    • If you would rather not support voice-only transactions with your Action, you can set your Actions project to require a screen by navigating to Deploy > Surface capabilities in the Actions console and setting Do your Actions require a screen output to Yes.