A Framework for Evaluating DeFi UX

Table of Contents

Intro

I’ve used thousands of DeFi applications across tens of networks over the years. I’ve deployed capital to hundreds and got rekt incomprehensibly many times through ludicrous ways.

In this post I introduce the v0.1 of my framework for evaluating DeFi UX. This framework incorporates my own experiences and failures as a user as well as some of the insights I’ve gathered from working in the industry for over half a decade. To be precise, this is not just about the UX of using the product, it is also about how you learn to use the product, and how you can make users feel safer when using your services. It’s also about giving control back to the users and truly embracing the De part of Fi.

This framework is not useful for thinking about whether your product or new primitive has any chance of PMF. Best way to figure that out is to test in prod. Best ideas come from personal struggles. Repeatedly hearing someone is suffering with a certain thing is a strong signal. Having paying users on your product is much better than non-paying engagement farmers – or worse – your friends’ feedback. If your product idea sucks, there’s no need to spend hours honing in the user journeys and button placements.

Assuming you have a product that brings some utility to someone, you shouldn’t only review your product against this framework. You should use all possible data in your disposal to ensure you are delivering the best possible user experience. Simple metrics like bounce rates, exit pages, common 404 paths, and page load times can tell you a lot. Allow users to give feedback with tools like Canny and collect cursor movement data & behavioural analytics with Hotjar.

When thinking about product development & design, it is all about the tradeoffs we can make with current resources. If you are at the early stages of your journey, I believe this framework will be useful. I hope it can add value and remind you of the fundamentals also down the line. But don’t use this framework alone, use good product management practices to get the insights you and your organisation needs.

And remember, most of the time your product is just not meant for success. Reiterate. Pivot. Rebuild.

I hope you can make this framework useful as you think about how to make your DeFi product a bit better. Just remember to use it in the context of your target user persona. If you’d like me to personally audit your product and give you holistic feedback, do get in touch (or order an audit right now through this link). Now, the framework:

DeFi UX Evaluation Framework v0.1

You can download this framework in Google Sheets format here. This is a v0.1 as it still requires some validation through repeated use and it is not yet fully MECE.

A. User Experience

A1. Interfaces & Usability

Topics to evaluate:

• Clarity and conciseness of the interfaces.
• Legibility factors like font size and contrast.
• Use of visual elements and cues.
• Consistency and integration of interface components.
• Error state communication and handling.
• Ease of use

Helpful questions:

• Does the product work?
• Are multiple click user journeys collapsed into as few clicks as possible?
• Are the interfaces clear and concise?
• Are the interfaces easily legible (font, contrast)?
• Are the interfaces continuous?
• Does the product utilise visual elements and cues to direct the user?
• Do the components used in the application work together?
• Does the user always feel in control?
• Does reality match expectations?
• Are error states handled graciously?
• Does the user need to sign unnecessary transactions?
• Can you easily exit your positions?

A2. User Assistance & Documentation

Topics to evaluate:

• Availability and quality of user documentation.
• Ease of finding details about product mechanisms and security assumptions.
• Use of industry jargon vs. user-friendly language.
• Accessibility of customer support and quality of help available.

Helpful questions:

• Does the product use accepted industry lingo or, better, easy to approach explanations?
• How easily can I understand the mechanisms of this product?
• Does the app suggest adding chains, tokens, or other dependencies to the support applications (e.g. wallet) where necessary?
• Can I get help?

A3. Onboarding & Accessibility

Topics to evaluate:

• Ease of the onboarding process.
• Support for account abstraction and transaction minimisation.
• Multilingual support and its necessity.
• Accessibility across various devices, screen sizes, and browsers.

Helpful questions:

• How easy is the onboarding process?
• Are there unnecessary onboarding steps?
• Is there multilingual support? Is it needed?
• Is account set up easy when account abstraction is used?
• Do I need to fund AA wallets for gas?
• Does it work on most common user device combinations?

A4. Error Management & Feedback

Topics to evaluate:

• Logging of errors and user notifications.
• Handling of product availability issues.
• Subscription options for security and uptime notifications.

Helpful questions:

• Are errors sufficiently logged?
• Is the user sufficiently informed of error states?
• When the product is not available, are the users sufficiently informed?
• Can I subscribe for alerts?
• Can the users subscribe to security and uptime notifications?
• Can I inspect service status in a third service?

B. Product Quality

B1. Performance & Compatibility

Topics to evaluate:

• App loading speeds.
• Support for common wallets and integration of chain dependencies.
• Compatibility with different operating systems and browsers.
• Is the product available?

Helpful questions:

• Does the product support most common wallets, where applicable?
• Is the product widely accessible across geographies, screen sizes, input devices, browsers, and operating systems?
• Does the app load quickly?
• Does the product load or is there a lot of downtime?

B2. Security & Compliance

Topics to evaluate:

• History and outcomes of security audits.
• Communication of security measures and audit results.
• Ease of contacting security researchers.
• Transparency of contract addresses and authoritative information.
• Compliance with data privacy rules.
• Centralisation risks.

Helpful questions:

• How easily can I find details about the security assumptions of this product?
• Can the users utilise secondary interfaces?
• Do the users need to rely on a singular front-end? Can a technical user use open-source code to access the application?
• Is the product audited? If yes, how? Is this communicated correctly? Does the current version run that version or something else?
• Can security researchers easily get in touch with the developers?
• Is important information, such as contract addresses, provided in an authoritative source? Are there discrepancies?
• Does the product transmit my data before I allow it?
• Is my data shared to third-party vendors?
• Is there an immutable version of the front-end (e.g. IPFS)?

B3. Transparency & Documentation

Topics to evaluate:

• Transparency regarding risks, fees, and expected returns.
• Availability of tools for position management and analytics.
• Clarity and accuracy of financial data representation like PnL.
• Understandability and documentation of transactions on the blockchain.

Helpful questions:

• Are implicit assumptions sufficiently communicated, given the target audience?
• Is the user documentation comprehensive and helpful?
• Are transactions and function calls clearly labelled on the blockchain for future use? Are these documented somewhere?
• Is the product upfront and transparent about risks, fees, and return profiles?
• Are PnL and other financial figures correctly booked and represented?
• Is data verifiable?
• Do functions use common interaction patterns?
• Are there tools for position management?
• Are there analytics tools?

B4. Integrations & Dependencies

Topics to evaluate:

• Use of third-party dependencies and data sharing.
• Support for multichain interaction and chain switching capabilities.
• Access to data and metrics without needing wallet connection.

Helpful questions:

• Are priority fees and similar set correctly where applicable?
• Can I access data and metrics without connecting a wallet?
• Are third-party dependencies minimised?