OISY Wallet

2024–now

I led product design for OISY, a browser-based wallet for managing digital assets, payments and swaps across networks.

oisy.comRight Arrow
OISY Wallet on desktop and phone, from the official sign-in page.
OISY Wallet on desktop and mobile. Product screens below use local sample data.
Role
Lead product designer
Scope
Product design, design system, brand and marketing strategy, design QA.
Team
Product, engineering, research, product and graphic design, support.

The design challenge

For OISY’s redesign and first public release, we wanted managing digital assets to feel familiar to people used to banking and payment apps. Understanding a balance or making a payment should not require a lesson in blockchain terminology.

I led product design, working with product and engineering to decide which technical details people needed before acting. We organised the wallet around assets and balances, with networks, fees and token versions explained where they affected a choice. This direction carried through the first release and later updates.

User interviews, usability tests and customer journey maps informed planning and the design of individual flows.

Starting with a familiar sign-in

People can sign in with a passkey through Internet Identity, or choose Google, Apple or Microsoft. Recovery information remains available when needed.

OISY’s browser-based architecture makes that entry possible on a phone or laptop, with no extension to install or wallet seed phrase to write down during setup. A private browser window works too if it supports the chosen sign-in method.

The OISY website on a silver phone, with Internet Identity, Google, Apple and Microsoft sign-in choices.
Illustrative studio portrait of a woman in a blue T-shirt using her phone.
The same wallet opens on a phone or laptop, with familiar ways to sign in.

A portfolio organised by asset

USDC on Ethereum, Base and Arbitrum can appear as separate entries in a token list. People have to recognise them as the same asset and add up the balances themselves.

When defining our product principles, we decided as a team to organise the portfolio by asset. USDC balances sit in one expandable group; BTC and ckBTC sit under BTC. The default view includes all networks, with network filters available when needed.

Expanding a group reveals each token and network. Those distinctions remain available for sending and swapping: grouping does not move funds or make token versions interchangeable.

A closer view of the OISY portfolio with BTC expanded into native BTC and ckBTC, preserving the group balance and surrounding assets.

0.24 BTC and 0.0445 ckBTC contribute to the combined BTC balance.

Swapping without a separate ETH balance

Grouping balances simplifies the overview, but a swap still depends on the network and how its fees are paid. Someone can hold enough USDC and still be blocked because the fee requires ETH.

For eligible routes, OISY’s Velora Delta integration lets people swap using the asset they already hold. In the example here, USDC moves from Ethereum to Base without an ETH top-up. Execution costs can be reflected in the quote.

Both networks appear beside the amounts, with the expected amount received, provider and fees available in the review. Gasless availability depends on the token and route, and some routes still need a separate gas payment.

250 USDC on Ethereum exchanged for 249.375 USDC on Base, with both networks and the slippage setting shown.
Expanded fee details for the same swap: Velora, Delta route, gasless network cost and swap fees.
Ethereum → Base, with the Velora Delta fee details alongside the quote. This eligible route needs no separate ETH top-up; execution costs can still be reflected in the quote.

Showing risk before a transfer or swap

Before an irreversible action, the recipient, cost and risks need to be explicit. Warnings sit in the same view as the final action, so the review explains what the person is agreeing to.

Address poisoning can plant a look-alike address in transaction history. The send review asks people to verify a first-time recipient; contacts let them reuse a checked address instead of copying from history. An optional filter also hides incoming transfers below $0.01 when a USD price is available.

For swaps, slippage and quote value are checked separately. The slippage warning appears while choosing a tolerance. A severe difference between the estimated values paid and received, or a missing token price, requires acknowledgement in the review. Slippage limits movement from a quote on applicable routes; the value comparison helps someone assess the quote itself.

Verify and save recipients

The Send review keeps the recipient address, network, fee and first-time recipient acknowledgement beside the Send action.
Verify a first-time recipient, then save the checked address as a contact for next time. This avoids copying from transaction history, where address poisoning can plant a look-alike. What is address poisoning?

Review swap risks

8% slippage selected

The complete swap form with the selected 8% maximum slippage, expanded tolerance control and warning about losses due to market volatility.

250 USDC → 225 USDC

The swap review shows 250 USDC paid and 225 USDC received, a minus 10% value difference, the acknowledgement of that loss and the disabled Swap now button.

Receive value unavailable

The swap review shows the destination token amount with its USD value unavailable, followed by a warning to verify the offer independently and the disabled Swap now button.
Each warning stays with its cause: a high slippage setting, a quote that loses 10% of the estimated value, or a receive amount that cannot be valued in USD. These are three separate states.
Tips by OISY

A thank-you,
sent as a link.

On holiday one summer, I wanted to tip someone who’d been really helpful. I had no cash. We both had phones.

I didn’t want them to learn about wallets and addresses just to accept a thank-you. That moment became Tips. I carried the idea through the sender and recipient flows, into implementation and launch.

A hand holding a phone with the Tips recipient screen: the 2 ICP tip appears before Internet Identity, Google, Apple and Microsoft sign-in choices.
See the tip before signing in.

Showing the tip before wallet setup

The recipient sees the amount first. I put wallet creation inside the claim: sign in with Internet Identity, Google, Apple or Microsoft, then receive the tip in a new wallet if needed.

The sender chooses a supported token, amount and expiry, then shares a link or QR code. The amount stays in their wallet until claimed. An unclaimed tip can be cancelled or expire.

Show the code in person, or send the link for later.

Designing complete flows and states

I led the design-system work, with several designers contributing to the Figma library. We developed shared components, responsive layouts and interaction states, supported by variables and colour tokens. Reviews followed a complete action through loading, confirmation, failure and recovery. Error states needed to explain what had happened, whether anything had been sent and what to do next.

I set up shared design documentation and a Linear intake for product requests, research and support feedback. I worked with engineering on feasibility and checked the implementation through design QA, including the states around the main action.

Explaining the product at launch

I also led OISY’s brand and marketing work, including positioning and marketing strategy around private, secure access to digital assets. The website and launch materials needed to explain what people could do with their assets before introducing the underlying technology.

Working with a graphic designer, I led the application of the brand across the wallet and launch materials. The work covered product visuals, templates and motion direction. OISY v1 launched publicly on 27 February 2025. The release artwork and social animations below show how that work continued across later releases.

From launch to ongoing product design

After launch, the scope grew to include more networks, contacts, Tips and new swap routes. I continued designing those flows and reviewing how they fitted into the existing wallet.

I also built an internal dashboard for the team. We review fully anonymised data on sign-ins, sends, swaps, feature usage and errors, as well as how holdings are spread across assets and networks.

I should have recorded baseline measures for individual flows earlier, including first deposits, completed transactions and approval drop-off. Those baselines would have made later changes easier to assess.