"Create wallet" UI workflow is confusing

[weilu]

Q: "if I don't enter a passphrase it still lets me create a wallet, is that intended?" A: "yes that's the point. It generates a seed phrase for you"

[jenbennings]

Here are some initial thoughts I’ve had regarding the user flow for setting up a passphrase.

A couple of key points have been raised so far:

• Generating a passphrase is a foreign concept to most users
• New users may avoid writing down their passphrase in an attempt to simply start using the app

Explain why this is important

If the passphrase is our ultimate defence against losing access to your account, we need to treat it with equal weight and brevity. This can be achieved through a combination of language and the manner in which we present the passphrase itself.

A more engaging way of revealing data

Delivering a generated passphrase as a single string of words and expecting them to be written down on paper is an easy opt-out for the user. If someone has set up an account and wishes to view the passphrase again, presenting it in its entirety is understandable. However, I think we need to approach the initial set up from a different angle.

In the example above, we reinforce individual words as part of a sequence, not as a copyable chunk of text. Something like this is also arguably easier to notate (your eye is not scanning a sentence), plus you have a progress indicator thrown in for good measure.

Validate their efforts

As part of this ‘wizard’ approach, it’s probably not a bad idea to touch base and communicate what point the user is at in the process either.

Something I’d argue we need to explain at this step is why a user needs a passphrase and and PIN. We attempted to solve this in our proposal to use one word from the passphrase as the user’s password, however that debate falls into another issue.

---

Thoughts, ideas and suggestions welcome

Disregard any brand/style decisions here, as this is more about communicating the ideas beyond a simple wireframe (I tend to explore aesthetics as part of this). Also, these are mobile-first examples—which, just in case we haven’t harped on about already, is where we start.

[javgh]

This is very nice - pretty cool ideas to communicate the process better!

I can see this working very well, when the user has a bit of time to get set up "properly". I know I already harped on about "instant on" :-), but even if we are going to decide against that for Hive JS, I would still like to point out the following two scenarios to keep in mind, which I consider fairly important:

1. I'm having a beer with a friend at bar and am introducing them to Bitcoin. They happen to have an iPhone, so I ask them to open Hive JS and I would like to send them their first bitcoins shortly after.

or, similar:

1. I'm manning the Hive booth at some conference and someone walks up, asking me to show them what Hive is. I would like to get them up and running on their own device quickly and ideally have some starter bitcoins for them ready right away (if they are new to Bitcoin as well).

Maybe an alternative to "instant on" could be some kind of demo account? Ben, I think it was, pointed out, that the instant on approach might result in users wondering whether this is even secure, if it's so easy to get into and that they are not invested in their own account afterwards. Maybe having a separate "demo account" would make it possible to differentiate that from the "proper", secure account. The demo account would just happen to be mostly completely functional and you could then have an "upgrade" process, where you turn your demo account into a proper account using a wizard like above. That would then include forwarding any funds you might already have to your proper account and also transferring any contacts, if you added any to your demo account. (At the bar for example, I would add my friend as a contact right away, of course, to easily send them some bitcoins.)

[mackuba]

Hmm... I like the "wizard" approach, though Jan's use cases with a friend in a bar or a person at a conference booth also make sense. Maybe we could let the users skip writing down the passphrase, but then keep nagging them about it until they confirm later that they've written it down?

[weilu]

I like the design a lot, the color, contrast and all - very pretty :)

The bar scenario: Grab a piece of napkin from the table, ask the bar tender for a pen, hand them to your friend, and tell him/her: if you write down the 12-word seed phrase and promise to keep them safe, I'll give you some bitcoin to get you started ;) Same thing goes for the Hive booth scenario.

Generating seed phrase takes a while (a few seconds), so maybe on the first screen, instead of "We're about to generate...", we make it "We are generating..." and the read more is something like a tooltip so user doesn't have to leave the page to read more about it?

[weilu]

@jenbennings Are we happy with the design? Can we close this now?

[jenbennings]

Yep! Will re-open it when/if any issues arise with the proposed flow once it is in the prototype.