SCROLL TO EXPLORE
Ready X: Making complex crypto interactions feel simple, safe & intuitive.
Senior Product Designer
Core Product Flows
Design Systems
Interaction & Motion
Animation
Mobile & Web
Ready X is a crypto wallet for managing assets, trading, staking and DeFi. I worked across the product to simplify complex flows, improve the mobile experience and create stronger, more consistent systems for interaction and motion.
Vibe coded a new onboarding flow using Claude.
The Challenge
Ready X had started life as a desktop-first product and was still evolving on mobile. It carried a lot of technical complexity, and some of the existing patterns did not translate cleanly to a smaller screen.
My focus was on making the experience feel simpler and more considered without stripping away the power experienced crypto users expected. That meant improving high-trust flows, creating more consistent patterns and making sure the mobile product felt designed for mobile, rather than adapted from desktop.
Tools
- Figma
- Rive
- Lottie
- Claude
- Adobe
- After Effects
- Webflow
When I joined..
What I was asked to do
With my experience across mobile products and complex systems, I was asked to take a broad look at where design could have the most impact. I reviewed the existing mobile experience, competitor patterns and technical constraints, then turned those findings into clear priorities for the product.
What it led to
Clearer flows
Less ambiguity around high-trust actions.
More consistency
Shared patterns across key parts of the product.
Greater confidence
Clearer feedback at important interaction points.
More reuse
Systems and patterns that could be carried into new features.
Float like a butterfly, sting like a bee.
Ready was a fast-moving startup, so I looked for ways to improve the quality of the product without slowing the team down. I worked closely with engineering, using lightweight prototypes and code to test ideas quickly and make interaction decisions easier to discuss and implement.
One of the first opportunities I spotted was motion. Rather than treating each interaction as a one-off, I created a reusable micro-interaction system for the app’s core components, defining states, easing, spring behaviour and haptics.
Reusable by design
Patterns could be applied across navigation, transaction states and new features.
Clearer for engineering
Rive files, motion specs and implementation notes gave developers a shared reference.
More consistent product feel
Common behaviours and feedback made interactions across the app feel more cohesive.
Projects
A closer look at some of the product, system and interaction work I led across Ready X.
The prototype below shows how those ideas came together in the product before I break down the individual decisions in more detail.
Clickable prototype of major screens
Private send
Designing trust into private sends & shielding
Private Send supported two related actions: sending private funds to someone else, and shielding funds into a private balance.
The challenge was making the privacy model clear without slowing down experienced users. I focused on creating the right checkpoints around intent, fees, recipients and confirmation so users could move quickly while still understanding exactly what would happen before they committed funds.
Hypotheses 🤔
Explaining shielding at the moment it becomes relevant will reduce confusion.
Showing available and shielded balances separately will improve comprehension.
Presenting Shield as part of the Private Send journey will feel more coherent than exposing it as an unrelated feature.
Showing fees and ETA before confirmation will increase confidence.
Clear progress states will prevent users from assuming funds are lost.
A first-time explanation will be useful, but repeat users should be able to move quickly.
Risks ⚠️
User understanding
Users understand the term “Shield.”
Users know why shielding is necessary.
Users understand the difference between shielded and available funds.
Users know when their money becomes private.
User behaviour
Users will read an explanation before proceeding.
Users will tolerate an additional step before sending.
Users will notice if their shielded balance is too low.
Users will review fees and estimated completion time.
Trust
Users believe the privacy claim.
Users understand what information remains visible.
Users feel safe confirming the transaction.
Users understand what happens after confirmation.
Technical and product risks
Transactions may take longer than expected.
Fees may change.
A shielding transaction may fail.
A user may leave during processing.
The balance may not refresh immediately.
Shielding may succeed but Private Send may fail.
01
Establish the privacy model
Before users took action, the flow needed to establish what changed when a transaction became private.
The experience clarified what was protected, what remained visible, and what tradeoffs users needed to understand before committing funds.
Asset context
Anchors the action in the correct asset, balance, and wallet state before introducing private transaction options.
Private Send intro
Frames privacy as a distinct transaction mode, setting expectations before setup begins.
Privacy model
Clarifies what metadata is protected, what remains visible, and what tradeoffs the user should understand before committing funds.
02
Support multiple transaction paths
Private Send was not one linear flow. The system needed to support sending to different destination types, shielding funds into a private balance, and unshielding funds back out.
Rather than treating each path as a separate product, I structured the experience around shared patterns: amount entry, fees, review states, confirmation, and transaction details.
Path decision
Routes users based on intent and balance state, avoiding dead ends when private funds are not yet available.
Recipient selection
Keeps outbound recipient choice explicit, reducing address ambiguity in the highest-risk input step.
Shield funds
Supports the self-shielding path, where funds move into the user’s private balance without an external recipient.
Amount entry
Surfaces balance, amount, fee, and total in one decision surface before the user reaches review.
03
Create confidence at commit
The final stages focused on control and verification. Review states gave users a clear checkpoint before action. Confirmation added deliberate friction. Success and transaction details gave users confidence after the transaction was complete.
Review send
Creates a pre-commit checkpoint for recipient, amount, fee, and Private Send status.
Review shield
Confirms source, destination, amount, and fee before funds move into a private balance.
Confirm
Adds deliberate friction at the final moment to prevent accidental sends or shielding actions.
Transaction details
Surfaces balance, amount, fee, and total in one decision surface before the user reaches review.
Explore the full flow
The full Figma board includes the wider transaction system, edge cases, shielding and unshielding paths, recipient setup, review states, and first-time user education.
Why it mattered
By creating a consistent model for account types, setup and controls, the wallet could support more complexity without making the experience feel more complicated.
It also gave the product a clearer structure for adding new account types and capabilities over time.
Interaction behaviour
Raising the product feel, quickly.
Ready X had grown quickly, and interaction behaviour wasn’t always consistent across the app. Some actions felt responsive and polished, while others lacked the feedback you’d expect from a high-quality mobile experience.
Rather than improving these moments one by one, I created a lightweight motion system for core components and states. The aim was to make the product feel more responsive and intentional, while giving engineering a reusable set of patterns that could be applied as the product grew.
Motion, made reusable
I created reusable motion patterns for core interactions, then turned them into shared tokens and implementation guidance so the same behaviour could be applied consistently across the product.
Motion System
Motion Patterns
Interactive reference for every motion pattern. All values are live — press, tap, and trigger to preview the exact tokens used across the app.
How the handoff worked
duration: Tokens.motion.base
curve: Tokens.ease.outSnappy
Self-documenting. No magic numbers. No guesswork.
Design → Dev
Motion and haptics added to an existing app — no rebuild, no disruption.
Rather than redlining every interaction individually, I defined the system as tokens. Developers received one reference doc — token name, resolved value, and usage rule. No ambiguity, no back-and-forth, no follow-up calls.
Token Reference
Pattern 1
Press Feedback
Live demo
Press and hold any element — spring.press releases on finger up
What dev received
Pattern 2
Surface Entry
Live demo
Slides in from Y+24 · holds 1500ms · exits with ease.in.standard
What dev received
Pattern 3
Expand / Collapse
Live demo
Only two states: collapsed or fully expanded — no mid states
What dev received
Pattern 4
Chart Data Reveal
Live demo
Switch periods to re-trigger the draw animation
What dev received
Pattern 5
Skeleton Loading
Live demo
What dev received
Pattern 6
Balance Count-up
Live demo
What dev received
Pattern 7
Haptic Visualiser
Live demo
Tap each to see the intensity difference — rings = haptic weight
What dev received
Pattern 8
Success Particle Burst
Live demo
Press fires particles + haptic.success, then toast enters
What dev received
Pattern 9
Screen Navigation
Live demo
Tap Bitcoin row to navigate · Back to return
What dev received
What this unlocked
The motion system did more than add polish. It gave Ready X a more consistent interaction language, especially around navigation and transaction feedback, while giving engineering reusable patterns they could carry into new features.
More consistency
Common interactions behaved in predictable ways across the product.
More reuse
New features could build on existing motion patterns instead of starting from scratch.
Clearer handoff
Engineering had defined behaviour and implementation guidance rather than relying on interpretation.
Adding moments of delight
Not every interaction needed to be purely functional. I also used Rive to add small moments of personality and feedback throughout the product, helping Ready X feel more distinctive without distracting from the task at hand.
Clickable icons
Experimentation in Rive for animation style.
Differentiating Ready X without slowing delivery
Visual differentiation through colour
Ready X needed to feel distinct from the main Ready app while still using the same underlying component system.
The challenge was to create a stronger product identity without slowing development or rebuilding the interface from scratch.
What I did
I created a new colour system that could shift the personality of Ready X across both design and development. Rather than redesigning individual screens, I used colour as a system-level tool for separation, hierarchy and state, while keeping the existing component structure intact.
The palette also had to work hard functionally, supporting accessibility, interaction states, data-heavy screens and high-trust financial actions.
Why it mattered
This gave Ready X a distinct visual identity without fragmenting the underlying system.
By solving the problem at the system level, we improved hierarchy across complex screens, kept mobile and web aligned, and gave design and engineering a stronger foundation for future features.
Check out this presentation to see the new colour system in action!
Wallet architecture.
Designing for a multi-account wallet
Ready X needed to support several account types, each with different levels of access, visibility and risk. My job was to make that complexity feel simple, so users could understand what they were using, add or import accounts safely, and manage them with confidence.
Check out the full flow here
System complexity
Rather than exposing the underlying account logic to users, I grouped the experience around a small set of consistent rules for setup, permissions and control. This created a clearer model for users and a more scalable structure for the product as new account types were added.
01
Account model
What kind of account is this?
Different account types came with different permissions and capabilities. I created a shared model that surfaced only what users needed to know: what kind of account they were using, what it could do, and any limitations that affected how it could be used.
Account list
See all accounts, balances, and types in one place. Gradient appears to allow the user to easily see which account is currently current.
Account type selection
Choose the right account type before setup begins.
Account state & capability
Clear visibility into account capabilities and settings at a glance.
Import method
Support for address entry and QR import.
Validation states
Catch errors early and explain what went wrong.
Setup feedback
Clear feedback and progress throughout the setup.
02
Setup and import
How do I add or import it safely?
Adding an account is a high-trust moment. I designed the flow to make it clear what users were importing, what level of access it would have, and whether the account could take actions or was view-only.
03
Settings and risk controls
What can I change, hide, connect, or remove?
Once an account existed, the challenge shifted from setup to control. I designed the settings around clear permissions and consequences, so users could understand what they were changing and where actions had higher risk or were irreversible.
Settings overview
Grouped by intent and risk for better clarity.
Visibility and control
Control how and where your account appears.
Sensitive actions
High-risk actions are separated and clearly communicated.
Related projects
Taken from the archives, screenshots and animation completed on similar based projects.
Ready: Making crypto feel clearer, safer, and easier to use