Note: The changes described in this article are currently available for preview at staging.patternfly.org. Links in this blog will be updated when they go live on PatternFly.org.

Since we launched PatternFly 6, we’ve continued to expand our website to keep pace with new product patterns and technologies. But as we released more documentation, it became clear our navigation was struggling to keep up. With dozens of new guidelines needing homes on PatternFly.org, our information architecture wasn’t just making it harder to place new content — it was becoming a barrier to the efficiency and consistency we strive to provide.

As PatternFly’s content designer, I knew we needed a strategic change, but that change couldn’t happen in isolation. To ensure our new direction was driven by data rather than my own assumptions, I led a multi-phase research study to uncover how our website could better serve our community.

After months of iteration and analysis in 2025, our new navigation is more effective and scalable. Here, I’ll share my research findings, the specific changes I’ve made, and the four core principles that guided our redesign.

Research approach and results

To build a more user-focused navigation, I led a study with 23 total participants who identified as a designer or developer. I used a mix of methods to ground decisions in how Flyers actually use PatternFly: card sorting to understand mental models and explore new ways to group content, and tree testing to measure how successfully and confidently participants could find information using only the navigation menu.

Testing and iteration

My research followed a multi-step process to move from our baseline to a new design, involving both experienced and fresh perspectives:

• Tree test 1 (the baseline): 13 participants completed 10 tasks using the existing navigation menu. This first step identified exactly where people were getting lost and established our starting metrics for success and confidence.
• Card sorting: I worked with 4 PatternFly maintainers through 3 rounds of card sorting. This revealed how maintainers closest to the system think about content organization.
• Refining the path: I ran two additional rounds of tree testing (with 12 and 19 participants respectively) to iterate towards a final design. I rephrased tasks to reduce bias and tested new navigation areas. To ensure the new system worked for everyone, I invited back original participants to measure improvement and also recruited novice PatternFly users (recent team hires) to see how the site performed for those less familiar with our system.

Findings

The results showed that a new direction was a clear win. While our existing navigation had a solid 70.7% success rate, the new design raised that to 76.4%.

What stood out even more was the jump in user confidence–on a 5-point scale, average ratings increased from 3.62 to 4.15 between our baseline and final tree tests. While some findability gaps remained — particularly around terminology for core concepts — the data confirmed I was on the right track. I used the final round of qualitative feedback to make one last set of refinements, ensuring the experience felt simplified but stayed functional.

The “Why”: 4 principles that guided the design

The numbers only tell part of this story. Qualitative feedback from our participants uncovered 4 clear principles to drive the final design. Not every insight lent itself to a clean before/after metric, but all shaped what you see today.

1. Clear labels drive confidence

When a navigation label describes a distinct destination, users feel confident. When it’s vague, they hesitate. Regarding our “Accessibility” heading, one user noted: “This feels very forward and clear!” In contrast, conceptual headers like “Foundations” and “Guidelines” often felt indistinguishable to users.

The changes:

• I made key entry points action-oriented — like Get started, Get help, and Get involved — to put the user’s goal first.
• I elevated help resources from behind generic headers and created dedicated pages for Contact us, FAQs, Bug reports, and Contribution guides.

The results:

• Removing guesswork from top-level labels was a major driver of our overall success rate increase.
• Participants navigated to help/support resources (like bug report and contact information) much faster than in our baseline test.

2. Structure breaks down complexity

This study confirmed that long, unstructured navigation can be overwhelming. To fix this, I applied a UX principle called “chunking” to break content into smaller, related groups. This helps our users recognize the right path rather than trying to memorize a list.

The changes:

• I organized items into three labeled, non-clickable groups–Learn, Design and develop, and Connect–separated by horizontal dividers.
• I moved items into their logical categories. For example, Topology and Component groups moved into Extensions, and Layouts and Tokens moved into Foundations and styles.

The results:

• Participants appreciated the breathing room. As one put it: “Classifying the menu items makes the number of options seem less overwhelming.”
• Across the redesign, top-level navigation items decreased from 16 to 13 — even as four new destinations were added.

3. Our design language weakens confidence

PatternFly is a robust system, but our language for core concepts — like components, patterns, and extensions — isn’t always self-explanatory. One participant admitted: “I don’t understand the difference between Component groups, Extensions and Patterns.”

The changes:

• I ensured that every major nav section has an updated Overview page. While we aren’t renaming our core features right now, these pages provide concise definitions and use cases to help users navigate our system’s complexity.

The results:

• Because this study focused on navigation-only interactions, I didn’t specifically test the effectiveness of this new page content. We’ll monitor the success of these changes through Google Analytics and user feedback surveys as our team continues to explore how users perceive our core concepts.

4. “Irrelevant” content creates noise

I observed participants mentally filtering our navigation based on their roles. If a navigation item felt like a “designer thing,” developers would often ignore it as noise–even when the content was relevant to both roles. The issue isn’t the content itself, but the perception of who it’s for based on how it’s labeled.

The changes:

• I organized all functional design and development documentation into its appropriate core concept like Components, Extensions, or Foundations and styles. By using these clear, conceptual “buckets,” I hope to reduce the feeling that any part of our system is job-specific.

The results:

• Some of these role-based assumptions are deeply rooted, so this work goes hand-in-hand with efforts to clarify design language. This insight has also opened doors for future exploration, such as role-based personalization or a site-wide context selector, to help users find exactly what they need for their specific job.

A snapshot of key changes

Here’s a consolidated view of every change I made — for full URL-level detail, refer to this Google Sheet.

Top-level navigation updates

Renamed:

• Design foundations → Foundations and styles
• PatternFly AI → AI
• UX writing → Content design
• Developer resources → Developer guides

Relocated:

• Charts is now under Components
• Component groups & Topology are now under Extensions
• Tokens, Layouts, & Utility classes are now under Foundations and styles
• Training is now under Get started

New:

• About us, Releases, Get help, and Get involved are new top-level items, surfacing content that was previously buried under Get started

Standardization and consistency

• “About [Section]” pages (like those in AI, Charts, and Patterns) are now simply called Overview
• Several pages were renamed for immediate clarity: Upgrade → Upgrade guide, Tokens → Design tokens, Writing for all audiences → Accessibility and localization
• Content design gained a more structured organization, with Grammar and Writing guides as distinct sub-sections replacing the previous flat list

Explore the new design today

Redesigning our navigation has been a collaborative, iterative journey — and you can experience it right now. The new navigation is available for preview at staging.patternfly.org!

