Blockchain’s biggest UX problems (and how to solve them)

Felix Oppenheimer
Oct 17 · 6 min read
A prototype trading app

As blockchain apps continue evolving into a more mature market, competing with global juggernauts like Deloitte and Facebook, it’s vital to take a more disciplined approach to development.

Here are some of the obstacles keeping apps from widespread adoption as well as proposed solutions.

Blockchain software uses unnecessarily complicated, or obfuscated processes

A lot of blockchain software has been developed by developers, for developers. Software is designed like a control panel, rather than a user-centered product.

A consumer focused blockchain app should look and feel like a consumer app, with the same UX rigor and design approach.


  • Replace long tx-hashes with email addresses, phone numbers, and other commonly used addresses
  • Use QR codes when appropriate
  • Make sure the user understand’s what’s going on, by using the right amount of information, and clear language (see below)

Blockchain software uses arcane language

Geth, Weth, tx hashes, confirmations. ‘Pick your gas price.’ ‘The blockchain is congested’.

Blockchain software should look and feel as native to a general user as possible. This means smoothing out language to emulate processes which they’re already used to. Tx Hashes are just addresses, confirmations are just ‘processing’. Gas prices should be lumped in with the ‘processing fee’. Remember, power users can look up the exact details using a block-explorer, and more advanced information can be hidden behind prompts if necessary.

This does not mean new terms won’t crop up, and the lexicon will continue to evolve, but be sparing. Even after all of these years, you still finish your journey on Amazon with a ‘shopping cart’.


  • Use every day language that emulates user’s already known speech and actions
  • If any new language is presented, be sure to onboard it, or use tool-tips to explain in more detail.

Unique, fluctuating currencies mean users can’t make efficient decisions

Do you know that feeling when you first get to a foreign country and you try and buy something and your brain does summersaults trying to work out whether you’re getting a good deal or not? That’s what using an app with a unique fluctuating crypto-currency feels like. Users want to know what they’re getting. They want to know the value of what they’re using. Pricing your products with a 20 decimal ticker symbol which changes value radically every day leads to an unusable level of decision fatigue.


  • Don’t use a crypto-currency which is exchanged on a public market
  • Use real world currency values, or stablecoins.
  • Again: USE REAL CURRENCY VALUES. It’s time we move on from the immature concept that fiat values are somewhat inferior. The technology behind fiat may die, but the symbols and values will remain an important benchmark for decades to come.
  • Ensure that the pricing structure of your app is as simple and natural as possible

On-boarding fiat users into the crypto eco-system is difficult, and usually relies on them first using another platform

Currently, most dApps use a related crypto-currency in order to allow the user to transact and use the platform. For the most part these crypto-currencies will need to be purchased with another entry-way currency, such as Ether or Bitcoin. This means that before a user has even hit your onboarding process, they’re having to sign up to another blockchain app / exchange (usually Coinbase), and go through their convoluted onboarding system, often involving 2FA, KYC (identity verification) and more.

In the long term, the aim is that all users will be using crypto as their primary transactional currency of choice, but until then, it’s a big barrier


  • Go through the regulatory hurdles required to allow users to buy your currency directly through the app
  • Integrate with entry-platform APIs to make the switch easier (allowing users to link their Coinbase accounts to trade in Ether)
  • Don’t use a cryptocurrency at all

Regulations prevent basic functionality and are changing every day

Because most dApps deal with the transfer of value, the governments of the world, and especially the SEC, have had a lot to say about what can and can’t be done. This means that a lot of functionality is hampered by arcane laws that were created to deal with various spheres, from gambling to equities.

As a user experience designer, this means a lot of red tape and a lot of talking with lawyers. Nearly every function has a legal implication that needs to be checked off. A lot of the blockchain apps that survived these regulations did so by growing fast enough to wield enough power to negotiate, or by being based in offshore jurisdictions.


  • Work closely with lawyers and legal counsel
  • Move fast, but stay within the law

Blockchain technology slows down apps

Most dApps on the market today are still slow. This is especially a problem in fin-tech, where speed is everything. Wallet apps like Venmo, Zelle and Revolut have gained enormous amounts of users because they act on the basic UX principle of getting the user’s aims achieved faster than anyone else. You get sent money and it appears immediately.

There is a common misconception in the tech world that the general public will pick software based on factors such as security and privacy. Wrong. People will almost always take the path of least resistance, even if it means signing away their rights to a shifty EULA. Ultimately, convenience is king and security, privacy and other values only come after.


  • Use proxy information. Once the user does something, mark it on the interface immediately provided there is a high enough chance of it resolving, regardless of whether it’s been confirmed on the chain or not. If it doesn’t resolve, wind it back with an error. Do not make your user wait. Use language such as ‘available funds’ vs ‘funds’ to dictate what the user is trying to do vs what has actually happened.
  • This does not mean lie to your user; use language and optics to create an experience that feels snapper and works on the premise of likely outcomes. More information can be made available if the user wants to explore (clicking on a transaction to see status: processing, for example).
  • Eventually the tech will be fast enough that this will no longer be necessary and all interfaces will be pure truth

Decentralization gives the user too much responsibility

One of the main benefits of decentralization touted by crypto purists is that nobody else gets their hands on our money. But the fact is, we don’t want our own hands on it. We put it in banks, even though we don’t trust them. Why? Because we trust ourselves even less.

Whilst working on wallet software at a start up, no less than 4 of us — 1 designer and 3 engineers — lost our passwords within about a week. And poof- the money was gone. This is a room full of people who are literally working on software that revolves around the fact that if you lose your password, you lose your money. How many times have you forgotten a password?

Aside from that, who is responsible for hacks or other malfeasance? Often when the money’s gone, it’s gone. We take for granted the fact that banks will pro-actively fight and take responsibility for fraud and have complex systems of insurance to ensure the end user doesn’t get burned for their mistakes.

When discussing blockchain technology we often underestimate just how reliant we are on third parties, and it may take a long time — if ever — for that paradigm to shift.

Solutions for now:

  • Centralize where necessary. Keep user’s private keys. Implement extremely high security.
  • Contract institutional insurance policies.

Solutions in the future:

  • Decentralize keys once access is fool-proof. Advanced identity technologies that do not involve memorising numbers (see Civic, uPort).
  • Robust third party insurance, auditing and anti-fraud solutions.


The future of widespread dApp adoption is going to be marked by compromise, careful consideration and a focus on user goals, rather than stubborn ideological principles. Here’s some top level advice when building a blockchain product:

  • Use standard UX principles involving the use of native language, efficient information display and quick controls
  • Only use a publicly traded crypto-currency if it actually serves a purpose. If so, display as a floating dollar value.
  • Compromise on decentralization. Centralize what’s necessary to provide a fluid user experience until the technology has sufficiently advanced.

Overall, there’s one very easy solution to all of these problems: don’t use a blockchain. The vast majority of MVPs produced in the past couple years gained nothing from using the technology. Consider the path ahead.

Building an app?

We can help.

Get in touch at

Felix Oppenheimer

Written by

Creative Director @ Lux Nova

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade