The login function is the basic function of every product, and users have become accustomed to it, but for product managers, it is the "key" that opens the door to the product world for users, and it needs to be well designed.
From the user's point of view, login is like a one-time function. After many APPs log in once on the mobile phone, they will not see the login page again until the next mobile phone change.
For users, the login function is "normal", but the product manager does not think so.
1. For the same lock, some people choose to install it on the entrance door, while others choose to install it on the room door
Currently, there are two mainstream designs for the placement logic of the login function: front-login and post-login.
Pre-login means that when the user opens the application, the application will require the user to log in first, and the user will be allowed to access resources only after the login is successful.
This kind of logic is like installing a lock on the entrance door. To enter the house, you need to open the lock on the entrance door first. Representative applications include WeChat, Alipay, etc.
Post-login means that when the user opens the app, he can access some resources of the app. When the user accesses a specific resource that requires account permissions, the user is required to log in.
This kind of logic is like installing a lock on the door of the room. You can enter the house at will, but if you want to enter the room, you need to unlock the room lock first. Representative applications include Douyin, Taobao, JD.com, etc.
Whether the login is front or back mainly depends on "resources".
If the resources of the application are basically "private resources", you need to pre-login, such as WeChat, Alipay, etc. The resources accessed are basically private information such as social networking, chatting, and payment, so the pre-login design will be adopted. Just like you have a TV, sofa and refrigerator in your living room, you'd better put a lock on your entrance door.
If most of the resources of the application belong to "public resources", you can post the login, such as Douyin, Taobao, JD.com, etc. The resources accessed are short videos, commodities, etc. These are resources that can be accessed publicly. If you want to check your order or collection, etc., you will only be asked to log in when it involves your "private resources". Are you sure you can't get a lock?
Second, when the lock is unlocked, the key will be assigned
Compared with the previous account password login, the mainstream login method of the application has now become the verification code login and third-party authorization login, which weakens the concept of registration.
Generally, when logging in, if the account does not exist, the system will automatically register a new account. This registration process is insensitive to the user. This is like when you want to unlock the lock and find that there is no key. The previous method was to let you go to another place to get a key, and then run back to unlock the lock. Now, you get a key on the spot and unlock the lock directly.
Mobile verification codes have become the preferred login method for most platforms.
Some applications still retain the account password login design. If the user logs in with the mobile phone verification code for the first time, there will be a problem, that is, the newly registered account does not have a password. For this situation, there are generally three solutions:
1. Add an entry for setting a password in the settings. If the account does not have a password, the entry will be displayed. If the user has already set a password, the entry can be changed to the entry for changing the password.
2. Adjust the registration process and add the function of setting a password when registering an account.
3. It is more complicated to judge and process when using the account password to log in.
The first thing to do is verify when you log in.
Then it is also necessary to add a process of setting a password in the non-login state.
There are also users who don't like the few seconds of waiting for receiving the SMS verification code, so they choose third-party authorized login.
Authorized login will jump to the third-party application, and the user clicks to agree to the authorization. After the authorization is successful, the "user ID" assigned by the third-party application will be obtained. The system will then check the obtained user ID in the system to see if there is a bound account. If you bind an account, it means that the user has not authorized to log in with this ID before, so you can create a new account and bind the ID.
This method brings more problems than the mobile phone verification code. The account can only get a third-party user ID. This time, not only does it not have a password, but it does not even have a mobile phone number. If the user changes to the mobile phone verification code to log in next time, he will register another account at this time, and the data of the two accounts are isolated, which is undoubtedly a kind of trouble for the user.
Therefore, except for those platforms that only support third-party authorized logins, any successful login through third-party authorization will generally require binding if the account has not been bound to a mobile phone number.
Of course, if it is a newly registered account, you can also ask the user to set a password after binding the mobile phone number, but this operation is too cumbersome for the user, and this link is generally discarded.
3. Unlock with lock
There is one of the most difficult problems to solve in the world, called the problems left over from history.
The formation of a product is the result of iteration, and it will take on different forms at different stages, but these forms are not always compatible. Maybe at a certain stage, the login of the product is mainly based on the mobile phone verification code, and at a certain stage, it becomes mainly based on the third-party authorized login. In the early stage, they may be independent, and different login methods will be registered as different accounts. At a certain stage, when the two methods are to be integrated, the problem is discovered. A third-party authorized login account that already has data needs to be bound to a mobile phone verification code login account that already has data. Conflicted.
This is like a door that can only be locked with one lock. At this time, you have two locks in your hand, and your intention is to lock both locks. At this time, there is a conflict. At this time, you can only "unlock with a lock". This is not a profound theory. Use one of these locks.
From the product point of view, the user can choose not to bind the third-party account to this mobile phone number, or to use two accounts separately. If you must bind the third-party account to this mobile phone number, the system can only ask you to Cancel one of the accounts and only keep one account.
The user may have used a third-party authorization to log in when logging in, and was required to bind a mobile phone number. As a result, the mobile phone number was also registered for an account.
It is also possible to bind a third-party account to an account that has already bound a mobile phone number, or to bind a mobile phone number to an account that has already been bound to a third party and find account conflicts. The basic idea is the same, and they all require cancellation of one of them. Account, only one account is reserved, and the reserved account can be bound to a mobile phone number and a third-party account at the same time.
Why do such an "extreme" design? The main reason is that both accounts have data. If one of them is not canceled and the data of the two accounts is forcibly merged, some data will conflict.
For example, suppose I want to merge two accounts. Data such as orders can be merged together, but if it is information such as avatars, nicknames, etc., one account cannot have two pieces of information at the same time, only one piece of information can be kept. So which account should I keep?
Maybe you think that the data that can be merged can be merged, and the data that cannot be merged allows users to choose to keep one of the accounts. This is theoretically feasible, but every time you develop a function related to the account, you have to consider which data can The cost of merging, which data has to be abandoned for merging, is too high, and it is far less economical than letting users log out of one of the accounts.
Therefore, the ordinary login function for users is actually the "key" for product managers to open the door to the product world for users.