We invite you to explore our new site structure and see how these changes affect your workflow. While the research phase is complete, navigation is never a one-time project. As you use the new navigation, we want to hear from you in our user feedback survey–your insight keeps PatternFly flying.

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.

Disclaimer: This story was drafted with AI assistance. All insights and final edits are the author’s own.

A new path for PatternFly.org was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Wait — Claude Code has a marketplace?”

That was the question that started a new chapter for PatternFly. We’d been sharing PatternFly context with AI models for a few months — Cursor rules, reference docs, an MCP server. All helpful, and genuinely a step forward from where we started. But the context lived in static files that users had to manually copy into their projects, and it only worked in one tool.

A marketplace changed that equation. Instead of asking developers to clone a repo and copy files into their project, we could package PatternFly knowledge into plugins that install with a single command. It also meant reaching Claude Code users for the first time. We didn’t know exactly what we’d build yet, but the opportunity was clear: a better way to distribute what we know, and a new platform worth exploring.

So we started building.

Low-hanging fruit first

The first two skills we created were deliberate: a coding standards agent and a unit test generator. We picked them because they addressed the most common friction points of following component composition conventions and Testing Library best practices, but also because they demonstrated two different modes of working.

We created the coding standards agent to run automatically. Once you install the plugin, it shapes every response your AI gives — carrying PatternFly conventions into every conversation without anyone having to ask.

The unit test generator works differently. Instead of running automatically, you invoke it when you need it to generate a test file. That distinction (agent = always-on knowledge, skill = on-demand action) became foundational to how we continued to build out our plugins.

Then the floodgates opened

Once the first plugin worked and the file format was clear, something unexpected happened: our team saw the pattern that emerged from our initial plugins and just started building. No one had to be convinced. No one needed a training session. They just looked at the existing skills, understood the format, and started writing their own.

The simple format itself was part of why our team was able to take action so quickly — a skill is just a SKILL.md file with some frontmatter and markdown. If you know a workflow, you can teach it to an AI model.

Then, Cursor rolled out marketplace support too. So we waved them aboard: same skills, same agents, both tools. That was important to us. We wanted to meet developers where they already were, not ask them to switch tools for the privilege of better PatternFly output. If a team used Cursor, we wanted the same marketplace to work without extra configuration or separate install processes.

Here’s what that looks like on the Cursor side — same plugins, same skills, different tool:

What started as one plugin quickly became several. If you’ve ever worked on an open source project and felt the moment when the project stops being yours and starts being the team’s, that’s what this felt like. I’d open the PR queue in the morning and three new skills would be waiting for review. Someone automated issue tracking with duplicate detection across PatternFly repos. Someone else created Figma-to-code change tracking. Another person automated the release version update workflow that had been manual for years. The contributions kept coming, each one from someone who knew a specific PatternFly workflow and decided to teach it to an AI model.

What made that possible wasn’t heroics, it was scaffolding. Someone who’d never written a plugin before could open CONTRIBUTING-SKILLS.md in the morning and have a working skill merged by the afternoon. No build step, no SDK, no framework to learn — just a markdown file with some frontmatter that describes a workflow.

The barrier to entry wasn’t “can you build a plugin?” It was “can you describe what you know?”

What we got wrong (and fixed)

Not everything landed cleanly.

Our original plugin names were product-prefixed and vague. One of them was a catch-all called something like “workflow” — workflow for what, exactly? If you saw it in a marketplace list, you’d have no idea whether it helped with issue tracking, release management, or something else entirely. We adopted a decision test: if someone browsing the marketplace can’t tell what they’re installing from the name alone, the name is wrong.

That test killed the old names and led to new, domain-based names, with the catch-all split into two focused plugins. It was a breaking change, but the marketplace was new enough that we wanted to get it right early rather than live with confusion later. The new names — react, design-foundations, figma, issue-management, repo-management, a11y — each tell you exactly what you’re getting before you click install.

Early contributions also mixed up the skill-versus-agent distinction, which was fair — the line isn’t obvious until you get it wrong. Some skills read like reference documentation instead of a method of producing usable output. Some agents tried to generate deliverables instead of shaping the AI’s thinking.

We landed on a litmus test: can someone use the result directly? That’s a skill. Is it knowledge the AI should always carry? That’s an agent. Once we named it that clearly, the contributions started sorting themselves.

And then there was SKILL.MD. Capital letters. This convention worked fine on macOS, but broke on Linux. This led to a one-character fix and a good reminder: if you only test on one operating system, you’re going to ship bugs the other one finds.

What it looks like when it works

Here’s what all this adds up to: someone asks Claude to build a PatternFly page with the React plugin installed and gets back properly nested components, correct design tokens, and no custom CSS. No corrections needed. No code review comments about component hierarchy. No hunting for the right token variable name.

That’s dozens of skills across several plugins doing their job. The success isn’t because any one skill is magic, but because together they carry enough PatternFly knowledge that the AI stops guessing and starts getting it right.

The difference between “AI that kind of knows PatternFly” and “AI that actually builds PatternFly correctly” turned out to be a set of well-written markdown files.

Our plugins also pair well with the PatternFly MCP server — a local service that gives AI tools access to component docs and prop schemas on demand. Skills tell the AI how to work, and the MCP gives it the reference material to work with.

What’s on the horizon?

There’s an empty plugin in the marketplace called a11y. It’s scaffolded with no skills inside — just a README that says “contributions welcome.” That’s deliberate. Accessibility is a first-class concern in PatternFly, and we wanted the taxonomy to have a home ready when the right contributor shows up. We’re waiting for someone who lives and breathes WCAG to come fill it in. If that’s you, the scaffolding is already there.

That empty plugin says a lot about where this goes next. The skills we have today are version one. They work, but we already know where to push them. The unit test generator, for example, produces solid tests, but it doesn’t yet know how to handle PatternFly’s more complex composite components like Wizard or DataList without some hand-holding. Every time someone runs a skill and bumps into a limitation like that, it’s a signal about what to improve for the next person.

We’re still finding new things to teach our AI tools. That’s the part that keeps us going — the marketplace isn’t a finished product, it’s a living system that gets smarter every time someone contributes what they know. And honestly, watching an AI tool go from “kind of helpful if you babysit it” to “actually understands how PatternFly works” has been one of the more satisfying arcs of my year.

Your turn

The marketplace is open source and we’re actively looking for contributions. You don’t need to be a plugin developer or know anything about AI tool internals. If you can describe a workflow in markdown, you’ve written most of a skill.

