Context & ownership
One transaction. Many moving parts.
A cross-chain transaction brings together assets, networks, route availability and a sequence of transaction states. The interface needs to remain understandable while those pieces change.
As Senior Product Designer, my work focused on reusable interaction architecture. The Assembly Library exposes that architecture through templates, populated examples and explicit variants, rather than only a collection of finished swap screens.
Selection can be incomplete, routes can be unavailable, and a transaction can require several steps. Each condition needs an intentional presentation.
Role, Scope & Team
My contribution
Hands-on work on modular transaction UX, reusable interaction patterns and design-system architecture, including asset/network selection, route states and transaction components.
The design team
One of four designers, alongside a Product Designer, a Marketing Designer and the Head of Product Design.
Cross-functional scope
Worked with frontend and backend engineers on behavior, feasibility and implementation; with the Product Manager on priorities; and with the Founder, CTO, CMO, Marketing Manager and Business Development on product and business alignment.
Design decisions
Selection states
Design the incomplete transaction, too.
The source/destination module covers zero state, source selected and both ends selected. These are explicit variants of the same module.
The board also distinguishes vertical and horizontal arrangements, with templates that can include or omit a destination and an action. The pattern describes both what the user knows and how much space the host has.
Zero, partial and completed selection states belong to the same module.
Selection, amount entry and the best route compose into one transaction module.
Route availability
One route, many routes, or no route.
Quote variants give a single route a direct presentation and multiple routes an explicit comparison action. An unavailable route has its own empty state.
The same board pairs abstract templates with a populated USDC-to-ETH example. That makes the reusable structure easier to distinguish from the transaction data inside it.
One route, several routes and no route each have an explicit presentation.
System architecture
From components to complete transactions.
The Assembly Library is organized into components, modules, views, screens and overlays. In the wider exchange workspace, route comparison has its own panel while selection, amount entry and the exchange action retain their structure. The receive cards compare returns, provider, fees and estimated time.
A wider workspace gives route comparison its own panel while preserving the selection and amount controls.
The same token, network and amount structure supports a compact exchange layout.
Components
The smallest reusable controls and content elements provide a consistent vocabulary.
Modules
Source/destination and quote modules combine that vocabulary with explicit state and layout variants.
Views & screens
Larger compositions assemble selection, routing and progress into complete product contexts.
Design → engineering
Specify the behavior between the screens.
I worked with the product and marketing designers and the Head of Product Design to keep the reusable patterns consistent with the broader brand.
Named variants, state coverage and populated examples beside templates gave engineering concrete behavior to implement.
The Foundation Library and LI.FI Widget sit alongside the Assembly Library in the source files, connecting the transaction patterns to the broader product ecosystem.
Six left-aligned rows compare template anatomy with populated USDC and ETH variants, including balances and route details.
Outcome & reflection
A reusable model for an uncertain route.
The library brings partial selections, completed selections and route availability into reusable modules that compose into larger transaction views.
Reusability comes from knowing which decisions stay the same when the data and state change. The selection and quote variants make those decisions explicit.
