Design challenge: the system knew what was happening; users only saw Pending
Copper provides institutional clients with digital asset custody, trading, and settlement services. The design was shaped by three constraints: real assets, multi-user permissions, and operations that move through several system stages.
While mapping the Staking, Approval, and ClearLoop flows, I found that the backend states were technically accurate but did not answer the questions users needed to make a decision: Who is handling this now? Do I need to act? Can these assets still be used? What happens next?
I therefore did not define the goal as reducing steps. Instead, I wanted to reduce the judgement required to understand the current state without hiding risk or responsibility.
My design framework: current state → responsibility for action → impact on assets → next step
A single confirmation could transfer, lock, or reallocate real assets.
Core Platform, iOS app, and building the Mobile Design System from scratch.
Help users make the right decision without explaining every backend mechanism.
Design decision 01: separate waiting for the system from waiting for the user
In the mobile flows, Pending collapsed two very different responsibilities into one label. Sometimes the system was processing and the user only needed to wait. At other times, the system was waiting for an authorised approver. I made “who owns the next step?” the first layer of the status design.
The same Pending label could not tell users whether to wait or act.
A status must communicate the current stage, who is responsible, and the consequence of acting.
Keep more information after critical actions instead of mistaking the shortest flow for the best one.
I made Sign a step in the lifecycle, not the endpoint
The original flow could easily stop at transaction completion: the user signs, the system shows Submitted, and the experience ends. But the Staking journey is not over. The assets still need to pass through a bonding period before they begin earning rewards.
Set up → Review → Sign → Transaction submitted
I redefined the endpoint of the flow and made the current stage answer three questions at once: Why am I waiting? How long will it take? What restrictions apply to my assets while I wait?
The final screen shows completed steps, the current two-week bonding period, and the fact that assets cannot be traded or unstaked. The screen carries more information, but every detail affects availability and reward timing.
How the same principle reshaped Approval
Approval represents the opposite state: the system has stopped because it is waiting for an authorised person. I changed the information order from status plus button to decision context plus action.
Before users approve, the interface prioritises the initiator, account, asset, amount, and outcome of confirming. This does not reduce clicks, but removes the need to move between screens simply to verify responsibility.
I was not optimising how quickly someone could Approve. I was improving the basis for that decision.
Design decision 02: organise balances by whether assets can be used
ClearLoop only needs one line of context: assets remain in Copper custody, while the institution can allocate the corresponding balance to an exchange for trading. This means where assets are held and whether they can be used are no longer the same question.
Total balance alone could not show which assets were immediately available.
Organise the home screen around user actions, not the backend account structure.
Add top-level categories so users understand asset use before opening details.
I first listed the decisions users needed to make when reviewing a balance: How much can I use now? How much has been allocated for trading? How much is being processed? How much is locked?
I kept Total balance as an overview, then separated the balance into Available, ClearLoop, Processing, and Staked. Each category describes the asset’s current purpose and usability, not a backend service step.
Available: can be transferred or used now.
ClearLoop: allocated to an exchange for trading.
Processing: the system is completing a transfer or settlement.
Staked: committed to Staking and temporarily unavailable.
Design decision 03: act without leaving the data
Product analytics showed that users repeatedly left the home dashboard to open a transaction, then returned to check balances and account details. In user research, they explained that they preferred to keep detailed data visible while taking action—a workflow familiar from Bloomberg.
I redesigned transactions as a side panel, allowing users to view balances, holdings, and recent activity while completing an action on the same screen.
A design system shaped by real product needs
When I joined Copper, the product was growing quickly but its design foundations had not kept pace. The Web Design System was incomplete, multiple versions existed in development, and Mobile had no shared component library. I helped rebuild the Web system and created the Mobile Design System from scratch.
I started with real product problems rather than an ideal component library in isolation. Staking, Approval, and ClearLoop repeatedly exposed the same questions around states, confirmations, permissions, and next steps.
The problem I inherited was not simply visual
Similar controls were implemented differently. Some components had accessibility issues, and design and engineering discussed one-off pages rather than reusable behaviours. The result was repeated design, repeated development, and gradual divergence.
How I structured the system
I used Atomic Design to create a clear dependency between foundational styles, reusable components, and complete business workflows. Typography, colour, spacing, semantic values, and icons became shared tokens across Web and iOS.
Identify duplication, divergence, and missing foundations.
Unify tokens, icons, and component states across Web and Mobile.
Turn proven solutions into reusable rules.
Bring usage guidance, contribution workflows, and front-end references together.
Beyond components, I defined rules for use and contribution
I documented when to use each pattern, how to configure its states, and how to contribute a new component. For Approval, documentation specified which details must appear before confirmation, how permissions should be handled, and how to explain what happens next.
The guidance linked to development libraries where useful, keeping design intent and implementation in the same conversation.
I turned it into a shared workflow
Reusable components discovered in product work were reviewed and moved into the library. Approved versions were published to a Design System website bringing together specifications, usage rules, and front-end documentation.
The system formed a loop: the product exposed a problem, the team validated a pattern, the system preserved the rule, and future product work tested it again.
Outcome and reflection: the shortest flow is not always the clearest
This project did not leave behind quantitative results appropriate to share publicly, so I do not present invented efficiency metrics. What I can confirm is a change in how design and engineering discussed the work: around shared components, patterns, and documentation.
In a complex financial product, removing one step can remove critical decision-making information. Design cannot count clicks alone. It must consider the risk users carry, whether actions are reversible, and the cost of getting something wrong.
Across Staking, Approval, ClearLoop, and the Design System, I first identified the decision users needed to make, then decided what the interface should hide, what it must retain, and which step deserved to be deliberately slower.