Explore the marketplace on GitHub. Install a plugin, try it in your own project, and see if it changes how your AI tools handle PatternFly code. If something doesn’t work right, tell us — that’s how the skills get better. And if you know a workflow well enough to describe it — contribute it back. Remember that teammate who already knows PatternFly? You could be the one who teaches them something new.

In Claude Code, two commands get you started:

/plugin marketplace add patternfly/ai-helpers
/plugin install react@ai-helpers

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.

Disclaimer: This story was drafted with AI assistance. All insights and final edits are the author’s own.

PatternFly’s AI marketplace was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.

A major barrier to using generative AI in PatternFly design and development is the “context gap.” While large language models are powerful, using them in an open environment often results in the generation of solutions that already exist or that deviate from established patterns. For PatternFly, this limitation caused early AI-generated prototypes to appear visually correct, while inadvertently violating design system rules.

The PatternFly Model Context Protocol (MCP) provides a solution to this challenge by providing models with a definitive source of truth for our design system.

The spark

Our MCP journey began with research into which existing workflows were effective and which were not. During workshops and early experiments with AI-integrated editors and CLI tooling, we saw a recurring problem: tools frequently suggested components that did not exist or props that had been deprecated for years.

This was not a failure of the underlying technology, but a failure of context.

Early attempts to bridge this context gap relied on manual guidance, such as curated Markdown libraries and detailed prompt instructions. These experiments proved that without a living, authoritative link to our design system, generated output would be less reliable and consistent. This realization led to our first MCP prototypes, which focused on providing tools with direct access to definitive documentation.

Scaling the solution

As this context project grew, our initial MCP prototype required a more robust foundation in order to more effectively reduce invalid output. To create a stronger base, our team integrated PatternFly component schemas using JSON and Zod descriptions. These schemas made it possible for tools to validate suggestions against actual PatternFly APIs.

The move from simple data access to formal validation was a turning point for the MCP. We could draw from past architectural patterns and refactor the project into a production-ready tool. To prepare the MCP for release, we introduced a more modular architecture by focusing on:

• Core isolation: We isolated the server core to ensure stability and simplify maintenance as our tool library expanded.
• Plugins for extensibility: By treating tools, resources, and prompts as plugins, we created a system that could grow from a simple documentation repository to a comprehensive suite of resources–without bloating the core server.
• Resources: Research into MCP resources helped us deliver documentation more effectively, manage token usage, and refine tool performance.

During this scaling period, the MCP matured through early releases, which allowed us to validate the experience before reaching a wider audience within Red Hat and the PatternFly community.

Reaching maturity with our 1.0.0 release

Moving the project to the PatternFly GitHub organization marked a shift toward long-term stability. To prepare the MCP for its first official release, we focused on refining the ergonomics of the MCP protocol to ensure a seamless setup experience for designers and developers.

As a foundation to our 1.0.0 release milestone, we migrated simple tools to MCP Resources. This change made it possible for users to search PatternFly documentation and schemas as a structured library, further closing the context gap.

Today and beyond

Today, the PatternFly MCP (v1.0.0) serves as a bridge between AI-driven tools and the design system. While there is still work to do, like adding dynamic API integration and resources as tool responses, the project validates the idea that working with AI within an organization requires a definitive source of truth: one that helps clarify AI’s role in the software development lifecycle.

A lifecycle where proposals are drafted, code is written and reviewed, and teams actually refresh their understanding of the system after release. AI assistance becomes more reliable when those tasks stay tied to the same grounded context. The PatternFly MCP is the bridge between essential human-centered understanding and AI assistants.

For teams starting their own journey with creating MCPs, our experience can provide you with a clear path:

1. Start with the context: Make sure AI has access to the right information before all else.

2. Ground it in schemas: Use formal validation to focus results.

3. Build for growth: Use a modular architecture to support new tools and resources in the future.

For more details and guidance, check out our documentation on PatternFly.org.

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.

Disclaimer: This story was drafted with AI assistance. All insights and final edits are the author’s own.

PatternFly and the Model Context Protocol was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design systems have become increasingly central to product strategy across software-based organizations. For some, a design system is simply infrastructure — a repository of guidance, a component library, and documented patterns that quietly support development. For others, the system is treated as a product, complete with a focused team, intentional development practices, and delivery models designed to support internal users.

But a mature design system that provides strategic value is neither just a product nor just infrastructure. It is both.

At PatternFly, we’ve been following this dual mandate and reaping the benefits of both perspectives. We’ve learned that embracing this duality is the only way to create a system that lasts — and one that the organization values.

Here is how we balance these roles at PatternFly, and how this dual mandate can benefit your organization.

Design systems as infrastructure

When a design system functions as infrastructure, it offers organizations a critical foundation that accelerates product delivery, reduces organizational risk, and prepares for change and evolution. It becomes a utility upon which other deliverables rely.

As infrastructure, a design system’s users are dependent on the system, relying on its rules to design, develop, and ship their own work. Their dependence demands stability, reliability, and continuous maintenance that requires the design system to be more “living” than a static, shelf-bought UI kit.

PatternFly operates as strategic infrastructure in three key ways:

1. Accelerating delivery and optimizing resources

By centralizing the development of UI elements, individual product teams don’t have to reinvent the wheel. PatternFly standardizes patterns from specific product spaces, creating reusable resources that save development time across Red Hat’s entire product portfolio.

As infrastructure, PatternFly supports diverse, complex workflows. Read more about how we power multi-level navigation in Red Hat Advanced Cluster Management, enterprise tables for Red Hat Satellite, and terminal integrations for Red Hat OpenShift Platform. PatternFly provides the architectural building blocks, freeing teams to focus resources on solving unique product challenges rather than rebuilding mundane basics or customizing off-the-shelf design systems.

2. Guarding investment and mitigating risk

Perhaps the most business-critical aspect of the infrastructure model is risk mitigation. PatternFly embeds accessibility standards directly at the component level (specifically WCAG AA compliance). When a product team uses a PatternFly component, they are virtually guaranteed accessibility for that specific element, reducing the risk of releasing non-compliant software updates.

However, accessible components don’t guarantee an accessible experience. To ensure that components are assembled into final screens that are well-structured for assistive technologies, we provide guidance instructing engineering teams on how to assemble our components into holistic layouts.

Beyond accessibility, we mitigate technical risk by keeping our code packages lean to ensure fast load times. We also monitor the security standards of our third-party dependencies to quickly mitigate concerns at a system level, delivering fixes to everyone at once.

3. Managing change and evolution

A modern design system must do more than maintain consistency — it must actively facilitate change management. PatternFly functions as the “control tower” that offers the structure, architectural stability, and centralized control to manage rapid evolution.

