Making Crypto Sticky — Part 1

A research driven foray into user behaviors on Ethereum

Steven Yuan
Good Audience

--

Illustration by Becky Jiras.

With the Constantinople upgrade around the corner (…or not), many people are hoping this is a first step towards true scalability for Ethereum. But will it solve our usability woes? Perhaps… but only in part. Making crypto speedy doesn’t necessarily make crypto sticky.

It’s no secret that transacting on Ethereum is a fundamentally difficult task for the average person. And fortunately there are many blockchain projects on the market today taking a serious look at usability. However, despite a newfound emphasis on design, there still seems to be a lack of fundamental research around current user behaviors. We end up designing based on assumptions we think we already know as opposed to designing based on what we actually know, partially due to the glaringly obvious shortcomings of blockchain usability.

A brilliant solution to the wrong problem can be worse than no solution at all: solve the correct problem.

I’m the type of person who tends to execute five steps ahead: excited about the end product and glossing over the steps it takes to get there. Case in point, I had already started coding (not even designing, mind you) a full-blown Javascript address management library when it suddenly occurred to me that I never asked the daunting question: “Am I making this for anyone else but myself?” I felt my stomach sink a little as the naiveté of my hasty decisions sank in. Don Norman reminds us in The Design of Everyday Things: “A brilliant solution to the wrong problem can be worse than no solution at all: solve the correct problem.”

While it’s a good exercise to solve for my own personal use-cases, cross examining behaviors and sentiments of a wider audience allows me to validate assumptions I currently hold. As a bonus, it also becomes a source of unexpected insights and new potential solutions.

So I stopped what I was doing and dug up the classic diverge/converge model before going any further:

  1. Assumptions — List out what I think I know.
  2. Research — Conduct a study (in this case, a survey) to collect data and draw insights.
  3. Validation — Reassess our original assumptions and arrive at a final problem statement.

Assumptions

Besides the obvious assumptions (*cough* “Ethereum doesn’t scale”) I chose to write down assumptions pertaining to current active users and the specific types of behaviors they engage in. Disclaimer: Many of these are derived from my own experiences as a starting point.

  • Most Ethereum users are fairly technical.
  • Most Ethereum users keep a reference document of commonly used addresses.
  • Most Ethereum users only transact a few times a month.
  • Most Ethereum users double-check the recipient address before sending a transaction.
  • Most Ethereum users don’t use ENS / don’t have a .eth address.

Research

In order to collect information around my assumptions, I designed the survey into four segments.

  • Sentiment: Qualitative Likert scale questions pertaining to how the participant generally perceives cryptocurrency and specifically Ethereum.
  • Context: Descriptive questions categorizing the degree of technicality the participant falls into (i.e., casual user or power user?).
  • Behavior: Specific questions pertaining to the the problem space. In this case, Ethereum transactions and address management.
  • Freeform: An open format response for any feedback on making Ethereum more user friendly.

✋ STOP! If you haven’t taken the survey yet and you‘ve had experience transacting with Ethereum, please take less than 5 minutes to answer this anonymous questionnaire and contribute to the research . Thank you!

The Results

  • Sample Size: 106 participants
  • Sourcing Channels: /r/ethereum, /r/ethtrader, /r/cryptocurrency, /r/dogecoin, Twitter, ~4 crypto specific Slack channels, Hoard Telegram Channel, Raven Protocol Telegram Channel, personal contacts
  • Link to raw data

While the number of data points were relatively low (106) for determining quantitative significance, I believe this cross section of channels is enough as a qualitative study to draw some interesting conclusions. I’m by no means a final authority on these topics, so I wholeheartedly welcome any constructive feedback and comments for improvement!

Sentiment and Context a.k.a. Participant Demographic

Our survey participant set can effectively be described as “cautiously optimistic practitioners,” as depicted below. They are bullish on the future, believe in the tech, and understand current shortcomings.

A radar chart depicting the first five Likert scale questions: “When I think of cryptocurrency I think of…”
“I trust in the integrity of the Ethereum network.”
“I am cautious when sending a transaction to the Ethereum network.”

In terms of transaction habits, participants regularly send upwards of $100USD+ per transaction (high value), but only a few times a month (low frequency).

“How much USD value are you sending on average per transaction?”
“How often do you conduct an Ethereum transaction?”

Lastly, participants effectively demonstrate technical prowess as observed in their responses to questions regarding gas (what is gas?):

  1. 61% of participants have experienced a transaction running out of gas.
  2. 78.3% of participants claim to know what gas is and how to use it.
  3. 64.2% of participants use a gas estimation service such as ethgasstation to calculate gas costs.

