Biconomy — long-form UX case study
Upon joining,my first tasks were to add new features to the and to restructure old ones.
Changes happened live and there was no testing or documentation process in place.
Over the next 18 months, cycling through 5 PMs, 3 FE devs, 2 BE devs, 1 bear cycle, 1 bull cycle, the only constant source of truth was the Figma file.
So to make this dashboard simple to use and expandable for development, I proposed a UX Audit.
Paymaster Empty State
Flow 1 of 6
#1
The empty state does not clearly signal what the user should do first.#2
Explanatory content occupies the primary visual area before any setup action.#3
Main action is gated behind reading and understanding long descriptions.#4
Learning and execution are presented together, creating cognitive noise.
Between dashboard releases,
I worked with growth and marketing to create usable prototypes
They were small functional stories showing what our SDK could do
Used when we needed to show how the SDK would fit into a prospect's existing dApp
These demos went through a natural process of abstraction themselves, from the most tangible to the most invisible.
Each demo made the invisible infrastructure into something people could see, use, and judge for themselves.
How we aspired
to be known as
Everyone on the team had real good ideas about our culture, process, and products so I started keeping a list.
This would go on to become
Biconomy Improvement Proposals
Six months later, during an internal tech-debt cleanup, I proposed a way to build these ideas out.
So then, that simple checklist evolved into a small workflow on Notion.
Seven ideas surfacedThree shipped
Copy of the Notion
The workflow was built around BIP #24001, a fully documented reference proposal
1. Know Your Idea
Contributors were first given a framework to clarify their idea by helping them with essential details required to strengthen it.2. Present
The doc structure then shifted into a presentation order, so every proposal could be read and evaluated in a consistent way.3. Evaluate
The final section captured stakeholder impressions, concerns, and suggested next steps.
Taken together, the workflow gave people a clear starting point, a shared structure, and a single place for feedback.
By following it, they could move an idea from insight to a real project.
I had great support from the then PM (Nikola ♡) who introduced it to his devs. Then growth and marketing teams gave it a shot.
After a year of remote work,
I met the team at the annual offsite and realized each person carried a different idea of what Biconomy was.
That turned into an internal joke. I called this
The Multiverse Theory
To test it, I ran one-on-one calls and asked simple questions* around directions and priorities.
Surprisingly, the answers varied greatly.
I turned that phenomenon into a poster which made the problem real while also carrying the humor with which this had started
Orange, the fruit, was part of our brand's secondary identity
Once I had resonance with the core team, I presented the findings to the founders.
They agreed with the diagnosis, unfortunately not the solutions.
Still, it aligned the rest of the team. We began looping each other in more intentionally.
This began as an experiment
My hypothesis was that if sci‑fi can inspire rockets, how about an interface?
This is where
Science Fiction Meets Interface Fiction
A standby mark, a stepper, and a receiver — each a grammar piece before connection.
Connecting Wallet
I read a few Asimov stories, hoping for a direction. I got ideas for the structure of the API and the way it will interface with the rest of the client dApp.
Post walking you through the full context
An experiment in API design: if sci‑fi can inspire rockets, how about an interface? A thread on Science Fiction meeting Interface Fiction — walking through the full context of this exploration.
opens in new tabTwitter was the primary channel for web3 discourse so I chose to pitch these ideas as threads rather than as a video or a deck.
By year two, almost everyone I'd started with had left.
To stay centered, I kept my own documentation: decision logs, PM notes, founder goals, working styles. It became the best way to keep the threads connected.
Outside the company, I tracked what was happening in web3, read the EIPs that mattered and translated the useful ones into features.
Also, attended a few events and befriended some blockchain devs. The conversations with them informed some of the decisions on navigation and flow.