myVCAT — Notice Creation Experience
Designing accessible legal notice creation for 280+ notice types across Victoria's Civil and Administrative Tribunal — making a high-stakes, form-heavy process usable for people who aren't lawyers.
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
The entry point into legal proceedings
I designed the notice creation experience within myVCAT's digital case management ecosystem. A notice is the entry point into legal proceedings, so errors can delay or reject a case.
The challenge was to make the process accessible to non-lawyers while maintaining legal accuracy across 280+ notice types and multiple user roles.
Problem
Complex, error-prone and overwhelming
The existing notice creation process was complex and difficult to navigate, highly error-prone (around 50% of applications were unsuccessful), dependent on rigid form-heavy systems, and overwhelming because of legal language and unnecessary fields — despite serving more than 400,000 users each year.
Approach
One adaptable system instead of 280+ flows
I reframed the problem to capture only the details relevant at each stage, and worked iteratively with legal reviewers to deliver within real constraints. Research-led design drew on usage data and stakeholder workshops.
Rather than designing 280+ separate flows, I designed a scalable, adaptable system — and improved key flows including onboarding, field simplification and new review-and-confirmation steps.
