Ðapp User Experience Audit

Alejandro Machado
Design For Crypto
Published in
14 min readJul 1, 2018


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 expect Ðapps to work well on a variety of mobile and desktop wallets.

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

[SIG] Use message signing for access

The community is deciding on a signing standard to enable passwordless authentication by proving ownership of an Ethereum address. We expect Ðapps to allow registration and logins by using such a standard.

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

Putting user data on a public blockchain can be risky. We expect Ðapps to prevent users from linking their transaction history across multiple systems.

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

Every Ðapp is an app. We expect systems to follow battle-tested, timeless usability heuristics.

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

People spend almost twice as much time on mobile as they do on desktop, and many people only use mobile. We expect Ðapps to work flawlessly on phones.

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

The early majority lacks mental models for the decentralized web. We expect Ðapps to provide relevant and concise explanations, following the segmenting principle.

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

[PFT] Prime the user for transactions

Transactions introduce a lot of friction. We expect Ðapps to prepare the user for an upcoming transaction, and explain its purpose when it isn’t obvious. This is a similar pattern to priming users for permissions consent on mobile apps, and is especially important during the onboarding flow.

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

Nobody, not even a regular Ethereum user, has a reliable mental model for how much ether is worth. Ether is volatile and common amounts involve many decimal places. We expect Ðapps to speak the user’s language when it comes to 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

Blockchains take longer to update than the user is willing to busy-wait. We expect Ðapps to reflect on their users’ purpose for every transaction and make smart design decisions about how to deal with inevitable delays.

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

All Ðapps have some centralized components. We expect Ðapps to make deliberate design decisions to gain efficiency and reduce friction while maintaining key elements of trustlessness that are clearly communicated to the user.

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


Peepeth is a decentralized Twitter clone.

Onboarding flow and interaction with providers

Peepeth requires new users to be invited into the service. Invites are implemented through secret links, so it’s not possible for a new user to sign up for Peepeth directly on Status by tapping on New > Open Ðapp > Peepeth. The user must get an invite email that looks like this:

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

Once registered, the user can easily access his account by signing a message.

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

During the signup process, the user must use an Ethereum address that will be irrevocably linked to all of his generated content. Peepeth issues several warnings that the account data is public, but fails to explain that the user is linking all prior blockchain activity (e.g., trades) to his activity on Peepeth (and all of his Twitter activity, if he links the two accounts).

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.


Configuring the system properly to use Ðapps is complex. Peepeth breaks the process down into parts and provides a useful checklist, following two timeless heuristics: showing the system status and helping users recover from errors. The overall usability on Peepeth is phenomenal.

Ensuring a good mobile experience

Peepeth is easy to use on mobile: most interactive elements have adequate target sizes, the layout isn’t too crammed, and it loads properly even on slow networks.

Baking education into the product

Peepeth strives to generate awareness and dispel common myths, one short message at a time. We applaud their efforts, but think these messages could be even more effective if presented in context — right before confirming the user’s post, for example. Too many educational messages at once, MyCrypto-style, are overwhelming.

Preparing the user for transactions

Summoning the wallet without prior notice is a bad idea. Peepeth does a good job of priming the user for approving a transaction: it explains that “saving to the blockchain costs ether” and lets the user learn more or choose a speed.

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

Making sure the system status is visible is a priority for Peepeth. Thanks to its status bar, the user can calmly keep using the app while the blockchain hasn’t synced — he’s reassured about the operation in the background.


Peepeth goes one step further than most Ðapps by letting the user group multiple actions into a single transaction, and delay her commits to the blockchain. This is an interesting pattern that may be desireable for content-heavy Ðapps, but it should be used judiciously.

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.


CryptoKitties is a game of digital collectible cats.


Although there are some leftover mentions of Metamask during the signup process, there’s no longer any Metamask-specific code, so CryptoKitties works well on Toshi, Status, and other wallets.

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.


CryptoKitties follows basic usability guidelines, and despite being originally conceived for desktops, is easy to use on phones.

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


CryptoKitties offers relevant and complete descriptions of what’s about to happen before the users initiate transactions, but prices are only shown in ether. Moreover, while the icon of three horizontal lines is slowly becoming synonymous with “ETH”, it’s confusing for first-time users.

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.


CryptoKitties uses a standard client-server architecture for providing a user interface and turning ERC-721s into visually appealing kittens. This is a good balance of centralized and trust-minimizing components. Could there be ways of batching transactions, putting a measure of trust on the CryptoKitties team, to make the system more appealing to certain users? Perhaps, but it’s not clear whether this is desirable.


OpenSea is a collectibles marketplace.


OpenSea delays user registration until his purchase. We think this is a fantastic design decision: the site lets the user browse freely and doesn’t get in the way until it may provide a legitimately useful service, like notifying the user via email.

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.


The site mostly follows best usability practices. While mobile support was added later on and still doesn’t feel very polished (some small fonts, weak navigation), the site is usable on phones.

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


The site does a good job of explaining how transactions work, but it doesn’t show transaction fees or time estimations. Prices are shown in ether only.

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:


Like CryptoKitties, OpenSea runs a central operation to serve a user interface, but its transactions are always handled trustlessly. As a decentralized marketplace, we don’t believe they should take steps to run a more efficient service if this came at the expense of having to trust them.


Airswap is a decentralized exchange that specializes in tokens.


Unlike the previous Ðapps, Airswap doesn’t request any information from the user. “Registration” only consists of signing a message before he trades. We believe this is the ideal workflow for crypto-to-crypto exchanges because the friction is greatly reduced. The only downside is that, currently, the service doesn’t have a way to contact the user if a transaction is rejected.

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.


Airswap is easy to use with its simple interface, search bar, and a layout clearly designed with mobile in mind. It effectively hides much of the complexity of peer-to-peer trades.

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.


Airswap does an exceptional job of providing relevant pre-trade information, uses a well-known currency, and even allows tweaking the gas price as an option for advanced users.

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 would make very little sense for Airswap to sacrifice trustlessness for efficiency, since its whole value proposition is being a decentralized exchange.



Bancor requires an account connected to SMS or a centralized server. We believe Ðapps should always give the user the option to register and access using a wallet.


Coming from Airswap, Bancor feels much more mature and finished, with features like fiat on-ramps and a hosted wallet that make it a lot more approachable for crypto newcomers.

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


Bancor’s transaction screens have great information design. Rates are shown in dollars and there are helpful explanations behind information buttons.

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.


One of the features that stands out is Bancor’s hosted wallet.

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. Acquiring ether and convincing users to spend it are the main sources of initial friction. Let’s keep working on ways to abstract gas away during onboarding. Good resources to build on are this talk on Universal Logins, and the current implementation of Identity Gas Relay.
  2. 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.
  3. Ð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.
  4. Ð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.
  5. 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.
  6. Wallets should use USD when communicating with the user, or even better, request the user’s native currency. Toshi does a fantastic job here.
  7. There should be a standard way to open Ðapp links in the user’s preferred application. Let’s research how this could be done.
  8. 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!

We’re starting to build out a community of designers in crypto. Check out designforcrypto.com, and join our discussion forums at discuss.conflux.network.

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!



Alejandro Machado
Design For Crypto

Cypherpunks design and code. Venezuela will be free. Long live Modernity.