Conversational UI, not app UI
RBM agents are well suited for providing efficient and specific tasks to users in a conversational user interface. The best-designed agents keep interactions focused, clear to understand, and structured like natural conversation.
Agents can't rely on the visual UI of an app or web page and shouldn't attempt to mimic it. Instead, agents need to rely on carefully crafted conversations that address users' needs by guiding them with verbal cues, suggestions, and good error-handling.
Agents also shouldn't mimic phone trees, or interfaces that rely on users responding with a number that represents a given action. Users should be able to communicate with agents naturally, much like they would communicate with another person in a conversation.
For more information about conversational UI, see Conversational UI and Why It Matters.
Check the device's capabilities
Before starting a conversation with a user, verify that the user's device can receive RCS messages. Send a capability request to identify the device's capabilities, and tailor your agent's interactions accordingly. Only interact with users in ways that their devices support. If a user's device isn't RCS-enabled, set up a fallback method of communication with another technology, such as SMS.
Start a conversation
The start of a conversation sets the user's expectations of what an agent can do. Begin conversations on a strong note: show your agent's personality, front-load information your users care about, and share what your agent is capable of. Give users clear options for interacting with your agent and continuing the conversation.
Respect the maximum message size
RBM implements limits on the maximum size of an RBM message and the media file that a message can contain. These are documented in Send Messages page.
Keep a good rhythm
Using various types of information in conversations keeps users engaged and interacting with your agent, but be careful to not overwhelm your users. Keep messages within engaging, digestible lengths that let the user see the whole message onscreen at once. Images and rich cards can take up a lot of screen space, so be conscious of how much a user needs to scroll to read the whole message.
Keep messages in order
If you send multiple messages in sequence, it's important that users receive
those messages in order. Some messages, such as those that include media, take
longer to process than others, such as text-only messages. To
make sure users receive messages in the order you send them, wait until you
receive a 200 OK
response for a message before sending the next message in the
sequence.
The 200 OK
response confirms that the RBM platform received the message and
that the user should receive your messages in the correct order. If you don't
wait for a 200 OK
response before sending another message, users may receive
your messages out of order.
Check for duplicate incoming messages
When you check for and respond to incoming messages from users, check the
messageId
and verify that you haven't already received and
responded to the message previously.
With distributed systems, there are two ways of sending messages: at most once, and at least once.
- With "at most once" systems, the system sends a message once, but if there are network or communication errors along the way, the message may not be received.
- With "at least once" systems, the system might send a message multiple times, but the message can be received even when there are network or communication errors.
Google Cloud Pub/Sub uses an "at least once" system. While this can lead to
duplicate incoming messages, it's straightforward to de-duplicate messages by
tracking messageId
strings. If you've already received a message,
it's safe to disregard any additional messages you receive with the same
messageId
.
Write clear and consistent messages
Send messages that are engaging and clear for the user to understand. Good message text prompts users to respond, and consistency in the style, formatting, and pacing of text builds trust with users.
Keep the following additional best practices in mind when creating message text:
- Don't create dead ends. Each suggested reply should lead to a meaningful conversation thread with the user.
- If necessary, refer to the user as "you", not "me".
- For titles and labels, use sentence case, not title case. For example, "Account statement", not "Account Statement".
- Use contractions. "It's" is more conversational than "it is."
- Use exclamation points sparingly.
- Use the serial comma. For example, "A, B, and C", not "A, B and C".
- Write numbers as digits. For example, "1, 2, 3", not "one, two, three".
Respect when users don't want messages
When a user indicates that they'd like to stop receiving messages from your agent, you need to respect their choice. Your agent must understand when users reply "STOP" and react appropriately. Your agent should understand the various ways that users might communicate their want to stop receiving messages, including any and all languages they might use to communicate their wants.
Consult the laws and best practices for your country of operation on how to respond to STOP and other mandatory commands. For example, refer to the CTIA best practices.
Help the user
Your agent should respond to HELP messages from users and educate users about your agent's capabilities. Something as simple as a list of suggested replies that correspond to your agent's functionality can turn a poor user experience into a useful one.
Implement retries with exponential backoff
When calling any API, it's possible for a call to fail because of infrastructure issues, service overload, QPS limits, and other errors. To recover gracefully from failed API calls, implement retries with exponential backoff.
Using retries with exponential backoff, your infrastructure automatically does the following:
- Identifies a failed API call.
- Sets the initial wait duration and the maximum number of retries.
- Pauses for the wait duration.
- Retries the API call.
Assesses the API call response:
- If a success, proceeds with next step in the workflow.
- If a failure, increases the wait duration and returns to step 3.
- If a failure after the maximum number of retries, enters a fail state.
Ideal wait durations and the ideal maximum number of retries vary by use case. Determine these numbers based on the latency requirements of your infrastructure and workflows.
Rich cards
Rich cards allow you to combine media, text, and suggestions in one message. As such, media shouldn't be the only element in a rich card, and suggested replies or suggested actions should always accompany a standalone rich card.
Vertical rich cards
Vertical rich cards display horizontal media at the top of the card. Horizontal media should have an aspect ratio of 2:1, 16:9, or 7:3.
When you send media to a user, you should be respectful of the user's resources. When horizontal media has a 2:1 ratio, the optimal resolution for the media is 1440x720 px with a maximum recommended file size of 2 MB for images and 10 MB for video. The optimal resolution for the media's thumbnail is 770x335 px with a recommended file size of 40 kB and a recommended maximum size of 100 kB.
Horizontal rich cards
Horizontal rich cards display vertical media on the left or right side of the card. Vertical media should have an aspect ratio of 3:4.
When you send media to a user, you should be respectful of the user's resources. When vertical media has a 3:4 ratio, the optimal resolution for the media is 768x1024 px with a maximum recommended file size of 2 MB for images and 10 MB for video. The optimal resolution for the media's thumbnail is 250x330 px with a recommended file size of 40 kB and a recommended maximum size of 100 kB.
Rich card carousels
Rich card carousels are ideal for browsing content or various options, but they should only be used when there are multiple items to read or compare, such as data plans or devices. The first item in a carousel should be the optimal choice in any given situation, and the reasoning for why it is the optimal choice should be communicated to the user.
The suggestion chips below a carousel should advance or pivot the conversation. Suggestion chips shouldn't repeat the options listed within the carousel and are not selection tools for the items presented in the carousel.
Media in rich card carousels
Rich card carousels display horizontal media at the top of rich cards. Horizontal media in carousels should have an aspect ratio of 4:3.
When you send media to a user, you should be respectful of the user's resources. When the media has a 4:3 aspect ratio, the optimal resolution for the media is 960x720 px with a maximum file size of 1 MB for images and 5 MB for video. The optimal resolution for the media's thumbnail is 605x452 px with a recommended file size of 40 kB and a recommended maximum size of 100 kB.
Suggested replies & actions
Suggested replies and actions within a rich card should pertain directly to the content within that card.
Suggested replies and actions within a chip list should be ways of advancing or pivoting the conversation.
Suggested replies
Suggested replies help users respond to your agent in ways that it can easily respond to. Unless the interaction requires a freeform response, use suggested replies. They're easier to process than freeform text and they allow your agent to steer conversations down an optimal path.
Suggested actions
Suggested actions allow an agent to hook into native device actions and provide a tightly integrated experience for the user. When relevant, suggested actions can make it easy to call customer support or find a location on the map.
But don't overwhelm users with options. Only provide actions that are related to the most recent message, and only provide as many actions as necessary. Limit the number of suggested actions and suggested replies to what is useful to the user in a given context.
Design wrap-up
Designing for conversation, usability, and efficiency are most important when creating your agent. Agents should focus on conversational UI and guide users through optimal workflows with suggested replies and actions. When using images or rich cards, the agent should maintain a rhythm that allows users to retain context and read messages with ease.
Considering the user experience and avoiding conversational deadends when designing your agent gives users positive experiences and leaves them willing to use your agent again in the future.