This role is essential for the rise of Artificial Intelligence (AI) and Large Language Models (LLMs). Because AI models rely on clear, structured inputs to generate useful code, PatternFly exposes the tokens, component APIs, schemas, and documentation these models need. This ensures that AI interacts with our infrastructure to generate outputs that maintain organizational standards and brand cohesion.

Whether integrating AI or rolling out a rebrand, this centralized infrastructure allows us to manage how new features are applied — including the predictable handling of breaking changes — ensuring that enhancements benefit rather than disrupt our internal customers.

Design systems as internal products

While operating as infrastructure provides stability and risk mitigation, managing a design system as an internal product shifts the focus to adoption, satisfaction, and growth. The system’s “customers” — the internal product teams — become essential to ensuring that tangible, immediate value is delivered to those who use our system the most.

PatternFly operates as a product in three key ways:

1. Providing “customer service”

We view Red Hat’s product teams as our customers. Successful adoption of PatternFly updates is driven by cross-departmental collaboration and a dedicated enablement team that focuses on assisting products with their integrations.

This support ranges from helping with migrations to partnering on building new user experiences. We also address user needs in real-time through office hours, critique sessions, and ad hoc support via Slack. Our enablement team is even actively developing AI tooling to support code migrations and rapid prototyping, ensuring our “customer service” evolves alongside the technology our users are adopting.

2. Delivering tangible value (ROI)

Our core purpose is to deliver immediate solutions for common concerns so product teams can focus on unique features. We see this value in the high adoption of foundational elements — like buttons, selects, and text inputs — that teams would otherwise build from scratch.

But we go beyond the basics. We actively partner with products to mature new capabilities, such as our recent exploration of AI. By introducing styling for AI-generated content, conversational interfaces, and generative UIs, the system functions as an internal product that systematically proof-of-concepts and delivers new requirements.

PatternFly also supports complex, system-level experiences like our ChatBot extension, which currently powers several Red Hat products offering agentic chat. A notable success is its use in the Red Hat Intelligent Front Door experience:

“Absolutely brilliant work by all involved. We went from 0 to prototype in 2.5 weeks.

PatternFly and its Figma UI kit allowed 6 designers (and 2 managers) to literally work around the clock by handing off tasks twice a day across time zones spanning 12.5 hours.

The seamlessness and thoughtfulness that the PatternFly team put into PF6 and the AI components meant that we were able to focus on critical workflows and AI behaviors.”

— Jason Brock, UXD Manager

By enabling reusability for both simple and complex features, we drastically reduce custom coding time. The value of this strategy is best illustrated by asking, “What would happen if the system went away?” The predictable outcome — massive rework and lost capabilities — proves the system is delivering indispensable business value.

“If the system went away each team would need to spend countless hours doing similar work that would be done slightly differently with each group. I call this chaos.”

— Ali Mobrem, Senior Principal Product Manager for OpenShift

3. Aligning cross-organizational teams

PatternFly is managed as a product, led by a dedicated Product Manager who brings Design, Engineering, and Product disciplines together. By working in small, cross-functional teams to collaboratively define initiatives from the start, we guarantee alignment on strategy and vision.

Organizationally, we sit within Red Hat’s UX design and research team. This positioning allows us to champion consistency across products, integrating tightly with brand and experience teams to connect PatternFly with the Red Hat customer experience across the entire “see, buy, and use” journey.

Crucially, this structure creates a feedback loop where our roadmap is shaped by actual stakeholder requirements rather than theoretical ideals. As Tracy Rankin, a Vice President of Software Engineering at Red Hat, notes:

“Red Hat’s products would reflect the company’s internal organizational structures if not for the centralization of the design team and the existence of the PatternFly design system.”

— Tracy Rankin, VP of Software Engineering

The dual mandate amplifies value across disciplines

To mature properly and function effectively, it is not enough to be either a stable infrastructure or a helpful product. It is essential to balance both.

As a dual-function entity, we deliver distinct value to every key discipline in the organization:

• For Designers: We facilitate efficient creation, consistency, and scalability through robust resources like our Figma library and reusable components with native accessibility. We further accelerate the design-to-development handoff with specialized methods like AI-assisted rapid prototyping.
• For Product Engineers: We establish a shared technical foundation with React, providing a common language that streamlines onboarding. PatternFly also supports higher-level system concepts — such as scaling information architecture, page layouts, form flows, and complex UI patterns — which often reside in libraries above the core system. This layered support provides the flexibility teams need to innovate beyond basic functionality.
• For the Business Unit: We create a common language across Design, Engineering, and Product Management. This alignment results in faster delivery, reduced rework, and clearer scoping for predictable roadmaps. Our system also accelerates the Software Development Life Cycle (SDLC) by playing a key role in agentic explorations and enabling the rapid delivery of new features.

Securing investment with a dual-role design system

A design system is fundamental infrastructure that sustains an organization, but its long-term success relies on treating it as a product that supports and propels its internal users.

By proving a design system’s value through the impact on quality, risk, and strategic enablement — rather than just component counts — organizations can secure the investment necessary to sustain this dual role. When stakeholders understand that the design system is both the foundation of the house and the service that keeps it running, it stops being viewed as a mere toolkit and starts being recognized as a strategic asset.

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.

Disclaimer: This story was drafted with AI assistance. All insights and final edits are the author’s own.

A dual mandate for design system maturity was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Disclaimer: This story was drafted with AI assistance. All insights and final edits are the author’s own.

We’re excited to share details about the completion of our Q3 accessibility epic! Based on a comprehensive audit from earlier this year, we’ve resolved several accessibility issues to improve the user experience for everyone. This effort was two-fold: we’ve made key updates directly to our components (which you get automatically when you upgrade), and we’ve also enhanced our documentation and examples to help you build more accessible products.

How we approach accessibility

Before diving into what’s new, it’s helpful to understand the process that guides our work. To ensure PatternFly remains robust and accessible, we rely on a multi-layered approach.

First, every pull request to our codebase is checked by a custom-built, automated tool that scans for accessibility errors against axe-core. This provides a strong baseline and prevents new issues from being introduced.

But automation can only go so far. We also perform in-depth manual audits, testing our components with assistive technologies like the VoiceOver screen reader on Mac, as well as (time permitting) NVDA and JAWS on Windows. This time-consuming but critical step allows us to test interactive states — like an opened dropdown menu or keyboard navigation — that automated tools can’t cover.

Finally, we translate our findings into clear accessibility documentation. This guidance is meant to provide you with best practices and clear guidelines that explain why certain attributes are so important for an inclusive experience and how you can implement accessible components.

