One aspect we are used to with web2.0 services is speed; if a website takes too long to load, we may lose interest and potentially leave the site altogether. The experience is frustrating if it is slow and clunky, hence the need to improve page speed and responsiveness to user actions.

The size of the web page and its assets, or the response time of the server in which it is hosted are central factors in how fast the product responds to what we want it to do. Though not a direct consequence of the visual design of the product necessarily, it still plays a vital role in how a user experiences a service and forms their impression of how successful it has been, and importantly for businesses, whether they would use it again.

The blockchain by its very nature needs time to validate web3 actions on the other hand; through the process of consolidating and mining to the chain do we retain the core theme of decentralisation within blockchain products.

We like our chains to be fast and to know our transactions have been accepted successfully and quickly, however there are several factors that may arise which prevent this, for example high usage of the network at the time the user is interacting with it.

The core difference is that with a centralised product we expect the business itself to manage and improve its service, we expect them to fix issues and provide something that works, but with the decentralised blockchain we often cannot point the finger at the service we are interacting with. Some blockchains are simply slower than others to process, high network usage can lead to higher gas fees which in turn leads to longer transaction times and so on.

Whilst users may not understand or care about the server respond time, page load speed or the traffic on the blockchain — they just want it to work — this expectation of fast services has become the norm and is often a pain point of interacting with web3 services.

The combination of a web2.0 front end with web3 capabilities can lead to this problem, the interaction on the front end may be fast but the blockchain interaction could be slow. Many users may direct their anger or frustrations towards the business who’s product they are using, though it may have nothing to do with the business itself.

If a user doesn’t know to check their wallet, or examine the blockchain explorer, they are left in the dark of whether their transaction has been successful. If they are not well versed in the nuances of interacting with the blockchain and examining the status of a transaction, this can breed uncertainty, fear and lack of trust and transparency of the product they are using. This is particularly potent when it comes to sending money.

Blockchain services themselves typically do not give any indication of the network status to its users — average transaction times, whether the chain is congested, gas prices required to get their transaction through quickly etc. This is left to wallets like Metamask or explorers like Etherscan to hold this information, creating an extra step for end users.

Utilising this information should be a priority for blockchain products; give users the ability to see what they are interacting with, let them know how long their transaction will take to process. This information exists, it is just not being used in the correct place to alleviate any anxiety to those who are using the service or those who may benefit from it.

Integrating this information on the product front end would create several benefits. It will inform users of any potential issues the blockchain is experiencing, remove confusion as to how long an action will take to process and build trust in the product that this information is being given to them easily and transparently.

One aspect we are used to with web2.0 services is speed; if a website takes too long to load, we may lose interest and potentially leave the site altogether. The experience is frustrating if it is slow and clunky, hence the need to improve page speed and responsiveness to user actions.

The size of the web page and its assets, or the response time of the server in which it is hosted are central factors in how fast the product responds to what we want it to do. Though not a direct consequence of the visual design of the product necessarily, it still plays a vital role in how a user experiences a service and forms their impression of how successful it has been, and importantly for businesses, whether they would use it again.

The blockchain by its very nature needs time to validate web3 actions on the other hand; through the process of consolidating and mining to the chain do we retain the core theme of decentralisation within blockchain products.

We like our chains to be fast and to know our transactions have been accepted successfully and quickly, however there are several factors that may arise which prevent this, for example high usage of the network at the time the user is interacting with it.

The core difference is that with a centralised product we expect the business itself to manage and improve its service, we expect them to fix issues and provide something that works, but with the decentralised blockchain we often cannot point the finger at the service we are interacting with. Some blockchains are simply slower than others to process, high network usage can lead to higher gas fees which in turn leads to longer transaction times and so on.

Whilst users may not understand or care about the server respond time, page load speed or the traffic on the blockchain — they just want it to work — this expectation of fast services has become the norm and is often a pain point of interacting with web3 services.

The combination of a web2.0 front end with web3 capabilities can lead to this problem, the interaction on the front end may be fast but the blockchain interaction could be slow. Many users may direct their anger or frustrations towards the business who’s product they are using, though it may have nothing to do with the business itself.

If a user doesn’t know to check their wallet, or examine the blockchain explorer, they are left in the dark of whether their transaction has been successful. If they are not well versed in the nuances of interacting with the blockchain and examining the status of a transaction, this can breed uncertainty, fear and lack of trust and transparency of the product they are using. This is particularly potent when it comes to sending money.

Blockchain services themselves typically do not give any indication of the network status to its users — average transaction times, whether the chain is congested, gas prices required to get their transaction through quickly etc. This is left to wallets like Metamask or explorers like Etherscan to hold this information, creating an extra step for end users.

Utilising this information should be a priority for blockchain products; give users the ability to see what they are interacting with, let them know how long their transaction will take to process. This information exists, it is just not being used in the correct place to alleviate any anxiety to those who are using the service or those who may benefit from it.

Integrating this information on the product front end would create several benefits. It will inform users of any potential issues the blockchain is experiencing, remove confusion as to how long an action will take to process and build trust in the product that this information is being given to them easily and transparently.