Context About BitGo
BitGo serves institutions, helping them custody their digital assets securely and providing services where they can then deploy their capital. These institutions custody billions of dollars with BitGo and are highly security conscious.
They set up policies for their enterprises and if a transfer or action breaches the policy, an approval from administrator(s) is required. For example, a policy can be: if a withdrawal exceeds $1M, require approval from 2 administrators. BitGo Verify App is the hub to view pending requests (as an initiator) and approve/reject all the pending approvals (as an approver).
ROLE
Lead Designer, 0→1
TIMELINE
June–Aug 2025
BEST TEAM
1 Designer (Me), 4 Engineers, 1 PM
PRACTICES
Product Design, Strategy, User Research
BitGo Verify helps institutions manage digital asset movement & activities across the entire enterprise. So when an approval delays, money transfer does too.
The Problem
After BitGo Verify launched, it quickly became a core part of users' daily workflows, with many managing a growing number of pending approval requests. While the initial experience supported smaller volumes effectively, scaling usage introduced new challenges. Users needed a clearer way to understand what required their attention, prioritize decisions, and take action efficiently.
We also recognized that Verify was more than an additional approval interface, it was a critical component in accelerating transaction execution and driving business growth. To maximize its impact, the experience needed to help approvers make faster, more informed decisions while reducing friction throughout the approval journey.
Painpoints Identified
It started with a request from BitGo’s product operations team, a power user of the product, to add filtering and sorting to the approvals page. As we dug deeper, the Product Manager and I realized that navigation improvements alone wouldn’t address the larger challenge. Through user conversations and workflow analysis, we found that the real problem wasn’t finding requests. It was efficiently reviewing, prioritizing, and acting on multiple approvals as volume increased.
KEY FINDING 1
Upon interviewing we realized users often had multiple approvals with similar context, policies, and decision criteria.
KEY FINDING 2
Approvers were mentally batching requests on their own — sorting by wallet or urgency in their head before acting — with no tooling that reflected how they already worked.
Design Process
After synthesizing the research findings, I aligned the team on the problems we were solving and the opportunities ahead. Throughout the process, I collaborated with engineering and security teams to prioritize workflows, validate technical constraints, and ensure a secure experience. I also leveraged internal users to test concepts early, gather feedback, and iterate quickly.
Discarded Approach
Approach was more focused on verification methods and not on the pending requests.
During user testing, we discovered that once requests entered the queue, users rarely approved them immediately. Instead, they preferred to review multiple requests together based on their workload and priorities.
Result: This approach focused on improving verification methods, but it didn’t address the larger challenge of helping users understand which approvals were ready to move forward and how many they could efficiently approve at once.
Improved Approach
Bulk approvals focused on simplifying request management while maintaining security
Working closely with the security team, we validated that this approach could maintain strong security standards by keeping biometric verification as a mandatory step before approving requests. Users could efficiently review multiple requests while still completing secure verification at the point of action.
Result:This approach reduced repetitive effort, improved visibility into pending requests, and enabled users to confidently process approvals at scale without compromising security.
Advanced Animations
What if users could authenticate multiple wallets with a single password?
Many users manage multiple wallets with the same credentials. Instead of requiring them to enter a password for each wallet, we explored how the system could detect shared credentials and authenticate multiple wallets at once, while clearly communicating the progress and outcome to the user.
Result: Although the authentication happens instantly in the backend, I designed a guided experience with three animation states to make the process transparent: verifying credentials, confirming approvals, and communicating the completed wallets. This required multiple iterations to balance speed, clarity, and user confidence.
Product Exploration
What if users had a distress code to protect funds in critical situations?
This concept was not part of the current roadmap, but I explored and pitched it to the leadership team as a proactive security measure. The idea was to provide users with a discreet distress code that, when triggered in a high-risk situation, could automatically move funds to a predefined backup wallet.
Result: This exploration helped identify a potential future security capability by combining user safety, product strategy, and technical feasibility. Rather than designing only for the ideal workflow, I explored edge cases where users may need protection during unexpected or compromised situations.
Information Clarity
Each grouped request surfaces the policy it triggered up front, so approvers aren't guessing why it's in their queue.
Empty States
A cleared queue confirms explicitly that nothing's waiting, instead of leaving approvers to wonder if the screen just hasn't loaded.
Live Notifications
Notifications update in real time as a batch processes, so approvers can step away mid-review without losing track of what's left.
