OISY Wallet

oisy.com

From technical prototype to product system

OISY began with an unusual technical advantage. It is a fully on-chain wallet served in the browser, with Internet Identity and passkeys instead of an extension, mobile app, or seed phrase. It can manage assets across Bitcoin, Ethereum, Solana, ICP, and other networks.

That architecture removed some familiar crypto friction, but created new questions. What happened when ETH became ckETH? Why did a balance change before the transaction history caught up? What exactly was a dApp asking permission to do?

I led product design across UX, UI, brand application, design systems, and delivery. The work was not about hiding every technical detail. It was about deciding what people needed to see, when they needed to see it, and how the product could remain auditable without making routine actions feel like infrastructure work.

The problem was trust, not just complexity

Crypto wallets ask people to make high-stakes decisions with unfamiliar language: chains, gas, wrapped assets, approvals, pending transactions, and irreversible transfers. Experienced users may read that detail as control. Newer users often read it as risk.

OISY could abstract much of the underlying infrastructure, but abstraction alone was not enough. If the interface failed to explain a conversion, delay, or approval, the technology felt opaque. A technically secure flow could still feel unsafe.

The design challenge became precise: simplify the wallet without taking away the evidence people need to trust it.

My role

I owned the design work across four connected areas.

My job was to keep the product coherent while leadership, product, and engineering worked through technically difficult choices. That meant reframing requests as user problems, surfacing feasibility risks early, and staying close to implementation through design QA.

Resetting the product frame

The early product had strong infrastructure and a working prototype, but it needed a clearer design direction. Some flows inherited older modal patterns. Feedback was inconsistent in transaction and conversion states. Important changes could happen without enough context in the interface.

I separated the problem into three layers:

1. What the technology can do.
2. What the user needs to understand to act safely.
3. What the interface can abstract until it becomes relevant.

This moved the conversation away from polishing individual wallet screens. A more useful frame emerged: OISY should be one place to receive, send, hold, spend, swap, and earn across networks without asking the user to reason about the network before every action.

The frame changed what the team could design. Contacts could behave like an address book rather than a key-management tool. Balances could lead with value and local currency. Confirmations could start in plain language while keeping fees, routes, providers, and transaction records close by.

Four principles for making tradeoffs

What changed

Conversion became a journey, not a modal

ETH-to-ckETH conversion exposed the gap between protocol state and user understanding. A balance could change while the history lagged behind, and the interface did not always make the relationship between the two assets clear.

I treated conversion as a sequence with a visible beginning, progress, outcome, and recovery path. The interface needed to say what was moving, what it would become, how long the change might take, and where to verify it. The same state model had to cover initiated, pending, available, failed, and action-required outcomes.

Assets were organized around money

Users do not start with ledger architecture. They start with what they own, what it is worth, and what they can do with it. Similar token names, network variants, unknown assets, and dust made the wallet overview an information-architecture problem.

The main surface prioritized the asset, balance, fiat value, and available action. Network details stayed visible where they affected transfer accuracy, fees, or troubleshooting. The goal was not to pretend networks did not exist; it was to stop making network state the organizing principle for every screen.

Onboarding led to a useful action

Creating a wallet is not the same as onboarding someone to crypto. The first experience needed to get people to a meaningful action—receive, buy, swap, send, pay, or connect—without teaching the protocol first.

Passkeys and Internet Identity were explained as access and recovery mechanics. Deeper technical explanations appeared when they affected a decision. Responsive navigation used a desktop sidebar and mobile bottom tabs so the same product model held across screen sizes.

Approvals became readable trust moments

dApp connections, contract calls, and token approvals are difficult to judge when the interface exposes raw payloads. I treated these screens as security-sensitive product surfaces.

Where the underlying request allowed it, confirmations led with a human-readable summary and separated simple transfers from contract interactions. Amount, destination, account, fee, expiry, and existing allowance remained available for verification.

Building the system around the screens

OISY did not only need a component library. It needed a repeatable way to turn product questions and user feedback into shipped work.

I introduced living design documentation, structured design artifacts, a Linear board for intake and planning, reusable UI components, and shared templates for product and marketing work. Design reviews focused on flows and states rather than isolated screens. Handoffs included loading, failure, fallback, confirmation, and privacy constraints.

Feedback from support, Discord, email, research, and product analytics could then move into the same planning loop. This made the design function less reactive and gave product, engineering, marketing, and support a shared language for the wallet.

The shipped product

OISY v1 launched publicly on February 27, 2025. The product brought passkey authentication, multi-chain asset management, send and receive flows, conversions, swaps, dApp connection, and a more coherent visual system into one browser-based wallet.

Later releases expanded the same product model with mobile navigation, more networks, contacts, preferred currency, localization, NFT support, OISY PAY, AI-assisted actions, and broader swap and Earn surfaces. The release history matters here because it shows the design system being used under real product growth, not only documented in Figma.

The work also left the team with a clearer operating system: shared principles, reusable components, explicit states, structured intake, closer implementation QA, and feedback loops connected to the backlog.

What I learned

In a wallet, clarity is part of security. The protocol may be safe, but the product will not feel safe if people cannot tell what happened to their assets or what they are approving.

I also learned that infrastructure-heavy product design is translation work. The designer moves between protocol capability, engineering constraints, business goals, and the small amount of information a person needs to take the next step with confidence.

If I continued this work, I would establish three measures earlier: time to first deposit, success and error rates across money flows, and drop-off inside conversion and approval steps. They would make the next round of tradeoffs easier to defend—and easier to improve.