This is re-affirmed when we look at wallet usage statistics. Though MyCrypto and MyEtherWallet may be a relatively safe, decentralized(-ish), and full featured wallets, they are also notoriously difficult to use for someone new or non-technical when compared to something more centralized like Coinbase.

  1. 36.8% MyCrypto/MyEtherWallet (MEW)
  2. 27.4% MetaMask
  3. 18.9% Centralized Exchanges
  4. 16.9% Other

Behaviors: Double-Checking Addresses

With the participant demographic above as a backdrop, we can now attempt to identify patterns of behavior. Perhaps the least surprising out of all the data is the overwhelming amount of users who double-check addresses before sending a transaction. With the visibility of high profile scams and hacks coupled with the the fact that users are sending $100+ on average per transaction, double-checking numbers for accuracy only seems natural.

“Do you double check the addresses you are sending transactions to?” (modified)

However, besides the simple fact that people double-check their address, it’s interesting to note how people actually go about doing their checks. Over half of the people who say they double-check addresses say they do so by checking just the first and the last characters.

“If you do double check addresses, how do you usually check it?”

This seems to be a microcosm of the general trade-offs people make when it comes to security versus convenience. What’s intriguing and warrants further investigation is the possibility that there might be a universal threshold regarding this trade-off. In the case of double-checking addresses, specifically checking the first and last characters was a “good-enough” mechanism for the majority of users. The question is, why? Are there patterns of human psychology or sociology that dictate this behavior? Or perhaps this is a sepcific user behavior limited to this specific participant set? Further research on these kinds of tipping points may prove to be useful for the longevity of cyrptocurrency usability.

Follow-up question: Why does checking the first and last characters of a long randomly generated string seem to be a reasonable option for verifying its integrity?

Behaviors: Reference Documents

With all this checking, double-checking, copying, and pasting going on, I was thoroughly convinced that a large majority of users had a Google Doc or Notepad file with all their commonly used addresses on it. Here’s what the data said:

Nope.

About 60% of users surveyed don’t keep a reference of the addresses they use normally. Why might this be?

One possibility is the lack of a use-case. If we look at the wallet usage statistics above, about 20% of the participants use centralized exchanges as their main vehicle for transacting. It can be argued that for purely speculative purposes, where usage is mostly around centralized trading on one platform, labeling addresses simply isn’t an important use case.

Another possibility for the discrepancy may be due to security concerns. A clear understanding regarding the vulnerability of storing a centralized repository of addresses may lead people to avoid it all together.

Similarly, it’s possible that users simply chose not to be honest in their responses for this question. In the freeform segment, one participant quipped: “You can’t ask people about using Google Drive for addresses. No one will give you an honest answer for fear of being hacked.”

So is address labeling completely unnecessary? Probably not. One theory is that labeling will be more relevant as applications scale and more peer interactions occur. High frequency, high connection applications (such as chatting) benefit more from address labeling than low frequency, low connection applications (say, wiring money).

Follow-up question: How does frequency and number of contacts significantly affect the desire for readable identifiers?

Behaviors: Ethereum Name Service (ENS)

We currently have the choice to register readable addresses by using the Ethereum Name Service (ENS). Similar to how a .com domain name can point to an IP address, .eth names can point to an Ethereum address. But rather than purchasing names from a central entity, .eth names are sold through an automated decentralized auction that grants naming rights to the highest bidder. It sounds promising, but how many people actually have one?

For anyone that has actually tried to bid on a name, the numbers above will make sense. With a multiple day waiting period and a convoluted, error-prone claims process, I’ve personally missed multiple attempts at registering my own .eth names. Currently, using MyCrypto or MyEtherWallet is the only method for registering ENS names*. Outside of that there exists several reseller markets that sell .eth names at a premium. There’s no doubt that the UX of the entire process probably needs to be revisited, but that’s a post for another day.

Follow-up Question: How can the ENS registration experience be reimagined to be more user friendly while keeping the service decentralized and secure?

*Update: As of the writing of this article, two services have come to my attention that may ease the friction for registering ENS names. ENS manager (manager.ens.domains) and ETHSimple (ethsimple.com). I haven’t use these services yet, but they look promising and I may do a write up regarding them in the future.

Validation

Now that we’ve parsed our data and done some analysis, let’s revisit our assumptions and see how we did.

  • Most Ethereum users are extremely technical. ✅
  • Most Ethereum users keep a reference document of commonly used addresses. ❌
  • Most Ethereum users only transact a few times a month. ✅
  • Most Ethereum users double-check the recipient address before sending a transaction. ✅
  • Most Ethereum users don’t use ENS or have a .eth address. ✅

Though most assumptions were validated through the survey, there were still interesting nuances observed in the details. Below are some noteworthy callouts.

Insight: An Ethereum Experience = A (Slightly Worse) Banking Experience

