Redwood UX: What Actually Changes and What to Test
Redwood isn't just a fresh coat of paint. Some flows move, some behave differently. Go in knowing what to check, not assuming it's cosmetic.
Redwood gets sold as a visual refresh, and that undersells it in a way that bites teams who treat the migration as cosmetic. The look changes, yes, but so do some flows and behaviours. Go in testing, not assuming.
Know which pages have moved to Redwood
Oracle's rolling Redwood out page by page, release by release. Know exactly which flows your users touch have flipped, because a half-Redwood, half-classic experience confuses people if you haven't prepared them.
Re-test your extensions and personalisations
Personalisations and page customisations built on the classic pages don't automatically carry over. Anything you've tailored needs re-checking in Redwood, or you'll find a customisation the business relies on has quietly vanished.
Update your training and screenshots
Every bit of training material, every screenshot in a user guide, goes stale the moment Redwood lands on that page. Refresh them before go-live, or your help content actively misleads people.
Real scenario: a client let a Redwood update roll through without checking, and a personalisation that hid a sensitive field on the classic page didn't exist in Redwood. The field was suddenly visible to managers for a fortnight before anyone noticed. We now treat every Redwood wave as a proper test cycle, not a passive update. Assume nothing, test everything.