Oracle Redwood Design System

The challenge

A component couldn’t be designed for one screen. It had to work across an ecosystem.

1. 01

   Different products exposed different needs

   Oracle products spanned industries and workflows with very different requirements. A component that worked well in one context could break down in another, so the interaction model needed to account for variation across real product use cases.

2. 02

   Consistency without over-constraining

   Redwood needed predictable interaction rules to create consistency across Oracle, without becoming so rigid that components could no longer adapt to legitimate enterprise workflows and edge cases.

3. 03

   Making interaction intent transferable

   Redwood was built across specialized teams including Interaction Design, Visual Design, Motion Design, Accessibility, Product, and Engineering. My interaction work would continue through other specialized teams before reaching implementation.

   The interaction intent therefore needed to remain clear as the component moved across disciplines. That required defining behavior, states, constraints, responsiveness, accessibility requirements, edge cases, and rationale with enough clarity that downstream teams could continue the work without losing the intent behind the interaction model.

Key decisions

1. 01

   Start with real product use cases

   Design the component from the ecosystem inward.

   A reusable component needed to represent the reality of Oracle’s products, not an idealized standalone pattern. I gathered examples from product teams, reviewed existing implementations, and worked with partners to understand where current patterns worked, where they broke, and what requirements the new component needed to support.

   UX audits, interface inventories, sourced product examples, competitive analysis of established B2B design systems, and conversations with Product and Engineering were the material for understanding the system — not a sequence of process steps.

2. 02

   Treat the spec as an interaction contract

   A component specification needed to answer more than “what does it look like?” It needed to define how the component behaves, when to use it, where its boundaries are, and how it adapts.

   I defined the interaction model across usage, anatomy, behavior, states, limitations, responsiveness, accessibility, and edge cases. The goal was not simply to design the default state, but to make the rules explicit enough that the component could remain predictable across different Oracle products.

   The documentation itself was the design work: a contract other teams could build from, not a picture of a single happy path.

   

   

   

   

3. 03

   Resolve ambiguity before the component leaves Interaction Design

   Reviews were part of the design process, not simply final approval.

   Because each component moved through several specialized teams, the interaction model needed to be clear before it moved downstream. I used feasibility conversations with Engineering, stakeholder reviews, accessibility evaluations, and usability feedback to surface missing requirements and resolve interaction questions before handoff.

   Engineering helped expose feasibility constraints. Accessibility reviews challenged interaction assumptions. Usability feedback helped validate behavior. Stakeholder conversations surfaced missing product contexts.

   Iteration happened before the interaction specification moved downstream.

Outcome

The system

The interaction model had to be systematic enough to hold across products. These are the questions a Redwood specification needed to answer before the component moved on.

The complexity varied from component to component, but the principle remained the same: interaction rules needed to be explicit enough to work consistently across Oracle products and downstream disciplines.

1. 01

   Usage and boundaries

   When should the component be used—and when should it not?

2. 02

   Anatomy and behavior

   What elements make up the component, and how should they respond to interaction?

3. 03

   States and edge cases

   How should the component behave outside the happy path?

4. 04

   Responsive behavior

   How should the interaction adapt across layouts, devices, and product contexts?

5. 05

   Accessibility

   What requirements need to be part of the interaction model from the beginning?

Structured input pattern

Interaction-dense component

Contribution to Redwood

1. 01

   Reusable interaction models

   Patterns designed to support multiple Oracle products, workflows, and contexts.

2. 02

   System-ready specifications

   Detailed interaction rules and constraints that gave downstream design teams a shared foundation to build from.

3. 03

   Accessibility built into behavior

   Accessibility was considered as part of the interaction definition rather than treated as a final check.

The interaction specifications contributed to Redwood’s shared component and template system, giving Oracle product teams a common foundation for bringing the new experience into complex enterprise workflows.

Looking back

1. 01

   Designing a system means designing for contexts you don’t control.

   A component had to remain useful across products, workflows, and teams I would never directly design for. That pushed me to think in rules and boundaries rather than individual screens.

2. 02

   Edge cases are where a system proves itself.

   The default state was usually the easy part. The real design work was defining how behavior held together across different states, constraints, accessibility requirements, and product contexts.

3. 03

   System decisions have to survive across teams.

   Redwood was built by specialists across Interaction Design, Visual Design, Motion, Accessibility, Product, and Engineering. My work had to be explicit enough that the interaction intent could remain intact as the component moved through each discipline.