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.

4 Answers 4


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.

  • Thank you for your reply. Option 3 sounds good. I think we could also drop the title and have the option to add it in the user profile later. So do you think the user should be asked after the first action (in the walkthrough they have to post something at the end) for the password? In case they close the walkthrough, they could be asked for that information too, or should they just have the ability to look around and only as soon as they want to post something, they have to enter data? It's a good point, that they should be able to change the mail, but the mail field is pre-filled.
    – chillmao
    Commented Apr 8, 2013 at 21:41
  • I don't agree that option 2 means you can't store a salted hash of the password. Of course you can't hash the email address because you need it to contact the user. But the password can be hashed. You don't need the password to create a login link. That login link can contain a random hash that is used to check the validity of the link. It doesn't need to have anything to do with the password because when using a link you don't really check the identity of the user, you just check the link. Like you say, you don't really authenticate. But it's not necessarily bad security either. Commented Apr 9, 2013 at 6:22
  • @KoenLageveen You are storing the link for option 2, not a password.
    – JohnGB
    Commented Apr 9, 2013 at 8:22
  • Ah, I think I have misunderstood the point of option 2, which as you say is a poor option all around then. Commented Apr 9, 2013 at 8:48

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.

  • Thanks for mentioning the research result. So you would kind of combine 2 options? Send the user a random password and a login link in each mail they'll get + having the ability to change the password in the walkthrough. I'm not sure if the login link is safe enough. But they could also check "remember me" at the password form, so they would always be logged in too as soon as they open the page. So the login link wouldn't really be needed in that case. What do you think?
    – chillmao
    Commented Apr 8, 2013 at 21:56
  • Here's a real world example from one of our apps. We create the user and a random password as soon as the invite is sent. The password is hashed, so we don't know it and we don't send it to the user (otherwise it would be in plain text in the email logs). Instead, the invite contains a link (with a long hash) that will log the user in (so he can use the application), and allow him to (optionally) change the password. The only security risk is the invite getting intercepted for an identity hack. But you have that risk anyway. Commented Apr 9, 2013 at 6:16

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.

  • So you would prefer our current user sign up? I'm not sure, if they would be confused, to do the walkthrough first. I think with the right wording you could tell the user, that he can look into it immediately and if he likes it, he can create his account. That's what I thought. They would see that it's useful or not. I think many users just don't want to sign up for a service, they didn't even seen first. What do you think?
    – chillmao
    Commented Apr 8, 2013 at 21:50
  • It depends on how you shape the jump point from the email to the app. If the link is shaped in such a way as to say 'sign up for our app', or 'start using our app', anything that gets in the way of those goals is poor UX as the user will not be interested in trying out the app first. However if you shape the email to say 'try out our app', then it makes sense to give them a demo. Maybe give them both options in the email? "try our app or sign up right now"? Commented Apr 9, 2013 at 1:21

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.