The biggest product companies are moving past the “add a sparkle icon and call it AI” phase. IBM, AWS, Atlassian, and GitLab are documenting AI behavior inside their public design systems, complete with rules for disclosure, generated content, chat, feedback, tone, and control.
Their systems look different, but the underlying AI design system patterns are beginning to converge. AI needs a recognizable entrance, its output needs a clear identity, and users need a way to question, correct, or take control of what it produces. That gives smaller product teams a useful head start: we can study the decisions these companies have already made instead of designing every AI interaction from scratch.
At The Design Project, we’ve helped more than 50 B2B SaaS teams ship products faster with AI. We also run workshops with product teams working through what AI should do, how it should behave, and where it belongs in the experience. The same pattern keeps surfacing in that work: the interface is only one layer. Trust depends on the rules around it.
Table of contents:
- What are AI design system patterns?
- The three patterns all four systems share
- How each design system approaches AI differently
- How to add AI patterns to your design system
- The missing pattern: designing for hallucinations
What are AI design system patterns?
AI design system patterns are reusable interaction and visual rules for AI-powered product experiences. They define how users discover an AI feature, recognize AI-generated content, understand what the system is doing, provide feedback, and recover control. They turn isolated AI experiments into consistent product behavior.
That consistency matters because AI creates a different relationship with the user than a traditional button or form. The output can vary. It can take time to generate. It can be incomplete or wrong. It may need context from the user, and the user may need context about the model in return.
IBM’s Carbon for AI treats AI as an extension of the core Carbon system, with its own visual identity and explicit guidance around trust, transparency, and explainability. AWS has built a broad generative AI pattern collection in Cloudscape, covering everything from loading states and follow-up questions to source display and user-authorized actions. Atlassian brings its AI product into the design system through Rovo UI, while GitLab’s Pajamas system documents AI-human interaction, calls to action, chat, feedback, agents, and flows.
The lesson is bigger than any individual component. These teams are treating AI behavior as shared product infrastructure.
The three AI UX patterns all four systems share
Across the four design systems, three patterns show up again and again.
1. Give AI a distinct entrance
Users should know when an action invokes AI before they click it. Each system creates a recognizable signal for AI-powered actions, usually through a dedicated icon, label, visual treatment, or combination of the three.
Carbon uses its AI label and visual styling to identify AI throughout an experience. Cloudscape reserves its generative AI sparkle icon and “Generated by AI” label for actual generative output. Atlassian gives Rovo actions a distinct visual language. GitLab recommends AI-specific icons for Duo calls to action while keeping button copy short and descriptive.
The exact symbol matters less than the consistency. If the sparkle appears on AI features today, decorative empty states tomorrow, and a premium upgrade banner next week, it stops communicating anything. A design system should make the AI signal exclusive enough that users learn what it means.
2. Make generated output identifiable
The system also needs to show when AI is working and which content came from it. This is where the design systems go beyond a single trigger icon.
Carbon can apply an AI visual treatment to a field or larger area and pair it with explanations about how AI contributed. Cloudscape documents loading, streaming, finished output, citations, regeneration, and feedback as related states in one experience. Atlassian uses a generative border to signal active generation and explicitly warns against using it as decoration. GitLab recommends a nearby “Generated by AI” or “Summarized by AI” disclaimer and asks users to verify the result before use.
A strong output pattern answers four questions without making the user investigate:
- Is the system currently generating something?
- Which part of the interface came from AI?
- What information or sources shaped the result?
- What can I do if the result is weak or wrong?
That fourth question leads directly to the next shared pattern.
3. Keep the user in control
Every system includes some form of response control: regenerate, edit, approve, reject, like, dislike, or provide detailed feedback. The interface may look like chat, an inline assistant, or an AI-enhanced form, but the user needs a clear way to influence what happens next.
Feedback is part of the product loop. GitLab’s Duo feedback guidance points out that a thumbs-up or thumbs-down captures only a thin slice of the experience, so users should also be able to explain what happened in their own words. Cloudscape includes feedback controls, response regeneration, support prompts, and follow-up questions. Carbon’s chat pattern includes regeneration and rating actions.
Control also includes transparency before the AI takes consequential action. Cloudscape now documents user-authorized actions for cases where an agent wants to use a tool or execute a command. This will become increasingly important as product teams move from assistants that answer questions to agents that change data, trigger workflows, and act on a user’s behalf.
How the four AI design systems differ
The shared patterns are the useful baseline. The differences show where a product team can make deliberate choices based on its users, risk, and brand.
| Design system | Strongest idea | What product teams can borrow |
|---|---|---|
| IBM Carbon | Explainability at the point of use | Let users inspect why AI is present, what it does, and which model or data shapes the result. |
| AWS Cloudscape | Detailed conversation and agent states | Document the complete flow around generation, including loading, questions, citations, approval, and recovery. |
| Atlassian Rovo UI | A distinct AI personality and visual system | Define tone, motion, illustration, and behavior together so the assistant feels native to the product. |
| GitLab Pajamas | Deep written interaction guidance | Write explicit rules for transparency, feature maturity, feedback, accessibility, agents, and flows. |
IBM Carbon: explain the AI where it appears
Carbon’s most useful contribution is its focus on explainability at multiple levels of the interface. An AI label can open more context about what the AI is doing, how it works, and where the user can learn more. The pattern makes disclosure useful rather than treating it as a tiny legal footnote.
For product teams, this is especially valuable when AI appears inside an established workflow. If a resume field is auto-filled, a summary is generated, or a recommendation changes, the user should be able to understand AI’s role right there. They shouldn’t need to visit a general “How our AI works” page and figure out which paragraph applies.
AWS Cloudscape: document the whole conversation
Cloudscape goes deepest on the mechanics of a generative experience. Its pattern library covers ingress, chat, loading, output labels, response regeneration, support prompts, citations, follow-up questions, thinking, progressive steps, context, and authorization.
The follow-up question pattern is particularly strong. Sometimes an AI system needs more information before it can produce a useful answer. Cloudscape formalizes how the assistant can ask for that information, offer choices, and keep the conversation moving. That creates a more honest experience than letting the model guess and presenting the result with false confidence.
Atlassian Rovo: build a character, not a sticker
Atlassian has invested heavily in making Rovo feel like a coherent product presence. Its AI language extends into icons, color, elevation, motion, illustrations, and voice. The tone guidance aims for a personality that is trustworthy, insightful, and collaborative while adjusting to the stakes of the situation.
That last detail matters. An assistant can sound playful while helping someone brainstorm. The same tone may feel careless while summarizing a security incident or discussing layoffs. Brand personality still needs situational judgment, and documenting those boundaries helps everyone writing or designing the experience make consistent choices.
GitLab Pajamas: give the rules enough depth
GitLab’s public guidance is text-heavy, and that is a strength when the implementation has many edge cases. Pajamas explains when to use a multi-turn chat, how conversation context persists, how agents are identified, how feedback works, and how AI disclosures should appear. Its AI-human interaction guidance also tells users to verify generated content and makes transparency part of the normal workflow.
Visual examples help people scan, but clear written rules give designers, engineers, content designers, and AI agents a shared source of truth. A mature design system needs both.
How to add AI patterns to your design system
You don’t need a separate, sprawling AI library on day one. Start with the moments that already exist in your product, then document the rules that would prevent teams from implementing them four different ways.
1. Inventory every AI touchpoint
List where users discover AI, trigger it, wait for it, review its output, correct it, and approve actions. Include quiet AI features such as autofill, ranking, summarization, and recommendations, not only chat.
2. Define one recognizable AI signal
Choose the icon, label, and visual treatment that identify AI. Write down when each is required, where it appears, and where it cannot be used. Test the pattern in dense product screens and in dark mode before making it a standard.
3. Map the full output lifecycle
Design the states around the answer: idle, gathering context, generating, streaming, complete, edited by the user, failed, and outdated. Add citations or explanation where the source affects trust. Make sure the system still works when generation takes longer than expected or returns nothing useful.
4. Build correction and approval into the component
Decide how users regenerate, edit, undo, report, or reject a result. If an agent can change data or trigger an external action, add a review step proportional to the risk. Approval should describe what will happen in plain language.
5. Document voice, accessibility, and risk
Include content rules for tone, uncertainty, errors, and high-stakes moments. Specify keyboard behavior, focus order, screen-reader announcements for loading and completion, and motion alternatives. Then document which use cases require legal, security, or subject-matter review.
At TDP, we’ve found that these decisions are easiest to make when design and engineering work through a real feature together. The component becomes more useful because it captures actual product constraints, and the feature ships faster because the team is building the reusable pattern at the same time.
The missing pattern: designing for hallucinations
The four systems do a thoughtful job with transparency, feedback, and verification. The weakest area across the group is what happens when the system confidently produces something false.
A disclaimer helps set expectations, but it doesn’t give the user a recovery path. Product teams should document how the interface behaves when sources conflict, confidence is low, a citation doesn’t support the claim, or the user flags an answer as wrong. Those states will show up in production whether the design system acknowledges them or not.
A hallucination pattern could include:
- A clear way to challenge a specific claim rather than rating the whole answer.
- Source-level feedback when a citation is missing or irrelevant.
- A low-confidence state that asks for more context or offers a narrower answer.
- An undo or recovery flow when the AI has already changed something.
- Escalation to a human or authoritative source for high-stakes decisions.
This is where the next generation of AI design systems can go further. Teams have established how AI enters the interface and how generated content looks. Now we need reusable patterns for how the product admits uncertainty, recovers from mistakes, and earns trust over time.
Start with rules, then design the interface
The strongest takeaway from IBM, AWS, Atlassian, and GitLab is that AI belongs in the design system because its behavior needs to be consistent across the product. A dedicated icon is useful. The deeper value comes from agreeing on disclosure, output states, feedback, explanation, approval, tone, and recovery before every feature team invents its own version.
If your team is working through these decisions, talk to The Design Project. We help B2B SaaS teams turn early AI experiments into reusable product patterns, production-ready components, and workflows that designers and engineers can actually ship.
Read more like this
- Agent skills: stop re-teaching AI your design system
- AI product design: why the designer still changes the outcome
- Paper AI design tool: a code-connected workflow from design to production
