Best way for sign up process after invite

Question

We are building an app and I'd like to have a faster sign up process for users. Right now users can only get access after they got an invite by mail. After they got the mail, they can click on a link and they will be lead to the sign up form. This is asking for name, title and password. Next to the sign up form is a short text, what our app is about. After they signed up, they will be lead to the dashboard and have a 5 step guide, which explains most important functions and they are asked to do their first action.

Now I'm thinking about, how to get rid of the sign up in all these steps. The invite is necessary. So after invite they get a mail. The mail can contain:

1. a default password

2. a user specific login link

3. a link to the app

---

1. If they get a default password, they could login directly and start the walkthrough. Later they could update their profile at their profile page.

2. With the login link, they wouldn't need a password and would always be logged in automatically, when they use the link. Passwords wouldn't be needed.

3. They could get direct access to the app and do the walkthrough and after they did their first action, they will be asked to set a password.

Now my question: Which way do you think is best? Solution 1) is quite standard, they could login directly, but they would have to remember the default password or change it afterwards. I'm still not quite sure if solution 2) is safe enough and they would also have to save the link somewhere, so I'm tending to say that it's not quite useful, but it still came up as idea. Solution 3) would have the benefit, that they could use the app directly before finally signing up.

Answer 1

The short answer is to use option 3. If you would like the reasoning, read on.

Option 1
If you give me a password to use, I will have to either write it down somewhere or memorise it. The former is poor security, and the latter is just tedious. If anyone doesn't want one of these two options, they will have to create a new password, which is even more steps than what you currently have.

Option 2
A direct login link is fast the first time you use it, but annoying with poor security every other time as you have to find the link first. This means either: bookmarking it (terrible security); writing it down (poor security); or finding the email every time I want to log in (poor security and UX).

Additionally, the authentication information would be stored insecurely on your server. You wouldn't be able to store a salted hash of an email and password, which is in itself poor security.

You may also create a legal issue for yourself in that that you will never be able to show that any particular user has signed into the account. All you will be able to show is that a person had a link - which not legally authentication.

Option 3
This is the best of the three options, as it is both secure and good UX. Give an initial link to a walkthrough or demo account that the person can play with and start using, but make it clear to them that if they want to keep any data that they have entered, they will have to create an account.

Unless you have a valid need (not a want) for a title, I would drop that from the process and only ask them to choose an email address and password. The email address should be pre-filled in with the one that the invite was sent to, but they should be allowed to change it to a different address if they prefer.

Answer 2

I think you've got the right idea to get all the bumps smoothed out and just let your users get started.

I'm all for just giving a new user a random password. Microsoft did some research (which of course I cannot find right now) about this when they created the Homegroup feature for Windows. Users that had to create their own password showed hesitation, while users that were given a quite long random password were happy to write that down and be able to continue directly. Users should always be able to change their password, but most really don't like having to think one up (which is why everyone uses the same password everywhere). So, 1: yes, create a random password.

If you use the email address to uniquely identify the user, and now you have a password, it's easy to put a link in the invitation mail with a specific hash/code that allows them to log in immediately. You can do that in all emails sent by the application. The less I need to remember and enter passwords, the happier I am. It's safe as long as they don't pass the email around. But the same goes for passwords. You could have an expiration on the validity of the hash. I can't tell if it would be safe enough for your situation, but applications I have worked on all work like this. So, 2 is a definite yes from me as well.

You could ask them to change the password the first time they log in, as part of the walkthrough. You may or may not want to offer them the option of skipping this. But if you gave them a real password and if it's easy to find out how to change it, perhaps there is no real need to change it or to tell your users that they have to.

Answer 3

The process needs to reflect the users expectations when they go from the email to your app. The assumption I'm making is that you've shaped the email to say 'sign up for our app', or 'start using our app'. If so, the process should be as follows:

1. Send the user an email with a user specific link
2. When they click the link, prompt them to create a new password
3. Proceed with introduction etc.

The reason for the above is because of the following:

The User's goal and expectation when clicking on the link is to sign up for the service.

Do not impede this by forcing them to complete a different action within the application. They will be confused by a lack of feedback confirming sign up, or lack the ability to undertake further action to complete sign up. They may assume the link is broken or that they have already signed up (and close the window, thus abandoning the task).

Never ask users to remember things or carry them from one interface to another.

This is an easy way to create user errors. This is why you should not create a random password for them to copy and paste to login.

Users will not remember this password for later access either and will have to dig through their emails to relocate it (or just abandon the task).

Do not assume consistency of platform or location of access.

You cannot assume users will be using this application from the same PC and browser every time. They may have multiple PCs or tablets, want to access from work or even from their mobile. This is why you cannot rely on an 'always signed in' feature to store the password.

---

If the email is shaped to say try out our service, then you can start with a demo of the app. It might be beneficial to give users two options in the email so they can choose to either sign up or try out the app.

Answer 4

I choose option 3

The first option the user has to be learned normally dificial password and that password is also written in the mail.

In the second option would say that with generic users can't have a generic trace each user makes.

With the third option we provide a first access, but the user gets their own password