Here’s a look at the component-based improvements that you’ll benefit from simply by updating to the latest PatternFly version.

Built-in component accessibility enhancements

This quarter’s epic led to several out-of-the-box accessibility improvements, which you’ll get “for free” just by updating to the latest version of PatternFly.

• Clearer focus states for buttons: We’ve modified the styling of the button component’s focus indicator to be easier to perceive, ensuring users navigating with a keyboard can more easily see which element is selected.

• More reliable tooltips: We’ve resolved an issue in our React code, where tooltips weren’t correctly linked to their triggers when using refs. Now, tooltips will be correctly associated with their triggers, an important fix that also benefits components that use tooltips, like menu, select, and dropdown.
• Smoother keyboard navigation in data list: We’ve fixed a keyboard navigation issue where triggering a kebab toggle within a data list item no longer accidentally selects the entire item, creating a more predictable experience.

Updated guidance for more inclusive design

Beyond the components themselves, we’ve updated our documentation and examples to empower you to build more accessible products from the start.

• Accessible attributes for jump links: Our examples now include the expected ARIA attributes and unique naming for semantic elements, aligning with the latest accessibility standards.
• Meaningful context for skeleton loaders: We now recommend including visually hidden text for a single skeleton per context. This provides crucial information for screen reader users while content is loading.
• Added context for icon-based labels in data list: We’ve added visually hidden text to labels that only contain an icon and a number, giving more meaning to what the labels are intended to convey.
• Unique naming for interactive elements in text input group and hint: Our examples now ensure that interactive elements have unique names, helping users differentiate between similar controls on a single page.

To accessibility, and beyond

Accessibility is a never-ending journey, not a destination. There’s no finish line or “mission complete.” As guidelines and best practices evolve, so will PatternFly. Here’s a look at what we’re working on next to continue raising the bar:

• High contrast mode: We’re building a new high contrast mode theme that aims to meet WCAG 2.2 AAA compliance.
• System-wide WCAG 2.2 AA compliance: We are officially striving to comply with WCAG 2.2 AA requirements across the entirety of PatternFly, aligning with both IBM and Red Hat Design System standards. We plan to begin the first step towards this goal soon.
• AI exploration: We’re exploring how AI can help us generate and structure accessibility documentation, making our process more efficient for components still in need (don’t worry, a human will always proofread the final content).
• Audit process refinement: We are refining our manual audit process to be less time consuming, which would allow us to test our components more regularly and efficiently, ultimately catching issues sooner.

These future updates reflect our ongoing commitment to accessibility. We’re excited to continue this journey and empower you to create more inclusive products for everyone.

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.

Raising the bar for accessibility was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Disclaimer: This story was drafted with AI assistance. All insights and final edits are the author’s own.

Since its launch in early 2024, the PatternFly ChatBot extension has grown from an idea into a key tool used in more than ten projects to create consistent AI experiences. ChatBot is community driven, and the team’s goal is to keep up with community needs, saving you time and providing you with a consistent, positive experience.

Our journey of community-led improvement continues with our latest release.

Driven by your feedback, this update delivers powerful enhancements that address key usability issues and introduce new, in-demand features.

Delivering features your users need

Our work for this release was driven by two simple questions:

1. How do users feel about the PatternFly ChatBot extension?
2. How can we keep up with evolving areas in AI like model context protocol, agentic AI, and retrieval augmented generation?

To answer the first question, PatternFly designers Kayla Chumley and Lucia Boehling led a series of usability workshops. They observed users performing several tasks with the ChatBot, and the results were clear. While the extension was well-liked, participants experienced a few key pain points:

• Finding and managing chat history was difficult.
• Starting a new chat was not intuitive.
• The interface felt too dense, and users wanted more layout control.
• Modern chat features were missing, such as message editing and transcripts.

Based on this feedback, we quickly focused on designing, workshopping, and building out new features and updates that addressed these needs. The latest ChatBot release now offers:

• Clearer navigation, with a new title, icon, and “new chat” button in the chat history drawer.
• Flexible layouts, with compact components and a new demo that showcases switching between layouts.
• Modern chat features, including message separator options and new demos that showcase message and chat history items, “pinning” chat history items, and transcript downloads.

To stay ahead of the curve in AI, we also collaborated with our community to deliver features for more advanced interactions:

• Deep thinking and tool calls: New components that allow control over tool calls and display insight into your AI’s reasoning process.
• Complex interactions: Demos for adding complex interactions to messages, such as software downloads and live installation progress monitoring
• Rich media support: New modals for previewing attached images and a better handling for non-previewable files.
• Footnotes and enhanced source cards: New ways to provide more context on source material, including system confidence scores.

Your feedback is essential

We love seeing how you’re using the ChatBot extension in your projects. These new features came directly out of conversations with community members like you. The ChatBot design and development teams are small, and your feedback is essential for us.

A special thanks to everyone who gave us early feedback on the designs and API for the new deep thinking and tool calls components. We have tried to keep these as flexible as possible given the fast pace of change. We have also heard your request for Markdown support in these new components and have created an issue to track progress on that work in GitHub.

What’s next?

This is just the beginning. We’re excited to bring this more intuitive and up-to-date chatbot experience to the PatternFly community. Our next steps include a second round of user testing to validate our changes and ensure we’ve truly improved the user experience. As the AI field continues to evolve, we’ll continue to work with you to identify and build the features you need most.

We encourage you to try out our new features and explore the PatternFly ChatBot extension on our website.

What would you like to see in a future version? Share your thoughts with us by opening an issue on GitHub.

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.

Building a better bot, together was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a UX researcher, I’ve seen AI transform everyday tasks: drafting research plans, analyzing data, and even summarizing interviews. New tools emerge daily, reshaping how we work. But here’s the thing: most of us use AI individually, as a solo tool for personal efficiency, instead of unlocking its collaborative potential.

That’s a missed opportunity. What if, instead of just working faster alone, we utilized AI to work more effectively together?

The Problem I See When Using AI

When teams use AI in silos, we risk trusting it blindly, overlooking biases in both our questions and the models themselves.

Here’s a real example: We introduced NotebookLM so that product and design teams could access research data instantly. Powerful idea, right? But I noticed colleagues asking biased questions that led to equally biased answers.

For instance, someone might ask:

“Is there a need for this feature?”

The AI will dutifully return quotes that support the idea, but that’s not the same as proving the strength of the use case. The way the question is framed shapes the answer, and without others there to challenge the framing, blind spots go unnoticed.

A better question might be:

