WisdomTree app is a blockchain-enabled financial app designed to let users save, spend, and invest in a variety of digital assets and tokenized conventional assets including cryptocurrencies, gold, stocks, and ETFs.

The opportunity

This project started with an opportunity, not a problem statement. Our customer, WisdomTree ETF provider, wanted to enter the digital asset space by building a blockchain-enabled wallet where users could buy stocks, gold, Bitcoin, and ETFs - all tokenized - in one app. The goal was to address gaps in traditional finance like restricted access to wealth-building assets, slow settlement times, and costly transactions, while opening a new direct-to-consumer channel.

I joined the project from the first discovery workshops with the WisdomTree team and led design through conceptualization, UI systems development, and MVP launch across 21 US states. The challenge was figuring out how to introduce tokenized assets - a completely new concept - to everyday investors without overwhelming them with blockchain complexity.

What people actually needed

After aligning on business goals through workshops, we had 3 weeks and a budget to validate our assumptions with US users. I led qualitative interviews and surveys focusing on two questions:

• How do people in the US think about financial freedom?
• Would they adopt blockchain-based tools to manage their wealth?

This shifted our entire approach. We stopped designing a "digital wallet" and started designing a personal finance app that happens to use blockchain. The research helped us understand that the technology should be invisible - users just wanted their money to work better.

Core concepts and app structure

A big part of the work went into defining core concepts and product requirements. We were still learning about Stellar blockchain capabilities, figuring out integrations, and understanding technical constraints. At this stage I helped the team define product requirements by researching existing market solutions. Back in 2021, there weren't many consumer apps with similar offerings, so I analyzed traditional investing apps to understand established patterns.

My goal was give users the traditional investing experience they're familiar with, with the benefits of tokenization. I wanted to abstract away blockchain complexity.

Moving from structure to actual UI surfaced specific challenges where "abstracting complexity" became concrete design problems. Below are the key design areas I explored - each direction went through iterations and was refined into stronger, more intuitive solutions.

The "zero-balance" dilemma

The blockchain required something called a "Trustline" - a permission that allows a wallet to hold a specific asset. To avoid friction, we automatically established Trustlines for core assets (Bitcoin, Gold, USD tokens) during onboarding so users could buy and receive them immediately.

Idea 1: "Show me what I can buy" model

Initially, we showed all assets in the wallet with $0 balances - mirroring traditional banking where you see accounts before you fund them.

Idea 2: "Show me what I own" model ✅

The solution: hide zero-balance assets and show only what users actually own. I went a step further and organized these holdings into categories (Cash & Stablecoins, Funds, Crypto, Precious Metals) rather than one flat list - matching how investors naturally think about risk and diversification. This kept the portfolio clean and scannable, while the technical Trustline setup happened invisibly.

Crafting the most intuitive Send flow

I revamped the Send feature to support multiple ways users might initiate a payment - whether they're at home browsing their contacts, standing in front of someone showing their QR code, or pasting an address from another app.
‍
The challenge: During testing, in-person users immediately asked "where's the scan QR code?" They didn't think to look inside the Send option. This revealed that one send screen had to accommodate different starting contexts - pasting addresses, scanning QR codes, selecting saved contacts and saving new contact if needed.

I explored four architectural patterns to solve this:

Idea 1: Contact list-first approach

Initially, I designed the flow around the mental model: "I’m sending to people I know." It prioritized saved contacts to reduce errors, with an option to add new ones. While it encouraged using verified contacts, it created friction for the "cafe scenario" where users need to scan a QR code immediately. The page also offered too many competing actions - search, contact selection, QR scanning, or manual entry - resulting in high cognitive load.

Idea 2: Two tabs (Account ID / My contacts)

Tabs to separate two distinct user intents: "I’m entering data" in Account IDs tab versus "I’m picking a person" in My contacts. This structure provided clarity and allowed the UI to evolve - potentially defaulting to "Account ID" for new users and switching to "My Contacts" as their list grew.

Idea 3: Single input field with embedded actions

One field for pasting an ID, with embedded icons for the contact list and QR scanner. This model aimed for a minimalist aesthetic - keeping the screen "quiet" so users wouldn't have to worry about being in the wrong tab. It mirrored familiar patterns like a browser search bar or Mac’s Spotlight, where one input handles everything.

Idea 4: Adaptive contact list with payment link ✅

After testing previous options, I learned users expected to see saved contacts prominently but also needed quick access to scan QR codes for the "cafe scenario." Adding new contacts wasn't a primary goal here, so I removed it to declutter the UI and focus on primary actions: choose contact or scan.

We also realized that to drive adoption and bypass the app-install barrier, we had to let users send to non-WT users. Adding "Payment link" solved this - recipients could claim funds through a shareable link.

Users expected single-asset transfers, not multi-currency conversions

Initial requirements let users send one asset while the recipient received a different one - send Gold, receive USDC. The backend could handle the conversion mid-transaction.

But would users actually want this? Or would they just get USDC first, then send? Two simple steps instead of one complex one. During testing, we learned users had a strong preference for simplicity.