RDRV — Digital Dispute Resolution Service
A free early-resolution and case-management service created by VCAT to help Victorian renters and rental providers resolve common disputes. I led the digital experience from early concept to public launch, across brand, public website and service portal.
01 · CONTEXT
Designing beyond the Figma file
A design system can look complete in Figma while leaving a significant gap between design decisions and production implementation. I created Chavosh Financial as a self-directed project to explore that gap: not only how to build reusable foundations and components, but how those decisions could travel consistently through tokens, code, documentation and testing. The goal was to create a system where design decisions remained understandable and traceable beyond the design file.
[ADD FIGMA VISUAL]
02 · CHALLENGE
How do you keep design and implementation speaking the same language?
The challenge was not simply creating a component library. The harder problem was maintaining consistency as the system moved between different representations: Figma variables define design decisions. Tokens translate those decisions into reusable data. Components apply them to interface patterns. Code implements those patterns. Storybook documents and tests their behaviour. Without a clear architecture, each transition creates another opportunity for design and implementation to drift apart.
DESIGN · Figma Variables → SYSTEM · Design Tokens → IMPLEMENTATION · React Components → DOCUMENTATION · Storybook → VERIFICATION · Design ↔ Code checks
03 · ARCHITECTURE
Building the system in layers
I structured the system so raw design values were separated from their semantic meaning and their use within components. This allowed the same foundations to support multiple brand expressions without requiring components to be redesigned.
FOUNDATIONS ↓ PRIMITIVE TOKENS ↓ SEMANTIC TOKENS ↓ COMPONENTS ↓ PATTERNS / PRODUCT UI
Figma → Tokens → CSS / React → Storybook
04 · TOKEN ARCHITECTURE
Separating values from intent
Rather than allowing components to depend directly on raw values, I used a layered token architecture. Primitive tokens define foundational values such as colour, spacing and radius. Semantic tokens describe intent — for example background, text, border or action roles. Components consume those semantic decisions rather than depending directly on raw values. This creates a clearer relationship between design intent and implementation while making system-wide change easier to manage.
PRIMITIVE · Raw value → SEMANTIC · Design intent → COMPONENT · Applied decision → IMPLEMENTATION · CSS / React
72 Public Tokens
[ADD TOKEN ARCHITECTURE]
05 · MULTI-BRAND
Shared structure, different expression
The system was designed to support two brand modes while keeping the underlying component architecture shared. Instead of duplicating components for each brand, brand-level decisions can resolve differently while the component structure and semantic intent remain consistent.
Shared foundations + Brand-specific tokens = Consistent components with distinct brand expression
2 Brand Modes
[ADD TWO-BRAND COMPONENT COMPARISON]
06 · COMPONENTS
Designing reusable behaviour, not just reusable UI
Components were designed as systems of behaviour rather than isolated visual elements. Variants and properties were used to manage size, hierarchy, state and interaction while keeping the underlying structure reusable. Across the Figma system: 162 component variants.
[ADD COMPONENT SHOWCASE]
07 · DESIGN → CODE
Creating a traceable path from Figma to implementation
The next step was testing whether the system architecture could survive outside Figma. Design tokens provided the bridge. AI-assisted development helped accelerate repetitive implementation work, but the system architecture, component decisions, visual direction and acceptance criteria remained designer-led.
FIGMA VARIABLES → DESIGN TOKENS → STYLE DICTIONARY → CSS VARIABLES → REACT COMPONENTS → STORYBOOK
DESIGNER-LED · Architecture · Design decisions · Component behaviour · Visual direction · Acceptance criteria
AI-ASSISTED · Implementation scaffolding · Repetitive transformations · Verification support · Testing support
08 · STORYBOOK
Documentation that can be inspected, not just viewed
Storybook became the implementation-facing documentation layer for the production slice of the system. Rather than relying only on static design specifications, components could be inspected across variants and interaction states in a working environment.
[ADD STORYBOOK SCREENSHOT]
6 Production Components · 52 Storybook Stories · 27 Interaction Tests
09 · VERIFICATION
Closing the gap between design and implementation
Generating components was not enough. The implementation needed to be checked against the decisions defined in the design system. I used a structured verification process to compare token relationships, component states and implementation behaviour. The implemented production slice passed 29/29 verification groups; this does not imply that every possible interface in the broader system was tested.
TOKEN RELATIONSHIPS ✓ COMPONENT STATES ✓ IMPLEMENTATION BEHAVIOUR ✓
10 · ACCESSIBILITY
Accessibility as a system decision
Accessibility was considered at the system level rather than treated as a final review step. Reusable decisions around colour, focus, interaction states and component behaviour help accessibility requirements propagate more consistently across the interface.
COLOUR CONTRAST · VISIBLE FOCUS · INTERACTION STATES · SEMANTIC IMPLEMENTATION
11 · REFLECTION
A design system becomes valuable when its decisions can travel
This project changed how I think about the boundary between design systems and implementation. Reusable Figma components are only one part of scalability. The greater challenge is ensuring that the same decisions remain understandable as they move through variables, tokens, code, documentation and testing. Chavosh Financial gave me a practical way to explore that complete lifecycle while keeping the design decisions human-led and using AI where it could accelerate execution and verification.
I designed the system. AI helped me operationalise and verify it.
The system, in evidence
340 Figma Variables · 162 Component Variants · 72 Public Tokens · 6 Production Components · 52 Storybook Stories · 27 Interaction Tests · 29/29 Verification Groups · 2 Brand Modes
Overview
Resolving rental disputes without a hearing
Rental Dispute Resolution Victoria is a free early-resolution and case-management service created by VCAT to help renters, rental providers and their representatives resolve common rental disputes fairly and efficiently.
I contributed across discovery, service design, branding, product design, accessibility and delivery — spanning the public website, the myRDRV portal and internal tools.
Problem
Many disputes don't need a tribunal hearing
Many rental disputes — bonds, repairs, compensation and rent increases — can be resolved through facilitated discussion rather than formal tribunal hearings. People needed clear guidance, fair information and confidence about their next steps.
Approach
Four principles from discovery
Contextual discovery and research synthesis led to four design principles: No wrong front door. Tell people the bad news early. Capture information at the right time. One coordinator, start to finish.
Alongside the service design, I developed a brand system and design framework that balances human and authoritative qualities.
Outcomes
From concept to public launch
RDRV launched publicly as a new digital service and was nominated for a Good Design Award (service and team recognition).
[Add adoption and resolution outcomes from the full case study.]