“Users mentioned [specific problem]. We’re considering [specific solution] to address it. Based on the data, what are the pros and cons users might experience? And what should we keep in mind when designing it?”

This invites the data to speak for itself, rather than serving as confirmation for a pre-decided narrative. The problem of blind spots isn’t limited to research. When a designer uses a UI generator in a silo, they might get a beautiful dashboard that overlooks key technical limitations that a developer would notice. A developer might use a code assistant to generate a wizard that functions well but misses crucial considerations for the user’s main goals that were identified in previous user research. In isolation, these AI-generated assets seem “good enough”, but they lack the collective expertise a team provides.

Learning from Paper Prototyping

This reminds me of why paper prototyping works so well in design. We don’t sketch on paper for aesthetics; we do it to strip away distractions and focus on the flow and core experience.

However, the real strength of paper prototyping lies in its collaborative nature. You sit with a PM, sketch an idea, and refine it together in minutes. While the designer sketches the UI, the product manager can check it against business goals, and an engineer can provide real-time feedback on feasibility. There’s no waiting weeks for feedback. Instead of each person holding separate mental models, you create a shared one on the spot.

Collaborative AI can work the same way: fast, iterative, and fundamentally shared.

My Solution: Collaborative AI Sessions

Instead of team members querying data alone, I run live sessions where we explore answers together.

Here’s how it works:

1. Frame the question together — I guide the team to avoid bias in how we ask.
2. Use AI live — We run the query in real time.
3. Interpret as a group — We discuss what the AI surfaced and what’s missing.
4. Add research context — Since I conducted the study (and related ones), I help connect insights to the bigger picture.
5. Decide next steps — Actions are based on both AI output and human expertise.

The result? Multiple perspectives catch bias before it misleads us. And because everyone contributes to framing and interpretation, we leave with a shared understanding, not just a shared document.

The Critical Thinking Advantage

There’s another benefit that often gets overlooked: collaborative AI strengthens our critical thinking.

When I work with AI alone, I sometimes take its answers at face value. Recent research shows this is common: we trust tech more when it behaves as expected, which means we can miss its mistakes. For example, in a study that tested the interaction with a biased robot, they found that biased robot behavior can increase human gender stereotypes, but counter-biased (pro-woman) robot behavior can significantly reduce or even eliminate stereotypical thinking in participants [2]. This study suggests that we often trust technology, sometimes even more than our own instincts.

From my experience, this tendency changes in a group setting. We’re more likely to challenge the output, spot gaps, and refine it. The responsibility to think critically becomes collective, not individual. And because the critique is aimed at the AI, not a person, it creates a safer space for questioning. The focus isn’t on who had the “right” or “wrong” idea, but on collectively improving the AI’s prompt and interpreting its output.

These collaborative AI sessions also reduce self-doubt; feedback loops are directed at the tool, not individuals, turning critique into constructive collaboration.

Why This Approach Strengthens Teams

When AI becomes a collaborative tool rather than a personal assistant, it helps interdisciplinary teams thrive by encouraging essential behaviors that research has found to be key [3]:

• Better Communication — Ideas are visualized instantly when using AI, reducing misunderstandings.
• Everyone’s Expertise Shines — AI produces quickly, but the team’s diverse expertise decides what matters.
• Safer Feedback — As mentioned, critique focuses on the AI output, not individuals, encouraging openness.
• Shared Understanding — Real-time iteration aligns teams more effectively than weeks of back-and-forth.

Beyond Research: A Broader Vision

This collaborative method extends beyond internal teams. Every individual contributes a unique understanding of the feature’s potential users and applications. Diverse perspectives offer a comprehensive view, and by integrating AI into the collaborative process, we can enrich discussions further. AI can introduce additional information and facilitate collective critique from various viewpoints, broadening the overall conversation. This approach empowers the team to think independently and utilize AI as a valuable tool, rather than relying on it as a decision-maker.

Imagine product kickoffs where PMs, designers, and engineers prototype together with AI. Instead of a slow loop of “design alone → present → refine,” you could iterate live in the same meeting.

Here’s an example scenario: a PM, designer, developer, and researcher work together using an AI tool trained on the latest PatternFly docs, or other design systems. The PM asks the AI “create a table view that….” The AI generates a quick prototype, which the designer immediately has feedback on. The designer then asks the AI “That looks good, but our users might not understand how they can manipulate the data. Let’s add more interaction to the table by…”. In that way, each member can advocate for the users’ challenges, while taking into consideration current technological limitations, or roadmap considerations.

You can even extend this to working with users. For usability testing, imagine evolving a prototype in real time with a customer. They give feedback, you tweak the design instantly, and they see their input reflected immediately. This transforms the “magic wand” concept into reality, not only gathering insights but truly empowering users to co-create.

With AI usage guidance continuing to evolve, there will be new ways to bolster this process. For example, using something like PatternFly’s recently published rapid prototyping guide [4] could help facilitate collaborative sessions like these, while adding loose guardrails to help ensure that prototypes align with best practices and existing patterns.

The Shift We Need to Make

Moving from solo AI use to human-human-AI collaboration isn’t just a workflow tweak; it’s a mindset shift. It speeds up alignment, opens new creative possibilities, and strengthens the human skills we risk losing if we rely on AI uncritically [1].

The opportunity is clear: AI is most powerful not when it makes me faster, but when it makes us better.

Sources

[1] Çela, E., Fonkam, M. M., & Potluri, R. M. (2024). Risks of AI-assisted learning on student critical thinking: a case study of Albania. International Journal of Risk and Contingency Management (IJRCM), 12(1), 1–19.

[2] Hitron, T., Morag Yaar, N., & Erel, H. (2023, March). Implications of ai bias in hri: Risks (and opportunities) when interacting with a biased robot. In Proceedings of the 2023 ACM/IEEE International Conference on Human-Robot Interaction (pp. 83–92).‏

[3] Nancarrow, S. A., Booth, A., Ariss, S., Smith, T., Enderby, P., & Roots, A. (2013). Ten principles of good interdisciplinary team work. Human resources for Health, 11, 1–11.

[4] PatternFly. (n.d.). Rapid prototyping. PatternFly. Retrieved October 15, 2025, from https://www.patternfly.org/patternfly-ai/rapid-prototyping/

If you have questions about the process, or run into any issues, please reach out to us on Slack. We can’t wait to read what you have to share!

Human-Human-AI interaction was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Co-author: Divyanshu Gupta

