Building toward a system that didn't exist yet
The hardest systems work is building for a standard that hasn't shipped, so the gap never reaches the user.
How I rebuilt an enterprise authoring tool onto a design system that was still being invented, one release at a time.
Context
Message Designer is an enterprise email authoring tool, a visual builder where marketers compose the emails and templates their campaigns run on. The work was building it on Oracle's emerging Redwood Design System (RDS), a system that barely existed when the work began.
Before RDS there was no shared standard to inherit. UI was assembled by hand, team by team. RDS itself arrived in pieces: it started with components, and there was a long lag between seeing a component announced and being able to build with it. The Canvas Page Template, the template we'd eventually need, wasn't even announced when the rebuild started. We began with the RDS components that existed, and once the template was announced and confirmed, we pivoted toward it, even though only its header had actually shipped.
The rest we had been shown, not given.
not given.
The Redwood Design System, as it arrived
The Tension
Build it to behave like a system that didn't exist yet.
The build can't move forward. Blocked on a system still being invented, on a schedule no one downstream controlled.
Technical debt from day one. Off-standard, and stuck owning accessibility yourself instead of inheriting it vetted from RDS.
The only way through was to build for a target still being drawn. And the target kept moving.
Build placeholders shaped like the future
Oracle's doctrine was to use the largest possible asset: start at the template level, because its accessibility was already built and tested, and only drop down when a level couldn't do the job. Never go custom.
So the placeholders were never free-form. They were assembled from the RDS components that did exist, arranged to stand in for the Canvas Page Template sections that didn't yet, so that when the real section shipped, convergence would be a swap, not a rebuild.
More work up front, building to a spec I didn't control and couldn't yet touch, in exchange for a clean migration later instead of a teardown.
Phase the build to the RDS release schedule
RDS shipped by releases. We would be told what a component could do now, and what it would gain one and two releases out. So I built with what existed and planned for what was coming.
The harder part was never the building. It was the conversation. Every feature carried a version of it: what could ship now, and what had to wait for a later release.
I was the translation layer between RDS's release schedule and our product's roadmap.
Accept shipping partial capability now, betting on a release schedule I didn't own, in exchange for never having to tear down and rebuild as the system matured.
Close the design-to-engineering gap
The swap was never truly clean. Oracle ran on two front-end platforms, OJET and Spectra. RDS components were only somewhat aligned across both, and depending on the section, one or the other had to be used. That ambiguity is exactly what led engineering to build with the wrong one.
Identify the correct component for the platform that section required, point engineering to the exact documentation, then review the build together so nothing was left to guesswork.
Place the component, the specific options in use, and a link to the exact documentation right beside the design. Engineering could click straight through and verify.
What this really was
The RDS team was learning their own system as they built it. Ours was learning it as we consumed it.
Designing well under that meant treating them as partners working a hard problem in parallel, not an obstacle whose unfinished work was slowing us down. And it was the earlier decisions that made the empathy affordable: because we had built placeholders and phased to the schedule, an RDS shift was a swap, not a catastrophe.
The Honest Outcome
As RDS shipped, placeholders were swapped for real components. The OJET/Spectra split made every swap a verification job, not a drop-in. But the migration held, and the tool ended up on-standard.
Because we had built to the known release schedule, maturing the product mostly meant swapping pieces in, not tearing anything down. The forward-compatible bet paid off.
The forms and landing page designers adopted the embedded-documentation step into their own work. It closed a gap that wasn't only mine.
The consistency built here is why the AI pattern later carried cleanly across Message Designer, the landing page designer, and the forms designer.
Build toward the standard before it exists, and when it arrives, there's nothing to tear down.