Senior Product Designer · Digital Products · Tokyo
Project metadata
My role: UX/UI Designer (Contract)
Type: B2C member self-service portal
Platform: Legacy system / RACV design system
Duration: October 2024 – June 2025
Case study · RACV · 2024–2025
Making self-service actually self-sufficient
UX/UI design for RACV's Member Online Account platform — modernising legacy insurance and membership flows for over one million members within a Salesforce-integrated ecosystem.
The Problem
RACV's Members Online Account (MOA) is the primary digital touchpoint for over one million members — covering insurance policy management, membership details, payments, and more. The platform had grown over time on a legacy system, and the gap between what members expected from a digital self-service experience and what MOA actually delivered had become significant.
Key flows were visually inconsistent with RACV's current standards, hard to navigate, and in some cases actively confusing — particularly around financial transactions. Members trying to understand the status of a payment or refund were confronted with raw back-end data labels that meant nothing to them.
A further gap: members who wanted to change their address on an insurance policy still had to call and speak with a representative. In 2024, that expectation was out of step with how members wanted to interact with their insurer.
My Role & Scope
I was brought in as a contract UX/UI designer to support RACV's digital transformation across MOA. My work spanned two interconnected work streams: designing net-new features for the modernised platform, and uplifting legacy interfaces to meet RACV's current design system standards.
Key pieces of work included:
• Payment and refund tracker redesign
• Address change self-service flow, from rep-only to fully digital
• Policy management UX/UI uplift across key flows
• Driver editing experience, context persistence and way finding
Process
• Discovery & stakeholder research
I familiarised myself with the MOA platform end to end, mapping existing flows and identifying where the legacy experience fell short of both user expectations and RACV's updated design standards. This gave me a clear picture of scope before any design work began.
​
• Design within legacy system constraints
All design work had to work within RACV's existing component library and design system — which shaped component decisions throughout. The constraint was to achieve the clearest, most usable result within what was available, without requiring changes to the underlying data layer.
​
• User interviews & usability testing
For the address change flow, I tested with internal RACV staff who held both RACV policies and policies with other insurers. This dual perspective was valuable — it surfaced global UX conventions that members expected (predictive address entry, dropdown selects for static fields like title, clear confirmation states) that the legacy flow was missing entirely. ​​​
​
• Iterative prototyping & handoff
Hi-fi Figma prototypes were used throughout for stakeholder review, development handoff, and usability validation.
Design Highlights
Payment & refund tracker
The existing transaction history presented payments and refunds in a single chronological table, most recent first. Refunds were scattered throughout, displayed with internal Salesforce data labels that were meaningful to the business but opaque to members.
My solution was structural: I separated payments and refunds into two distinct table views, connected by a tab navigation so members could switch between them on the same page. For the refunds table, I worked backward from what a member actually needs to know — amount, date, status — and redesigned the frontend display to show only that, stripping away the back-end noise without changing the underlying data architecture.
Address change from rep service to fully digital
Previously, any member wanting to update their address on an insurance policy had to call RACV and speak to a representative. My brief was to design a self-service version of this flow within MOA.
User research surfaced three clear expectations that the legacy system hadn't met: predictive address lookup when typing, dropdown selects for static fields (rather than open text), and a clear confirmation screen showing the proposed change before submission — giving members a chance to review and correct before committing.
The resulting flow was intentionally minimal. No unnecessary steps, no ambiguity about what had changed or what would happen next.
Driver context persistence
RACV insurance policies can have multiple named drivers. When a member selected a driver to edit and began working through the flow, there was nothing in the interface to remind them which driver they were currently amending. On policies with three or four drivers, this created real risk of error.
The fix was simple but meaningful: I added a persistent heading throughout the edit flow displaying the driver number and name as listed on the policy. No extra screens, no extra interactions — just the right information, anchored in the right place. It's the kind of detail that members never notice when it works, but immediately feel the absence of when it doesn't.
The Outcome
The user research conducted for the address change flow was adopted as a primary driver of the MOA product roadmap, informing how subsequent self-service features were scoped and prioritised. The payment and refund tracker, driver context improvements, and address change flow were all delivered within the contract period as part of RACV's broader MOA modernisation programme.
Key Constraints & Decisions
-
All design delivered within RACV's existing component library — component choices were prescribed, but implementation quality was not.
-
Testing was conducted with internal participants rather than external members due to access constraints — mitigated by recruiting participants with multi-insurer experience to broaden perspective.
-
Back-end data structures could not be changed — frontend redesigns had to achieve clarity for members without touching the underlying data layer.