When the topic of open source comes up, there can be an instinct to focus more on the benefits for the project itself: the faster development, the bug fixes, and the innovation that comes from a global and diverse community. But what about the people behind the contributions? For many, contributing to an open source project is a journey of growth, learning, and finding their place in a larger ecosystem.

To truly understand how this dynamic plays out in PatternFly’s open source practices, we need to hear both sides of the story: the perspective of the project maintainer (PatternFly engineer Eric Olkowski) and the experience of the outside contributor (Divyanshu Gupta).

The Maintainer’s Perspective: A Welcome Helping Hand

I’m Eric, a software engineer and one of PatternFly’s core maintainers for the past 4 years as well as a maintainer of the open source self-learning curriculum, The Odin Project.

As an engineer on the PatternFly team, an active open source community can be a huge benefit. There’s always a backlog of issues we want to tackle but can’t prioritize due to more pressing tasks (something I’m sure many projects, open source or not, can relate to). This is where outside contributors like Divyanshu come in, and his impact on our project has been invaluable.

For any open source project, a dedicated contributor can be an incredible asset, particularly with smaller, more straightforward issues that are perfect for those with less experience. Divyanshu has helped us clear tickets that had been sitting in our backlog, enabling us to focus on larger, more complex features, while still allowing us to close out tickets that are still important for the project in different and various ways. His contributions are more than just code, though; they represent a lifeline for a team that’s juggling many different priorities.

But the benefits aren’t just for PatternFly. Divyanshu’s journey has been inspiring to watch. He has gained practical experience with new concepts, like using Handlebars for the first time, and has quickly adapted to our codebase conventions. He’s not afraid to ask questions, whether in Slack or on a pull request, and he’s taken the initiative to grab issues of varying difficulty. This willingness to engage directly with our team is great preparation for what it’s like to work on a professional team in the future. He even spoke at one of our Office Hours meetings, which is a fantastic step for anyone looking to build confidence in a public forum.

Beyond that, the potential mutual benefit lies in the fact that an engineer on an open source project like myself gets more opportunity to help support and mentor outside contributors, especially those who may be taking their first steps into the land of open source. Likewise, outside contributors like Divyanshu are able to receive feedback and insight from experienced engineers. While providing a more hands-on supporting/mentor-like role may not always be feasible (the more outside contributors or larger workload for a release, the less time we may have to be more hands-on), this potential is still a huge benefit for both sides.

Working with Divyanshu has been a pleasure, not just because of the work he’s done for our various repositories, but also because of his positive attitude. He’s incredibly easy to talk to, quick to learn, and consistently turns around quality work. Witnessing his growth has been one of the most rewarding parts of this experience, and I know he’ll continue being a lean, mean, accessibility, handlebars, React-y machine.

The Contributor’s Journey: From Student to Part of the Team

I’m Divyanshu, a final-year undergraduate student pursuing a B.Tech in Computer Science and Engineering, with a passion for making projects better through meaningful improvements.

My journey with open source began in 2023, during my second year of college. My first contribution was to a project called WasmEdge, where I wrote an installation script in Bash. It was a long process that took me about a month, but it taught me a lot about testing code and, more importantly, about communicating with maintainers.

After that, I made a few small documentation updates, but I struggled to find an issue where I could make a more meaningful contribution. I spent a year exploring different projects and learning about full-stack development, with a focus on ReactJS, TypeScript, and other related technologies.

In early 2025, I came across the Cockpit project and discovered that they used the PatternFly library for their UI/UX. This led me to PatternFly, a design library used by many Red Hat products that is actively maintained and open source.

My first pull request in the PatternFly ecosystem was for an accessibility issue, and it was a fantastic learning experience. It was the first time I had worked on a large-scale project, and it opened my eyes to the importance of web accessibility. From there, I tackled a variety of issues, from updating outdated dependencies to converting JavaScript examples to TypeScript, both of which helped me understand the codebase more clearly. I also worked on bug fixes and even a new feature request for PatternFly’s micro-animations epic.

More recently, I’ve contributed to the chatbot and core PatternFly repositories, getting to work with Handlebars and more accessibility fixes. The entire experience over the past six months has been an amazing learning opportunity. The engineers on the PatternFly team have been incredibly helpful whenever I’ve gotten stuck. I want to give a special thank you to Eric, who was a constant source of support.

I encourage anyone interested in open source to contribute to PatternFly or any other project you like. It’s an experience that will add immense value to your skills and your journey as a developer.

The key to open source success

Successful open source experiences must value and seek to understand the experience of both sides of the street. Outside contributions are inherently meaningful for open source projects; they allow new perspectives and skillsets to reinforce the evolution of the project. They can offer that critical helping hand when roadmaps grow too long. But, the experience of the contributor ultimately decides if the project will actually see community support. If the contributor’s experience is painful and fruitless, open source projects can easily lose interest before it gets a chance to take off.

The experiences in this story highlight an invaluable lesson for the PatternFly team: contributing to our codespace is a two way street. By collaborating with maintainers, contributors have the potential to make a greater impact, learn crucial lessons, and function as an extension of the core team.

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.

Disclaimer: This story was drafted with AI assistance. All insights and final edits are the author’s own.

Open source is a two-way street was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.

PatternFly is an open source design system, dedicated to building consistent, usable enterprise software. We operate on principles of transparency and community contribution, making PatternFly accessible to everyone. Our primary goal is to empower designers and developers, enabling them to work more efficiently and build better user experiences together.

We demonstrate these core principles here on our Medium publication, where we publish medium-to-long format articles with project details and the stories behind new features. We also empower members of our community to share their experiences in the field of UX.

Our community thrives of diverse voices — we welcome and encourage anyone interested to write with us! Here are some guidelines to help you create PatternFly’s next great article.

Requirements

1. In order to submit an article, you must have a Medium account and be following our publication.
2. By submitting your article, you agree to collaborate with PatternFly editors to ensure that your story aligns with our publication style.
3. Ensure your story is appropriate for our publication:

• Audience: UX industry professionals, PatternFly users, Red Hatters, and anyone interested in UX or open source design.
• Content focus: To share expertise, educate readers, and start conversations with the community about UX, open source design, and PatternFly

Writing your article

Generally, a story should focus on one of the following topics:

• PatternFly: A story about your thoughts, ideas, research, or tips for using PatternFly. This includes details about how you’re using PatternFly, as well as PatternFly-related updates.
• Open source: Your perspective on the world of open source design and development.
• UX thought leadership: Insights on design, research, development, writing, or other UX fields.

To get a better idea of how an article should flow, we recommend first reading some of our recently published pieces.

A note on AI-assisted writing

