AI design principles and Conversation design guidelines (Red Hat / PatternFly AI)

Source: Red Hat, PatternFly AI conversation design guidelines · undated

Conversation design is the practice of creating human-centered chatbots and other AI-driven interfaces. Like traditional content design, conversation design uses words to make experiences clear, concise, and relevant. At Red Hat, our goal is to ensure that AI enhances user experiences through interactive interactions that resemble a helpful, professional dialogue.

When designing AI conversations for PatternFly-based projects, align with our brand voice and tone and the ethical guidelines outlined in our AI overview.

Follow these best practices to ensure users can complete their goals:

Be transparent: Clearly disclose when the user is interacting with AI.

Be direct and brief: Use simple language and get to the point quickly.

Explain the "why": If you ask for personal information or specific data, tell users why it's needed first.

End with an invitation: Always have the "last word" in a chat-based interaction so the user knows the model is ready for their next prompt.

Focus on value: Frame bot questions and suggestions in terms of how they help the user, not just what the technology can do.

Our research shows that users want AI to be personable but not human. Red Hat AI experiences should sound like a helpful colleague, without pretending to be a person or mimicking human emotions.

When configuring an LLM or assessing a model's response, use this description as a baseline:

"Be a helpful colleague. Get straight to the point but engage the user like a peer. Ask clarifying questions if you need more information to give a precise answer. Give concrete advice, not vague platitudes. Empower the user—position Red Hat's technology as an enabler for their success, not a replacement for their expertise."

The physical constraints of a chat interface require specific attention to message length and formatting. See our ChatBot design guidelines for details on prompts, welcome messages, and streaming.

LLM guardrails are safety mechanisms that moderate how a model handles sensitive or risky prompts. Research shows that a user's experience is shaped more by how a model handles a refusal than by their initial intent. Even if you cannot fulfill a user's request, it is important to handle the interaction tactfully to ensure they feel respected.

Many models default to providing direct or explanation-based refusals (such as "I can’t do that" or "I can’t assist because of a safety policy"), but these can be perceived as frustrating or patronizing. While users generally prefer that a model fully complies with their requests, safety and policy requirements often make this impossible. When a guardrail is triggered, your goal is to instead "let them down easy" to maintain trust and engagement.

When a user requests something unsafe or unethical, follow these core strategies:

Prioritize partial compliance: Whenever possible, answer the general or theoretical parts of a user's request without providing actionable, dangerous, or sensitive details.

Explain the refusal: To reinforce transparency, clearly explain why action cannot be taken to fully comply with a user's request.

Redirect instead of shutting down: Avoid using definitive phrases like "I refuse" or "I cannot." Instead, suggest a related, safer topic to keep the conversation productive.

Real-time message streaming introduces unique technical challenges because guardrails must be checked dynamically as text is generated. To maintain a seamless experience, you should gracefully handle guardrail triggers at different stages of the conversation.

If a guardrail prevents a model response from ever being generated, provide a clear system-level message in the UI so the user isn't left waiting for a response that will never arrive. For example, this might look something like: "I'm sorry, I'm not able to assist with that request for safety reasons. Is there something else I can help you with?"

More complex are situations where violations are detected mid-stream. In these cases, avoid simply deleting the message from the DOM or UI, as disappearing content is likely to confuse users. Instead, if a guardrail is triggered while a message is streaming, replace the partial response with a standard refusal or redirection message.

To balance safety with timely streaming, consider a "chunk-based" verification workflow, as outlined in this AWS article about guardrails. Instead of waiting to validate the LLM's entire response once it's generated, you can validate its reply in small segments, only displaying a content in the UI after it has been verified. This approach creates a buffer that ensures safety without sacrificing the "real-time" feel of the conversation. If a segment fails, you can halt the stream and redirect to a safer topic or address inability to reply.