OISY Wallet

oisy.com

Designing a browser-based, multi-chain wallet

OISY runs entirely on-chain and is served in the browser. People sign in with Internet Identity and passkeys rather than installing an extension or managing a seed phrase. The wallet supports assets across Bitcoin, Ethereum, Solana, ICP, and many other EVM networks.

That setup removes some familiar crypto friction and introduces less familiar behaviour. A conversion can turn ETH into ckETH. A balance can update before its transaction appears in the history. A dApp approval can arrive as a payload few people can read.

My role covered UX, UI, brand application, the design system, and delivery. In a product this technical, design often comes down to deciding which details to show and translating them into what matters to the person making the decision.

Making technical behaviour understandable

Crypto wallets ask people to make irreversible decisions using unfamiliar language: chains, gas, wrapped assets, approvals, and pending transactions. Experienced users may read that detail as control; newer users often read it as risk.

OISY could keep much of the infrastructure out of view, but hiding it everywhere would create a different problem. When a conversion, delay, or approval goes unexplained, the interface feels unsafe even if the protocol is working as intended.

The goal was to simplify routine actions without removing the details people need to verify them.

My role

I worked between leadership, product, and engineering when product decisions depended on protocol or engineering constraints. I reframed feature requests around the user problem, raised feasibility risks early, and checked the implementation through design QA.

Research and product planning

We ran user interviews and usability tests for existing flows and new features. I used those findings, competitive analysis, and detailed customer journey maps in product planning and in the design of individual features.

Reframing the product around user actions

The early product had solid infrastructure and a working prototype, but many interface decisions were still unresolved. Some flows relied on older modal patterns. Transaction and conversion states gave inconsistent feedback. Important changes could happen without enough explanation in the interface.

I used three questions to work through each flow:

1. What can the technology do?
2. What does the user need to understand before acting?
3. What can stay out of view until it matters?

The point was to stop reviewing one screen at a time and define what OISY was for: one place to receive, send, hold, spend, swap, and earn across networks without asking people to reason about the network before every action.

Contacts could work like an address book rather than a key-management tool. Balances could lead with value in the user’s preferred currency. Confirmations could start in plain language, with fees, routes, providers, and transaction records available for verification.

Rules I used when making trade-offs

Building the system around the screens

Requests and user feedback came from several places. The team needed a way to connect them to design decisions and implementation checks.

I led the design-system work beyond individual screens. In Figma, I structured the library around variables, colour tokens, reusable components, shared styles, responsive patterns, and interaction states.

The work also included living design documentation, a Linear board for intake and planning, and shared templates for product and marketing work. Design reviews covered complete 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 went into the same intake and planning process. This kept design from reacting to each request in isolation and gave the teams one place to track the reasoning behind the work.

The shipped product

OISY v1 launched publicly on February 27, 2025. It included passkey authentication, multi-chain asset management, send and receive flows, conversions, swaps, dApp connection, and a more consistent visual system.

Later releases added mobile navigation, more networks, contacts, preferred currency, localisation, NFT support, OISY PAY, AI-assisted actions, and broader swap and Earn surfaces. This was the useful test of the design system: whether it could support new features and networks rather than exist only as documentation in Figma.

The team also had shared principles, reusable components, explicit states, structured intake, closer implementation QA, and feedback loops connected to the backlog.

What I learned

A technically sound wallet can still lose someone’s trust. If people cannot tell what happened to their assets or what they are approving, the interface has failed them.

Much of my work involved moving between protocol capability, engineering constraints, business goals, and the few pieces of information someone needed to take the next step.

If I were setting up this work again, I would define three measures from the start: time to first deposit, success and error rates across money flows, and drop-off inside conversion and approval steps. Those numbers would have made later trade-offs easier to judge.