Please do not use AI to generate your entire story. While it’s a great tool for brainstorming and polishing your draft, we want your unique voice and experience to be front and center.

Even if you don’t consider yourself a writer, we want to hear your story in your words. Our editors are here to help with the rest!

Formatting your article

All PatternFly articles share a few consistent design aspects:

• Title and subtitle: Each article needs an attention-grabbing title and a short, descriptive subtitle.
• Header image: Articles begin with a header image that also serves as the story’s thumbnail. This image will be created by the PatternFly team to ensure visual consistency. To request an image, please leave a bracketed comment in your draft with a clear description. For example, [Image: A Figma blueprint-style image, with a button at the center that a mouse is hovering over. The button has a ripple design to indicate the animation.]
• Structure: Format your article with an introduction, a body with multiple sections, and a conclusion.
• Introduction: Preview the story you’re going to tell and let the intro lead into the first body section.
• Body: Add a subtitle that describes the content. Include relevant screenshots and images that help tell your story.
• Conclusion: Summarize your story and include any next steps or calls to action that you have.

Submitting your draft

Once you’ve written your article, follow Medium’s guidelines to submit your draft to our publication.

After you submit your draft, the PatternFly, our editors will do their best to review it within two weeks. You’ll be notified of any requested changes or feedback from our editors.

If you have questions about the process, or run into any issues, please reach out to us on Slack. We can’t wait to read what you have to share!

PatternFly Medium submission guidelines was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you think of animation in UIs, what comes to mind?

It’s easy to dismiss motion as a pretty decoration, something that simply brings excitement to otherwise dull interactions. And while there’s value in livening up our software experiences, what if the most effective animations were the ones you barely noticed? What if motion, like typography and color, was simply another tool to make complex products more clear and usable?

On the PatternFly team, this is a question we’ve been exploring since 2022.

As we’ve worked to integrate motion into our design system, we knew it had to be more than just a fun addition. It needed a purpose, and it needed to be true to our principles and values.

By meticulously researching and observing animation implementation in other design systems, we deliberately chose a path that prioritized the performance and stability that our users expect from PatternFly. After years in the making, we’re excited to dive into our new motion system — one that is intentional, consistent, engaging, and, above all, inclusive.

Designing for everyone with an accessibility-first approach

Even when it’s used intentionally and carefully, motion in UIs isn’t for everyone.

For some users, animation is a distraction. But for others, it’s more than just distracting–it’s harmful. Motion-based effects can trigger debilitating vestibular disturbances, and certain types of flashing can induce seizures in individuals with photosensitive epilepsy. Our intention for adding motion to PatternFly was always to help our users, not hurt them, so we took the responsibility of accessible design incredibly seriously.

Initial research, led by Sarah Rambacher, uncovered a set of strict, safety-first considerations. We learned that parallax effects and movement that runs contrary to a user’s scroll direction are highly likely to be problematic. We learned that flashing content poses specific risks, especially flashes between 5 and 30Hz and saturated red flashes.

With these clear considerations, our motion system prioritizes accessibility at its core.

• We follow the W3C accessibility guidelines to enforce a limit of either using less than three flashes per second, or ensuring that the flash is below the general flash and red flash thresholds.
• We keep our animations minimal and reduce their contrast to avoid potential triggers.
• Most importantly, we embrace the prefers-reduced-motion media query as a clear path to let users reduce the presence of animations. To ensure consistent functionality for animated components, we often reduce the animation duration to be imperceptible, rather than completely disabled. This approach prioritizes user safety without inadvertently breaking the experience.

Motion with a mission

At the foundation of our motion design philosophy is our declaration that motion in PatternFly must always serve a purpose. Well-designed animations can be powerful tools for improving usability. They can guide a user’s focus to what’s important, clarify the relationship between UI elements, and provide immediate, reassuring feedback that the system is responding to their actions.

This led us to our four guiding principles:

• Intentional: Motion should guide our users without being a distraction. It must be purposeful and simple, helping users complete their tasks and focus only on what is most important.
• Consistent: Motion should create a familiar and predictable experience. It should be applied uniformly to unify interactions and connect the user’s journey across different products.
• Engaging: Motion should captivate users and add character to the interface. It can celebrate user accomplishments and make common interactions more expressive and interesting.
• Inclusive: Motion must empower users by respecting their preferences. It must always be optional and accommodating to ensure a comfortable and accessible experience for all.

Take our expansion animations, for example. When a user opens an accordion or an expandable section, the content doesn’t just pop into view. Instead, a gentle fade and slide transition draws their eye to the newly revealed information. It’s a subtle effect, but it aligns with our principle of being intentional by guiding the user’s focus and making the new content easier to process.

Anatomy of a PatternFly animation

To ensure our animations will be consistent and scalable we developed a system of semantic motion tokens for duration, delay, and easing.

Under the hood, we chose a CSS-first approach. By prioritizing CSS transitions and animations over JavaScript-based solutions, we’re able to benefit from better performance. Because browsers are highly optimized to handle CSS animations, our animations will have smoother rendering and less technical overhead. We also focus on animating only the most performant properties, like transform and opacity, avoiding less efficient properties like height and margin that can negatively impact the animation quality.

Our decision to use a CSS-first approach was informed by a careful analysis of other major design systems, where we saw a variety of philosophies. Some relied more heavily on JavaScript, while others used less performant properties.

By analyzing the different methods being used, we could solidify our path and focus on prioritizing performance and stability.

1. Most performant actions used: Refers to using CSS properties like transform and opacity that don’t force the browser to recalculate page layouts, resulting in smoother animations and better overall performance.
2. Orchestration: Describes how an animation is triggered. MUI uses JavaScript to manage the start and end states and orchestrate CSS transitions.
3. Generally performant: While MUI might favor performant properties, some components animate height and can still lead to less smooth animations.

Now we’re movin’ and groovin’

Bringing purposeful motion to PatternFly has been a multi-year, highly collaborative marathon. The foundational system we’ve built demonstrates how animation, when treated with care, can make an interface more intuitive, accessible, and engaging.

With our initial phase of micro-animations complete, we can look toward the next horizon, like assessing performance and usability, understanding user sentiment, or even exploring more complex animations. We also look forward to ensuring that all animations are supported by default in a future breaking change release, removing the need for any opt-ins.

See the result of this multi-year effort:

• Dive into the details in our motion guidelines and developer documentation.
• Interact with the different animations in our guided animations tour.
• And let us know what you think.

Your experience will help us define what comes next.

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.

Motion with purpose was originally published in PatternFly on Medium, where people are continuing the conversation by highlighting and responding to this story.