A unified scheduling pattern built inside Oracle's Redwood Design System, serving clinicians managing outpatient care in Oracle Health and recruiters tracking candidate interviews in Oracle Fusion HR.
Oracle Health and Oracle Fusion are two of Oracle's largest enterprise product lines. One serves the clinical workflows of health systems and physician practices. The other powers the HR operations of the world's largest organizations. Both needed the same thing: a scheduling experience that could surface the right information at the right moment for high-stakes, time-pressured users.
The work was built inside Oracle's Redwood Design System, Oracle's unified design language, which meant every pattern decision had to hold across both platforms without compromise. A clinician reviewing their patient schedule and a recruiter tracking a candidate's interview day are doing fundamentally different work, but the underlying cognitive demands are remarkably similar: who is this person, where are they in the process, what do I need to do next, and when.
The challenge was to design a scheduling component system with enough structural integrity to serve both domains, while remaining flexible enough that each platform's context came through clearly.
Before a single component could be designed, the team had to understand what scheduling actually meant in each domain, and where the experiences needed to converge.
In both Oracle Health and Oracle Fusion, the existing scheduling experience was organized around time, not around people, status, or action. That distinction matters enormously when you are managing twenty patients or ten candidates in a single day.
The root problem was identical across both platforms: the scheduling view surfaced time and appointment data, but not status, progression, or urgency. Users had to hold the missing context in their heads, or navigate away to find it. In clinical care, that cognitive overhead directly affects throughput and patient safety. In recruiting, it creates pipeline friction and candidate experience failures.
The opportunity was to reframe both scheduling experiences around the questions users were actually asking, and to do it through a shared Redwood component that could serve both platforms without requiring parallel design efforts.
The Redwood Design System provided the infrastructure: a consistent token system, established interaction patterns, and cross-platform governance. The design challenge was to use that infrastructure to build a scheduling pattern that treated people, patients, candidates, as the primary unit of organization, with time as a supporting signal rather than the organizing principle.
The Clinician Organizer and the Interview Schedule share a single Redwood component architecture, designed once, implemented across two platforms serving millions of users.
Oracle Health, Clinician Organizer: patient flow, room status, chief complaint, and care-stage progression for outpatient physicians
Both implementations share the same component anatomy, the same token-based status system, the same accessibility standards, and the same interaction model. What differs is the data each platform provides and the actions each user can take.
The clinical scheduling experience in context, patient rows with live status, room location, and priority signals surfaced without secondary navigation.
Oracle Redwood is the design system that governs the visual and interaction language across Oracle's entire product portfolio. Building inside Redwood meant every decision had to be defensible at the system level, not just within a single product.
The scheduling pattern was not a one-off component. It was a contribution to the system itself, designed to establish a reusable model for any Oracle product that needs to represent sequential, status-driven interactions involving people moving through a process.
| Component layer | What was governed | Flexibility surface |
|---|---|---|
| Row anatomy | Fixed layout: person identity, status indicator, context fields, action zone | Context field schema per platform |
| Status system | Fixed token set: scheduled, active, pending, complete, urgent | Label copy per platform context |
| Information hierarchy | Tier 1 fields always visible, Tier 2 default, Tier 3 on demand | Field assignment per platform |
| Interaction model | Fixed: row selection, inline action disclosure, keyboard navigation | Action set per platform workflow |
| Accessibility | Full keyboard nav, screen reader structure, focus management | None, non-negotiable |
End-to-end ownership meant defining the workflow before touching the component, and establishing the patterns before either platform team started building.
Building a shared pattern for two platforms with fundamentally different users, data models, and organizational stakeholders is a different kind of design problem. The component has to be right for both, or it serves neither.
Whether you're exploring new solutions or improving what you already have, I am here to help.
Get in touch