What is Redwood and why people are confused

What is Redwood and why people are confused

When I first heard about Redwood, it was described primarily as a design system, with the goal of unifying the look and feel across Oracle applications. That foundation still exists today with Oracle’s Redwood design system defining visual patterns, components, spacing, and typography.

Where confusion often comes in is that Redwood didn’t stop at being a design system.

As Redwood evolved, it expanded beyond visual consistency into a broader application experience framework. The focus shifted from just how fusion looked to how it behaved with an emphasis in performance, responsiveness, extensibility, and consistency across products. Over time, this evolution also created the foundation to introduce new capabilities, such as AI driven experiences.

Because of this development, Redwood is sometimes described as a “new UI,” a “theme,” or even a “new platform.” In reality, it’s none of those individually, it’s the standardized experience layer Oracle is using to modernize Fusion applications while keeping the underlying architecture intact.

How Redwood fits into Fusion CX architecture

To understand where Redwood fits architecturally, it helps to contrast it with how many of us experienced ADF-based pages.

With ADF, pages are designed so that much of the interface loads at once, rather than loading individual sections independently. While this model has been reliable for years, it can also introduce performance limitations, especially as pages grow more complex.

Redwood, on the other hand, is built on a more modular, Oracle JET–based front-end architecture. Instead of treating a page as a single unit, Redwood uses component-driven layouts where individual sections of a page load independently. This means the system only renders what’s needed at a given moment, which directly contributes to faster load times, more responsive navigation, and smoother interactions.

From an implementation standpoint, this architectural shift enables many of the benefits we now associate with Redwood: improved performance, more flexible layouts, and a consistent experience across applications. Additionally, this change is focused on the experience layer not a rewrite of Fusion’s core backend. Business objects, security models, and integrations continue to operate on the same proven foundation.

Practical guidance for Redwood adoption

When thinking about Redwood adoption, I believe it opens the door for teams to take a more intentional approach to design and delivery, especially for custom experiences.

In past projects, UI considerations were often constrained by the limitations of ADF, which made deep customization more difficult. With Redwood, those constraints are significantly reduced. This creates an opportunity to better align Scrum-based delivery with UX and UI practices such as planning experiences early, validating designs, testing assumptions, and iterating before and during build.

Rather than treating the UI as something finalized late in the project, Redwood allows teams to design, test, and refine user experiences incrementally, while still maintaining consistency with Oracle’s standard look and feel. For customers with custom requirements, this approach can lead to solutions that feel purpose-built without feeling disconnected from Fusion.