Whether we like it or not, most users are sending high value transactions ($100USD+) at low frequencies (a few times a month). This puts Ethereum on par with how most people interact with a traditional fiat bank. And in reality, it might actually be slightly worse considering the litany of scams and the lack of insurance.

What it boils down to is this: In order to increase widespread adoption of Ethereum, messaging must evolve to center around micro-transactions: the ability to provide secure incremental transactions at a very high frequency for little to no fees. This will provide the edge needed to push Ethereum past the territory of current incumbents and into its own disruptive niche.

Opportunity Statement: How might we design experiences optimizing for low value, high frequency transactions?

Insight: Caution as a Function of Flexibility

Another important metric to consider is a users sentiment around caution. As depicted in the survey, most users agree that they are cautious when sending an Ethereum transaction. And while this isn’t inherently a bad mentality (in fact it’s a preferred mentality), it indicates a measure of user friction within the ecosystem. Caution arises when flexibility is absent.

We see this play out in Ethereum as the consequences of user errors today are often dire and irreversible (mistyping an address; losing your mnemonic recovery key; etc). And while these are all necessary responsibilities bestowed upon a user to maximize decentralization, the weight of these responsibilities stymies new users from joining the platform. Mechanisms encouraging flexibility (especially for lower value transactions) can spur an attitude of experimentation among new users, allowing them to get comfortable with the tech. Comfort then leads to confidence and trust in the technology, removing the mental barrier of risk.

Opportunity Statement: How might we build safeguards, failsafes, and flexibility for user error while maintaining acceptable decentralization?

Insight: Simplify, Simplify, Simplify

Last but not least, the freeform responses were a resounding echo for simplification on two main fronts: 1). Obfuscation of gas and 2). Readable addresses. The message is loud and clear: Don’t force users to be crypto experts to use crypto services.

Of course, asking people to understand gas or use hex strings is a far-cry from asking people to become crypto experts, but it’s enough friction to scare off average users.

Opportunity Statement: How do we simplify core components of the network while maintaining its integrity? Additionally, how might we make ENS easier to use so that .eth names are a common convention?

The Final Problem Statement

Current users and practitioners of Ethereum are subconsciously funneled into a subset of limited use cases due to a lack of flexibility, transparency, and feedback mechanisms resulting in stunted adoption of applications that would appeal to more general audiences.

Some may argue that focusing on current users isn’t as productive as focusing on all potential users. However, Jon Choi’s insightful write-up, Enter the Crypto Maze, describes something called intermediate utility that shouldn’t be ignored:

Intermediate utility refers to the usefulness of a network before it is sufficiently saturated…Two things help the creation of a network at an early stage: (1) the discovery of active peers despite small network size and (2) how compelling those experiences are before the network fully matures. Those are crucial factors in the “intermediate utility” of an early network. Early adoption paths with intermediate utility are often the only ways to achieve a desired end state.

If we can’t create usable experiences for current ethos-driven users, how can we expect adoption by non-ethos driven users? Solving problems for the most enthusiastic users today will bootstrap the network for new users tomorrow.

Next Steps

Armed with the problem statement above, we can begin to brainstorm solutions within specific areas of improvement: flexibility (wiggle room), transparency (certainty), and feedback (action/reaction). By aggregating the free form responses into these categories, we now have a rough first-pass at a prioritization framework:

  1. Transparency (~23 responses): ENS adoption, less convoluted gas, human readable addresses, transaction tagging, live price and token visibility
  2. Flexibility (~21 responses): easier ENS registration, 3rd party implementations and integrations, alternative purchasing methods
  3. Feedback (~11 responses): wizards and walkthroughs, automatic address checking/confirmation

With transparency and flexibility as a clear priority in terms of areas of improvement, I crafted this hypothesis as a starting point for testing and validation:

Providing a secure, decentralized, cross-platform way of labeling and inputting commonly used addresses will increase a users perceived comfort when interacting with the Ethereum network and encourage more frequent transactions.

And voilà! With a proper understanding of the problem we want to solve and a hypothesis in hand, we are now ready to roll our sleeves up and start putting pen to paper. Stay tuned for the next post! I’ll be detailing the experiment methodology and rapid prototyping techniques used to determine if our hypothesis holds true or not. Thank you for reading and please share and add a clap (or 50) if you enjoyed this post!

Shout outs

I’d like to thank a few amazing communities that posted (or allowed me to post) the research survey to their users in order to gather all this amazing data. This write-up could not have been done with out you. 👏

Raven Protocol
/r/Dogecoin

If you are interested in cryptocurrency usability research and design, I’d love to hear from you! Please email me personally at hello@stevenyuan.design, or reach out to me on Twitter @stevenleeyuan.

--

--

Human Experience Designer. Interested in all things Blockchain + Design. Tweet me: @stevenleeyuan