Helping innovators move fast without breaking the things that matter most requires knowing which things matter most before moving.
A product at the edge
of two financial worlds
The client built a tokenized asset platform that let users invest in real-world assets through blockchain-based instruments, under a compliant and regulated framework. The pitch was genuine: DeFi-level accessibility with the structural rigor of traditional finance. What nobody had tested was whether users could tell which world they were in at any given moment.
Tokenized asset platforms occupy a specific and strange middle space. They carry the design conventions of traditional finance: clean account dashboards, familiar transaction flows, recognizable compliance disclosures. But the mechanics are blockchain-native, which means settlement is asynchronous, states change in layers the interface does not expose, and the timeline for a "completed" transaction has no equivalent in anything a typical user has encountered before.
In a conventional banking app, that ambiguity is minor. Users have cognitive frameworks for navigating it. In a platform where real money moves into positions that do not carry the familiar backstop of traditional financial infrastructure, the same ambiguity becomes a different category of problem entirely.
Audit the onboarding experience and full transaction flow. Identify the friction points threatening user retention and document failure modes before launch.
The engagement was scoped as a research and advisory project, with deliverables including a friction audit and an executive roadmap prioritizing findings by combined UX and regulatory risk.
Mapping the experience against
the mental model users actually had
The research started with a deliberate reframe. This was not primarily a usability problem. The interface was technically well-built: buttons did what they were supposed to do, navigation was clear, nothing was visually broken. A usability-first audit would have generated a list of minor UI improvements and left the underlying problem completely intact.
The audit focused instead on the gap between what the interface communicated and what users interpreted. That distinction shaped both the methods and the framing of findings. Fixing the wrong thing, in this context, would have made the problem invisible rather than solved.
Pending didn't mean pending
to the people using it
Seventeen distinct friction points emerged from the audit. The distribution was striking. Eleven of the seventeen were concentrated in a single area: transaction state legibility. The interface was technically accurate at every step. The problem was that accuracy and comprehensibility are not the same thing.
The central finding: users consistently interpreted pending transaction states as evidence of asset loss. A transaction in settlement, processing normally and on schedule, looked to users like a failed transaction. Or one that had simply disappeared. The interface was showing exactly what was happening. Users understood something different.
The interface was not broken. The mental model users arrived with was built for a different product category entirely, and nothing in the flow told them otherwise.
This failure mode gets worse as the stakes increase. A user who cannot tell if their grocery order went through hits refresh. A user who cannot tell if their asset position is processing or lost does something more costly: they abandon the transaction, contact support, or do not come back. The cost of the same information gap scales with what the user believes is at risk.
The same finding costs more
in some contexts than others
In most products, a confusing loading state is a minor annoyance. Users have mental frameworks for navigating uncertainty during a transaction. In a tokenized asset platform, the same ambiguity activates a different category of concern entirely.
Traditional financial infrastructure has spent decades building cognitive safety nets that users have absorbed without realizing it. FDIC coverage, monthly statements, customer service lines, the ability to walk into a branch and speak to someone. None of these protect a user against a confusing interface in any direct sense. What they provide is a backdrop of institutional accountability that quietly mutes anxiety during moments of uncertainty. Users do not think "I am protected." They feel protected, without thinking about it at all.
That infrastructure does not exist in DeFi-native products, and users know it, even if they cannot articulate it. A tokenized asset platform may carry legitimate regulatory standing, but users bring their associations from the broader DeFi landscape: irreversible transactions, no customer recourse, self-custody risk, the familiar stories about assets lost to a mistyped address or a wallet that cannot be recovered. When a pending state appears and the interface offers no context for how long, why, or what it means, the worst interpretation fills the space immediately.
The finding was not novel as a UX observation. Mental model mismatches between product mechanics and user expectations are common. What made this finding consequential was the context it landed in.
This was a platform where that specific gap, users misreading a normal pending state as asset loss, could translate directly into permanent user attrition, support volume the team was not staffed for, and reputational risk at exactly the moment a new product most needs positive word of mouth.
What the audit
surfaced
The 17 friction points broke across three categories. The concentration in transaction state legibility was not a random distribution. It reflected a product that had invested heavily in building a technically sound system and had not yet invested in making that system legible to users who arrived without blockchain-native experience.
Two problems that
turned out to be one
The executive deliverable was a prioritized roadmap covering both product changes and regulatory sequencing. The framing was deliberate. It was a departure from how the leadership team had been thinking about the work.
Most product teams in this space treat UX design and regulatory compliance as separate workstreams. Different owners, different timelines, different definitions of what "done" looks like. The audit produced evidence that they could not be separated here. The specific communication gaps making pending states feel like asset loss were the same gaps that would create regulatory exposure if users misunderstood the nature of their positions. Fixing the interface without fixing the disclosure language would paper over the problem. Fixing the disclosures without improving the interface would bury the solution in legal text nobody reads.
The roadmap gave the leadership team a sequenced plan: 17 friction points ordered by combined UX and regulatory risk, with clear ownership and decision points across both tracks. The single most important output of the engagement was the reframe itself. This was not a UX problem with a compliance annex. It was a user trust problem that happened to have both UX and regulatory dimensions, and it needed to be solved as one thing.
Full friction audit documenting 17 friction points with severity ratings and primary ownership (product vs. compliance vs. content).
Executive roadmap sequencing the 17 findings by combined UX and regulatory risk, with decision points and dependencies surfaced explicitly across both tracks.
The methodology choices
worth revisiting
The onboarding finding arrived later in the process than it should have. I prioritized the transaction flow because that is where the retention signals pointed, and it was the right call for urgency. But the onboarding sequencing failures had downstream effects on how users interpreted everything that came after. Users who arrived at a transaction without the right mental model were more likely to read a pending state as failure than users who had been properly oriented. Running both analyses in parallel and sharing findings between them earlier would have surfaced that connection sooner.
Two points in the friction map does not reflect how important the regulatory communication finding actually was to the overall problem. The boilerplate disclosure issue was flagged clearly in the roadmap, but a more thorough review, including comprehension testing of the disclosure language specifically, would have strengthened the recommendation considerably. That was a resource constraint more than a judgment call, but it is worth naming. The finding deserved more evidentiary support than it got.
Research in high-stakes financial contexts is different not because the methods change but because the cost of a wrong interpretation is higher and faster. The core challenge here was a familiar one: users arrive with mental models built for a different product, and the interface has to bridge that gap or they leave. Every research engagement I have worked on involves some version of that problem.
What made this one distinct was that "they leave" meant something more consequential than a bounced session. On a platform where user trust is the actual moat (not the technology, not the compliance infrastructure, not the asset selection), a UX finding is also a business continuity finding. The two are the same thing, even if the teams responsible for each one are not used to thinking that way.
That reframe was the real deliverable. The roadmap documented it. But getting a leadership team to see a user trust problem as a unified product and regulatory challenge, rather than two separate workstreams that occasionally overlap, is the harder and more durable outcome.