Ðapp User Experience Audit

Alejandro Machado
Jul 1, 2018 · 14 min read

I originally wrote this as a design bounty for Status in June 2018.

Here’s a review of five “decentralized applications” running on Status Beta on the Ethereum mainnet. We identified guidelines for good experiences that most (all?) Ethereum Ðapps should follow in the summer of 2018, and made some recommendations for further improving the usability of the ecosystem. These are being collected and expanded in designforcrypto.com.

Let us start with these realizations:

From Alex Van De Sande’s Universal Logins for Ethereum


[WAG] Be wallet-agnostic

We scored Ðapps from 1 to 10, judging their compatibility with Status, MetaMask, Toshi, and Trust.

[SIG] Use message signing for access

We scored Ðapps from 1 to 10, judging how easy it is to create an account and register by signing a message.

[PRI] Prioritize privacy

We scored Ðapps from 1 to 10, judging how they managed their particular need for privacy.

  • Scores 1–4: the Ðapp fails to mention risks and doesn’t check for prior address activity.
  • Scores 5–7: the Ðapp mentions risks but doesn’t check for prior address activity.
  • Scores 8–10: either the Ðapp doesn’t store any personal information or it doesn’t allow signing up with an address that has prior activity.

[BAS] Follow basic usability guidelines

We scored Ðapps from 1 to 10, using the 10 Usability Heuristics for User Interface Design by Jakob Nielsen as reference.

[MOB] Design for mobile

We scored Ðapps from 1 to 10, judging how easy they are to use on a smartphone, giving higher scores to products that adhere to a mobile-first philosophy.

[EDU] Include short and context-specific educational content

We scored Ðapps from 1 to 10, judging how much they help newcomers without overwhelming them.

[PFT] Prime the user for transactions

We scored Ðapps from 1 to 10, judging how well the Ðapp explains transactions just before they’re initiated.

[CFC] Communicate using a familiar currency

We scored Ðapps from 1 to 10, judging how easy it is to understand transaction amounts.

[MAP] Manage the user’s attention to pending transactions

We scored Ðapps from 1 to 10, judging how thoughtful their post-transaction flow is.

  • Scores 1–4: the Ðapp blocks the UI after a transaction is sent or simply links to Etherscan.
  • Scores 5–8: the Ðapp directs the user to a live list of transactions and their statuses.
  • Scores 9–10: the Ðapp uses status bars and asynchronous systems (e.g. email) to respect the user’s time.

[CES] Centralize strategically

We scored Ðapps from 1 to 10, judging how much sense they make in terms of centralized versus decentralized components.


Onboarding flow and interaction with providers

We’re at a very early stage where standards haven’t been set. Peepeth chose to optimize for today’s user experience and provide quick links that work with two widely-used wallets: Metamask for desktop and Trust for mobile. This isn’t ideal, but it helps most users get started.

Peepeth remains compatible with other wallets, like Toshi and Status, but the onboarding experience isn’t so smooth. If a user wants to sign up with Status, she must open this email on her mobile phone, copy the invite link, switch to the Status app, select New > Open Ðapp, and paste the URL.

In the future, there should be a standard way to open Ðapp links in the user’s preferred application. web3 apps shouldn’t need to use the Metamask, Trust, or Status logos any more than Web 2.0 applications need to use the Chrome or Firefox logos.

How might we design a friendlier invitation flow that works cross-platform? One possibility is to make invitations into tokenized assets that are sent directly to the user’s chosen wallets.

Signing in

Registration, because it reserves a username, requires sending a blockchain transaction. This introduces a lot of friction, but is a valid design decision in the usability-security tradeoff.

Putting privacy first

Instead of issuing generic warnings, Ðapp developers should show what information can be easily inferred from the public blockchain. Something like:

In the future, wallets could automatically choose a fresh Ethereum address to use for every Ðapp, helping protect privacy without additional Ðapp developer overhead.


Ensuring a good mobile experience

Baking education into the product

Preparing the user for transactions

On choosing transaction speeds and estimating costs: when should it be done by the Ðapp, and when by the wallet? This is an area of further research.

Even better: Peepeth estimates the cost of the operation in dollars, because nobody knows how much 0.000055 ETH is:

  • most people have a hard time mentally processing that many zeroes
  • ETH is extremely volatile

A further improvement would be to use the user’s native currency instead of the dollar, but should this be responsibility of the Ðapp or the wallet? Toshi makes this a priority.

Keeping track of transaction statuses


With its many educational messages, Peepeth excels at making the user aware of the tradeoff she’s making by trusting a single party with data that has not been committed to the blockchain.



