owned this note
owned this note
Published
Linked with GitHub
# Ðapps UX Audit
We conducted a UX audit of 5 decentralized applications, using Status as the wallet on the Ethereum mainnet. We identified **heuristics** for good experiences that can be refined into actionable Ðapp store design guidelines, and made some **recommendations** for further improving the usability of the ecosystem.
## List of heuristics
### Onboarding
#### [WAG] Be wallet agnostic
The early days of web3, when Ðapps had Metamask-specific code, are gone. We expect Ðapps to work well on all major wallets, both in desktop and mobile.
We scored Ðapps from 1 to 10, judging their compatibility with Status, MetaMask, Toshi, and Trust.
#### [SIG] Use message signing for access
The community has decided on a signing standard to enable passwordless authentication and prove ownership of an Ethereum address. We expect Ðapps to allow registration and logins by using the standard implemented in most wallets.
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](https://medium.com/uport/privacy-preserving-identity-system-for-ethereum-dapps-a3352d1a93e8). 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.
### Usability
#### [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 Guidelines for User Interface Design](https://www.nngroup.com/articles/ten-usability-heuristics/) by Jakob Nielsen as reference.
#### [MOB] Design for mobile
People spend [almost twice as much time on mobile as they do on desktop](http://www.kpcb.com/internet-trends), and many people [only use mobile](https://www.statista.com/statistics/297504/number-of-us-mobile-only-internet-users/). 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](https://static.lukew.com/MobileFirst_LukeW.pdf) 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](https://sites.google.com/site/cognitivetheorymmlearning/segmenting-principle).
We scored Ðapps from 1 to 10, judging how much they help newcomers without overwhelming them.
### Transactions
#### [PFT] Prime the user for transactions
Transactions [introduce a lot of friction](https://www.behavioraleconomics.com/mini-encyclopedia-of-be/pain-of-paying/). We expect Ðapps to [prepare the user for an upcoming transaction](https://blog.hellobloom.io/how-to-make-a-user-friendly-ethereum-dapp-5a7e5ea6df22), and explain its purpose when it isn't obvious. This is a similar pattern to [priming users for permissions consent on mobile apps](https://www.useronboard.com/how-slingshot-onboards-new-users/?slide=61), 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, common amounts involve many decimal places, and few people recognize the Ξ symbol. 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](https://medium.com/design-for-crypto/direct-attention-away-from-pending-transactions-13a3348edb3e) 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.
### Decentralization
#### [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
### Onboarding
#### Invitation 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.
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
> How might we design a friendlier invitation flow that works cross-platform? One possibility could be making invitations tokenized assets sent directly to the user's chosen wallet.
#### Signing in
Once registered, the user can easily access his account by signing a message.
Registration, however, requires making a transaction to reserve a username in a trustless fashion. This introduces a lot of friction, but is a valid design decision for the usability-security tradeoff.
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
| **[SIG]** Use message signing for access | 8/10 |
#### 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.
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
| **[SIG]** Use message signing for access | 8/10 |
| **[PRI]** Prioritize privacy | 5/10 |
> In the future, wallets could automatically choose a fresh Ethereum address to use for every Ðapp, helping protect privacy without additional Ðapp developer overhead.
### Usability
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.
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
| **[SIG]** Use message signing for access | 8/10 |
| **[PRI]** Prioritize privacy | 5/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
#### 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.
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
| **[SIG]** Use message signing for access | 8/10 |
| **[PRI]** Prioritize privacy | 5/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 8/10 |
#### 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](https://medium.com/@candemosse/7e895aaff992).
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
| **[SIG]** Use message signing for access | 8/10 |
| **[PRI]** Prioritize privacy | 5/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MAP]** Manage the user's attention to pending transactions | 10/10 |
| **[MOB]** Design for mobile | 8/10 |
| **[EDU]** Include short and context-specific educational content | 7/10 |
### Transactions
#### 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.
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
| **[SIG]** Use message signing for access | 8/10 |
| **[PRI]** Prioritize privacy | 5/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 8/10 |
| **[EDU]** Include short and context-specific educational content | 7/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
> 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.
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
| **[SIG]** Use message signing for access | 8/10 |
| **[PRI]** Prioritize privacy | 5/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 8/10 |
| **[EDU]** Include short and context-specific educational content | 7/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 9/10 |
#### 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.
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
| **[SIG]** Use message signing for access | 8/10 |
| **[PRI]** Prioritize privacy | 5/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 8/10 |
| **[EDU]** Include short and context-specific educational content | 7/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 9/10 |
| **[MAP]** Manage the user's attention to pending transactions | 10/10 |
### Decentralization
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.
| Guideline / Ðapp | Peepeth |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 8/10 |
| **[SIG]** Use message signing for access | 8/10 |
| **[PRI]** Prioritize privacy | 5/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 8/10 |
| **[EDU]** Include short and context-specific educational content | 7/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 9/10 |
| **[MAP]** Manage the user's attention to pending transactions | 10/10 |
| **[CES]** Centralize strategically | 10/10 |
## CryptoKitties
### Onboarding
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.
| Guideline / Ðapp | CryptoKitties |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
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.
| Guideline / Ðapp | CryptoKitties |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
> How do users log out? This is an unsolved pattern: not all wallets allow users to switch to a different account. Besides, Ðapps currently use a combination of cookies and address detection to determine login status, which can be confusing.
While its [privacy policy](https://www.cryptokitties.co/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.
| Guideline / Ðapp | CryptoKitties |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
### Usability
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:
| Guideline / Ðapp | CryptoKitties |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 9/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
### Transactions
CryptoKitties offers relevant and complete descriptions of what's about to happen before the users initiate transactions, but prices are only shown in ether. Morevoer , while the icon of three horizontal lines (Ξ) is slowly becoming synonymous with "ETH", it's confusing for first-time users.
| Guideline / Ðapp | CryptoKitties |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 9/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 1/10 |
> 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.
| Guideline / Ðapp | CryptoKitties |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 9/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 1/10 |
| **[MAP]** Manage the user's attention to pending transactions | 5/10 |
### Decentralization
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 trustless 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.
| Guideline / Ðapp | CryptoKitties |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 9/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 1/10 |
| **[MAP]** Manage the user's attention to pending transactions | 5/10 |
| **[CES]** Centralize strategically | 10/10 |
## OpenSea
### Onboarding
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.
| Guideline / Ðapp | OpenSea |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
### Usability
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.
| Guideline / Ðapp | OpenSea |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 8/10 |
| **[MOB]** Design for mobile | 7/10 |
OpenSea provides some helpful educational content, but it's not always short or contextual. For example:
| Guideline / Ðapp | OpenSea |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 8/10 |
| **[MOB]** Design for mobile | 7/10 |
| **[EDU]** Include short and context-specific educational content | 6/10 |
### Transactions
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.
| Guideline / Ðapp | OpenSea |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 8/10 |
| **[MOB]** Design for mobile | 7/10 |
| **[EDU]** Include short and context-specific educational content | 6/10 |
| **[PFT]** Prime the user for transactions | 8/10 |
| **[CFC]** Communicate using a familiar currency | 1/10 |
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:
| Guideline / Ðapp | OpenSea |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 8/10 |
| **[MOB]** Design for mobile | 7/10 |
| **[EDU]** Include short and context-specific educational content | 6/10 |
| **[PFT]** Prime the user for transactions | 8/10 |
| **[CFC]** Communicate using a familiar currency | 1/10 |
| **[MAP]** Manage the user's attention to pending transactions | 7/10 |
### Decentralization
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 it would come at the expense of having to trust them.
| Guideline / Ðapp | OpenSea |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 8/10 |
| **[MOB]** Design for mobile | 7/10 |
| **[EDU]** Include short and context-specific educational content | 6/10 |
| **[PFT]** Prime the user for transactions | 8/10 |
| **[CFC]** Communicate using a familiar currency | 1/10 |
| **[MAP]** Manage the user's attention to pending transactions | 7/10 |
| **[CES]** Centralize strategically | 10/10 |
## Airswap
### Onboarding
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.
| Guideline / Ðapp | Airswap |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 10/10 |
### Usability
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, but the Ðapp doesn't feel any less useful because of this. They appear to have embraced that their users are familiar with basic trades on blockchains.
| Guideline / Ðapp | Airswap |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 10/10 |
| **[BAS]** Follow basic usability guidelines | 7/10 |
| **[MOB]** Design for mobile | 9/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
### Transactions
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.
| Guideline / Ðapp | Airswap |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 10/10 |
| **[BAS]** Follow basic usability guidelines | 7/10 |
| **[MOB]** Design for mobile | 9/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 9/10 |
| **[MAP]** Manage the user's attention to pending transactions | 3/10 |
### Decentralization
It would make very little sense for Airswap to sacrifice trustlessness for efficiency, since its whole value proposition is being a decentralized exchange.
| Guideline / Ðapp | Airswap |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 10/10 |
| **[PRI]** Prioritize privacy | 10/10 |
| **[BAS]** Follow basic usability guidelines | 7/10 |
| **[MOB]** Design for mobile | 9/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 10/10 |
| **[MAP]** Manage the user's attention to pending transactions | 3/10 |
| **[CES]** Centralize strategically | 10/10 |
## Bancor
### Onboarding
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.
| Guideline / Ðapp | Bancor |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 1/10 |
| **[PRI]** Prioritize privacy | 4/10 |
### Usability
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.
| Guideline / Ðapp | Bancor |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 1/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 10/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
### Transactions
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.
| Guideline / Ðapp | Bancor |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 1/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 10/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 10/10 |
| **[MAP]** Manage the user's attention to pending transactions | 4/10 |
### Decentralization
One of the features that stands out is Bancor's hosted wallet.
Offering this option allows people without wallets to start interacting with the crypto economy, which is great. However, Bancor's insistence of using the hosted wallet at every occassion goes against the ecosystem's goal of empowering people to use decentralized systems.
| Guideline / Ðapp | Bancor |
| ---------------------------------------------------------------- | ------- |
| **[WAG]** Be wallet agnostic | 10/10 |
| **[SIG]** Use message signing for access | 1/10 |
| **[PRI]** Prioritize privacy | 4/10 |
| **[BAS]** Follow basic usability guidelines | 10/10 |
| **[MOB]** Design for mobile | 10/10 |
| **[EDU]** Include short and context-specific educational content | 9/10 |
| **[PFT]** Prime the user for transactions | 10/10 |
| **[CFC]** Communicate using a familiar currency | 10/10 |
| **[MAP]** Manage the user's attention to pending transactions | 4/10 |
| **[CES]** Centralize strategically | 8/10 |
## Score comparisons
|Guideline / Ðapp|Peepeth|CryptoKitties|OpenSea|AirSwap|Bancor|
|----------------|-------|-------------|-------|-------|------|-----|
|**[WAG]** | 8/10 | 10/10 | 10/10 | 10/10 | 10/10
|**[SIG]** | 8/10 | 10/10 | 10/10 | 10/10 | 1/10
|**[PRI]** | 5/10 | 4/10 | 4/10 | 10/10 | 4/10
|**[BAS]** | 10/10 | 10/10 | 8/10 | 7/10 | 10/10
|**[MOB]** | 8/10 | 9/10 | 7/10 | 9/10 | 10/10
|**[EDU]** | 7/10 | 9/10 | 6/10 | 9/10 | 9/10
|**[PFT]** | 10/10 | 10/10 | 8/10 | 10/10 | 10/10
|**[CFC]** | 9/10 | 1/10 | 1/10 | 9/10 | 10/10
|**[MAP]** | 10/10 | 5/10 | 7/10 | 3/10 | 4/10
|**[CES]** | 10/10 | 10/10 | 10/10 | 10/10 | 8/10
## Recommendations
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](https://www.youtube.com/watch?v=qF2lhJzngto), and the current implementation of [Identity Gas Relay](https://github.com/status-im/contracts/blob/73-economic-abstraction/contracts/identity/IdentityGasRelay.sol).
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](https://eips.ethereum.org/EIPS/eip-712). 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](https://github.com/ethereum/EIPs/issues/802), but communication should operate off-chain.
5. Making [web3 access opt-in](https://eips.ethereum.org/EIPS/eip-1102) 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?
Before you go, remember (credit goes to Alex van de Sande):
Sign in with Wallet
