You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After several rounds of usability testing for implicit account support, a particular piece of feedback has resonated across several conversations. Users have explicitly validated that there is in fact value and a desire to complete onboarding in a logged in state, before they are asked to make an initial deposit.
Anecdotes from Usability Sessions:
Asking me to fund this account before being logged in feels like a wall. I'd prefer to be in a logged in state, even if I still need to fund my account to do anything.
If I don't want to or can't make a deposit right away, don't stop me from finishing the onboarding. At least take me to my account and let me get a sense of how the wallet is used.
I want to be able to poke around. I want to be able to see what I might be able to do before I commit to making a deposit. Like, staking for example. I want to get a feel for the wallet before I'm forced to make my first deposit.
Banks have understood this forever (0 balance accounts). When you sign up for a bank account, you're not required to make a deposit right away before you're logged in. Onboarding doesn't cost anything. People expect this and are used to it.
Being able to click around and explore before I make my first deposit has value. It helps me answer the question. "What am I getting into?"
From a psychological perspective, it's beneficial for me to feel like I'm finished with onboarding before I'm asked for something.
Right now, you're asking me to make a deposit before telling me about custom addresses. Let me log in to my hashed address (implicit), and then say 'if you want to reserve a custom address, you'll need to make a deposit'. Then show me where I can get NEAR to make that first deposit.
Conclusion & Proposal
This has been debated for some time, as some members of the team have felt that there is no perceived utility in presenting a logged in state until an implicit account has been funded. While it is true that users inevitably need to make an initial deposit before performing txns, they have explicitly expressed that there is still value and benefit to being presented in a logged in state before being required to do so, in order to gain a level of confidence and familiarity with the product, and to better understand what kind of functionality the product will offer them once funded. Having this assumption be validated by users during usability testing is an important signal.
As a result, I must insist that for the next iteration of onboarding, users are presented a logged in state with their implicit account showing a 0 balance, with the ability to navigate through the wallet as normal, granted everything will be presented in its default "empty state" and all balances will indicate 0. The option to register a custom address will still be presented after the fact, but should be framed in such a way as to communicate that this action requires a deposit/balance.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Summary
After several rounds of usability testing for implicit account support, a particular piece of feedback has resonated across several conversations. Users have explicitly validated that there is in fact value and a desire to complete onboarding in a logged in state, before they are asked to make an initial deposit.
Anecdotes from Usability Sessions:
Conclusion & Proposal
This has been debated for some time, as some members of the team have felt that there is no perceived utility in presenting a logged in state until an implicit account has been funded. While it is true that users inevitably need to make an initial deposit before performing txns, they have explicitly expressed that there is still value and benefit to being presented in a logged in state before being required to do so, in order to gain a level of confidence and familiarity with the product, and to better understand what kind of functionality the product will offer them once funded. Having this assumption be validated by users during usability testing is an important signal.
As a result, I must insist that for the next iteration of onboarding, users are presented a logged in state with their implicit account showing a 0 balance, with the ability to navigate through the wallet as normal, granted everything will be presented in its default "empty state" and all balances will indicate
0
. The option to register a custom address will still be presented after the fact, but should be framed in such a way as to communicate that this action requires a deposit/balance.Beta Was this translation helpful? Give feedback.
All reactions