Creating a CryptoKitties account is easy. The user doesn’t need to memorize a new password, and fields like email address can be made optional. Accessing one’s account only requires signing a message through the wallet.

How do users log out? This is an unsolved pattern: not all wallets allow users to switch to a different address. Besides, Ðapps currently use a combination of cookies and address detection to determine login status, which can be confusing.

While its privacy policy is sensible, CryptoKitties fails to alert the user that his past and future blockchain activity could be linked to his kitty trades. This is less serious for CryptoKitties than it is for Peepeth, but we feel that every Ðapp should make an effort to safeguard the user’s privacy.


As for educational content, it’s less verbose and more timely than Peepeth, with some great explainers about the service:


We believe the wallet should also display prices and estimates in the user’s native currency (or the US dollar for simplicity). Status doesn’t currently do this.

After the user completes a transaction, she’s directed to an Activity page with a list of recent transactions. This behavior isn’t immediately useful: transaction statuses aren’t visible on this page and activity disappears after a few weeks. A status bar similar to Peepeth’s or a notifications system would be improvements.




On the plus side, OpenSea works well on all wallets and uses message signing for access. On the not-so-good side, OpenSea handles privacy like CryptoKitties: it doesn’t even mention the potential risks.


OpenSea provides some helpful educational content, but it’s not always short or contextual. For example:


OpenSea sends the user an email when his transaction is processed by the blockchain:

This is a welcome feature when confirmation times are around 20 minutes — it’s best to let the user keep browsing and send him a confirmation asynchronously.

Other kinds of transactions aren’t handled so gracefully, though: the UI is blocked when wrapping ETH:




Should wallets build a messaging service between Ðapps and address owners? This could allow for better error handling while preserving the user’s privacy: Ðapps wouldn’t need to collect email addresses or other data.

Collecting no user data also means that Airswap has much less of a burden to alert the user of privacy concerns: by transacting, he’s adding some records to his blockchain history, but unlike with Peepeth, there’s no information being recorded that could expose his identity.


We’d favor an interface that showed the exchange rate between ether and a chosen token. Currently, the design assumes that the user knows how much of a given token he’ll buy, not how much ether (or dollars) he’s willing to spend. The other interface blunders are minor: higher contrast between the active and inactive elements of the Buy/Sell toggle is needed and the Terms of Service link doesn’t work on mobile.

Airswap barely integrates any educational content at all — they’ve assumed that their users are familiar with basic trades on blockchains. Fair game for this Ðapp.


Like the other Ðapps we analyzed earlier, Airswap doesn’t offer a great way to manage pending transactions. Once the trade is done, there’s no more feedback. The user is expected to quit the Ðapp, go to the Wallet tab, manually add tokens, and busy-wait until the blockchain updates his balances.





It follows usability best practices and feels like a mobile-first product. Its few educational messages are concise and timely.


Like Airswap, Bancor surrenders responsibility for the user’s engagement after the order is placed, instructing the user to check Etherscan. Like we’ve said earlier, it would be helpful to notify the user.


Offering this option allows users with web2 browsers to start interacting with the crypto economy, which is great. However, Bancor’s insistence of using the hosted wallet at every occasion goes against the ecosystem’s goal of empowering people to use decentralized systems.

Score comparisons


  1. Currently, the burden of estimating fees and letting users pick a confirmation speed is on Ðapp developers. This is inefficient for developers (reinventing the wheel) and confusing for users (variety of interfaces for the same task). Let’s research if wallets could take over this responsibility.
  2. Ðapps should follow standards for signing messages. If users can be certain that a transaction is being requested from a URL they trust, there’ll be less of a need to prime them before every transaction — explanations could be embedded in the wallet’s request.
  3. Ðapps should be able to communicate with users that opt-in by using their Ethereum address. This would enable natively notifying the user when his transactions go through. We should converge on an address-to-address messaging standard, but communication should operate off-chain.
  4. Making web3 access opt-in will be key to avoid fingerprinting. We should propose a standard that web3 providers follow when requesting the user’s permission to expose a wallet address.
  5. Wallets should use USD when communicating with the user, or even better, request the user’s native currency. Toshi does a fantastic job here.
  6. There should be a standard way to open Ðapp links in the user’s preferred application. Let’s research how this could be done.
  7. Let’s create a standard on how logging out works: should it require signing a message? should Ðapps flush cookies upon logout?

Thanks for making it through!

If you read one more long article on web3 design, make sure it’s Beltrán’s web3 design principles. I owe a lot to it!

Design For Crypto

Best practices for user-facing dapps, developed and curated…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store