Unhedged — Mobile Investing Redesign
Redesigning the mobile investing journey on iOS and Android — from sign-up to first investment — so people without a financial background feel confident.
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
Investing can be intimidating
Investing can be intimidating for people without a financial background, and Unhedged's mobile app wasn't helping. Sign-up and first-investment flows lacked clear guidance, so new users often lost confidence and dropped off before completing key tasks.
I redesigned the mobile investing experience across iOS and Android, focused on streamlining the journey from sign-up to a first completed investment.
Approach
Research-driven priorities
I ran stakeholder workshops using Lean Canvas, guerrilla usability testing with existing and new users, and a competitive analysis of other platforms, then used affinity mapping to turn findings into actionable priorities.
Design
Clarity and trust at every step
The redesign introduced a simplified, step-by-step onboarding flow; restructured investment information for easier scanning and comparison; trust signals and clear feedback at critical decision points; consistent navigation patterns; accessible layouts for complex financial data; and contextual guidance with progress indicators.
