Similar to how Web 2.0 provided a paradigm shift in the way we interact and do business, Web 3.0 constitutes another foundational change thanks to new protocols and networks that undergird interactions on the web. The global adoption of Web 2.0 led to the the definition of an internet user experience which was defined by the necessities of Web 2.0 applications. Users became acclimated to managing email addresses and passwords, online bank accounts and routing numbers, credit cards, etc.

Web 3.0 also requires the definition of a user experience that enables massive blockchain adoption. However, many questions remain unanswered: Will users get used to blockchain wallets and tokens? Can users get used to the increased responsibility of managing their own data and information? Putting token volatility aside for a second, will users get used to the added risk of managing their own money and having virtually no one to blame for mistakes?

These questions alone suggest that Web 3.0 user experience will likely be significantly different from Web 2.0. Already in this early stage of blockchain development, we have seen a number of delineated user profiles emerge, and building successful blockchain platforms and businesses is contingent on understanding their needs and how they may change in the future.

To start answering the above proposed questions and many others, token-based platforms should take into account three main types of users.

Types of Users

When defining user personas for a specific platform or dApp, understanding token user behaviors becomes crucial. These behaviors have a significant impact on the way the platform or dApp should be designed, tested, and validated.

For token-based platforms, there are three high-level types of token participants present in every cryptosystem. While this is a simplified model of all the possibilities in the user space, they each relate to a specific desired user experience.

Token Adopters — this type of user has no problem holding, managing, or using tokens where they see fit.

— this type of user has no problem holding, managing, or using tokens where they see fit. Token Instant Users — this type of user would buy and use tokens on-demand but doesn’t want to deal with the volatility and security risk of storing tokens.

— this type of user would buy and use tokens on-demand but doesn’t want to deal with the volatility and security risk of storing tokens. Token Atheists — this type of user does not want to hold, manage, or use tokens at all.

Token Investors (or, one can argue, Speculators) probably constitute the majority today. There are some Token Adopters, Token Instant Users, and Token Atheists, but probably not as many. A good example of a Token Instant User would be in the remittances space, where the users don’t want to hold any crypto token — they want to buy the exact amount they need to send. A Token Adopter in this case would be someone who has no problem managing a crypto account for the main purpose of remittance payments. For blockchain platforms to move towards mainstream adoption, Token Adopters, Token Instant Users, and even Token Atheists must become the majority.

User personas for a token-based platform should be defined based on those user types, prior to detailing the user stories for each persona. Once this is done, tagging token-specific user stories would allow better feature design and testing.

Let’s Run Through an Example

For the purpose of this article, we have created a fictional example, a decentralized video sharing platform: DVS.

The DVS token functions as a medium of exchange, reflecting the price of video making. The token price varies depending on the demand and quality of videos.

Let’s assume we have two major participants for this platform:

Supply Side: Video Makers

Demand Side: CMOs (Chief Marketing Officers)

And let’s focus on the demand side for the sake of the example.

In this case, we would have three main user personas, according to the three user types mentioned above (you obviously could have many personas under each user type, but we will stick to this for the sake of simplicity).

After defining the user personas, we would then detail the user stories for each. Here’s a sample: