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, easy to understand, and structured like natural conversation.
Agents can't rely on the visual UI of an app or webpage 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. User's should be able to communicate with agents naturally, much like they would communicate with another person in a conversation.
For more information on 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.
Starting 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, frontload information your users care about, and share what your agent is capable of. Give users actionable options for interacting with your agent and continuing the conversation.
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 also take up large amounts 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
content, 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
200 OK response for a message before sending the next message in 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
messageId strings. If you've already received a message,
it's safe to disregard any additional messages you receive with the same
Write clear and consistent messages
Send messages that are engaging and easy to understand. Good 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 myriad other errors. To recover from failed API calls gracefully, implement retries with exponential backoff.
Using retries with exponential backoff, your infrastructure automatically
- 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 allow you to combine media, text, and suggestions in one element. As such, media should not 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 file size of 40 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 file size of 40 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 devices or data plans. 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 expand or pivot the conversation. Suggestion chips should not 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 file size of 40 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 help users respond to your agent in natural ways that it can easily react to. Every message the agent sends that requires interaction should be paired suggested replies or actions.
Unless the interaction requires a freeform response, use suggested replies. Suggested replies are easier to process than freeform text and provide your agent with a method to steer conversations down an optimal path.
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 calling customer support or finding a location on the map easy, 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 and useable for the user in given the context.
Designing for conversation, flow, and usability are most important when creating your agent. Agents should focus on conversational UI, making sure to 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 maintain context and read messages with ease.
Considering the user experience and avoiding conversational dead ends when you're designing your agent provides users with positive experiences and leaves them willing to use your agent again in the future.