Joke Collection Website - Public benefit messages - User System Design (I) Front-end Design and Multi-platform Account Opening

User System Design (I) Front-end Design and Multi-platform Account Opening

Preface

User system is one of the most basic components of many products, but the more basic it is, the more open source it is, and the more difficult it is to improve it. When designing a user system, the first keywords that come to mind are registration and login. But it is not enough to have these two things. To improve the user system itself, we need to consider: multi-platform account opening, binding and unbinding between accounts on the same platform, account security, and what kind of front-end design is needed to meet the positioning of the product itself and the design of user operation.

There are two ways to realize the user system: 1. Build your own user system; 2. Authorized by a third party. The user information obtained by the third-party authorization is limited and subject to people, while the research and development and user use costs of building the user system by itself are not as good as those of the third-party authorization. Therefore, it is more that the two coexist and complement each other.

If there are imperfections and unprofessionals in defining the fields or requirements of the server, I hope you can give me more opinions and make them perfect.

1. Summary of requirements

1. Basic registration/login function of user system and front-end page design

2. Multi-platform account opening, that is, users registered in a single app can use this account to log in to all apps in the system

3. Users are relatively independent. For a single app, the user identity is unique

II. Front-end design

There are three mainstream designs for login registration (the prototype is as follows)

1. Account password priority

Account password priority is the most common login registration design, which is suitable for common scenarios, encourages users to log in by way of registration, and helps products guide users to improve more information and keep their own user information. For example, in Zhihu, account password login is the top priority, and third-party authorization login will be hidden. At present, account password login will use user registration instead of userid generated by the system as the account. Pure account password login is an early design, such as early qq and Fetion.

2. Fast login of mobile phone number takes precedence

Fast login of mobile phone number, also called secret-free login/SMS verification code login, is suitable for users to complete most behaviors without logging in, and users only need to log in when they have to obtain user identity in a certain scene, and the behavior that users want to complete at this time is interrupted by the required login operation. Common products, such as group purchase, are browsed, filtered and added to the shopping cart by the user in the application. When the last payment operation is to be made, it is found that the user is not logged in. At this time, cumbersome registration or login may lead to the loss of this order or even this user. Therefore, the way to obtain user identity must be as convenient as possible.

3. Third-party authorized login takes precedence

Third-party authorized login is suitable for products with low requirements on user information and authority and rapid development cost. It is suggested that you can access the third party first and realize the login function quickly in the early stage of building the user system. But if you want to build your own relationship chain, you still need to improve your own user system.

user information actually belongs to the content of user system design. The judging principle of whether to add this item is to decide whether to add a data filling page when users register, whether the data filling page is mandatory or skippable, what are the required data items and what they want to fill in. For example, if you need a relationship chain, you should force users to fill in the information and set the necessary nicknames and avatars when registering, so that users are effective users for such applications. Otherwise, users click on the information page in the app, which is all junk information automatically generated by the system, which is harmful to the construction of the relationship chain and retention.

The interaction details can be extended. How many steps does it take for a user to register or log in? Are these steps carried on one page or one page at a time as multiple pages? The advantage of a single page is that the user can have a clear expectation of what operations he needs to perform to complete the registration, but the disadvantage is that a page carrying too much information is messy and the order of operations will be unclear; The disadvantage of multi-page loading is that users have no complete expectation of the specific behavior of completing registration, and it is easier to jump out. The advantage is that the pages are neat and the path is single, which can guide users to follow the smooth preset path completely. I personally recommend the latter, because user expectations can be managed by page numbers/steps.

The following is the prototype of the user login/registration system that I designed according to the positioning and requirements of our products: As mentioned above, the user system I designed needs to carry multiple products, so I designed a combination of account password login and mobile phone number quick login to switch which one is presented to the user according to the scene that the user needs to log in.

Add some thoughtful points:

1. Apply for the permission to read the local phone number and help users fill in

2. Apply for the permission to read and write short messages, and automatically fill in and click Next when you get the verification code

3. It should be preceded by reminders: last login method, legal mobile phone number, correct graphic verification code, etc.

3. Design many products on the server side

. In particular, products without technical background will not contact and design the server requirements. In fact, there are not many requirements for contacting the server in my daily work. This is not to say that products should be responsible for designing a perfect user system server, but to learn to express their demands clearly in a way that colleagues at the server can understand, and there will not be too many deviations between the two sides in the realization of functions. This is the purpose of product design server.

the basic functional requirements of a simple user system server are: judging account identity (registered/unregistered), generating account identity (assigning id to new users), and verifying account password; What we want to design here is not satisfied with registration and login, we need to consider the user system with multi-platform accounts, and we need to unbind it with a single platform or multiple platforms and multiple accounts of users in the case of opening. Now, let's talk about some issues that need to be considered when opening a multi-platform account:

1. Creating the user system identity, because we are a multi-platform system, so the user identity can only be included in the users registered with the mobile phone number. If the third party authorizes the registration, it is also a user system user, and there will be confusion at the level of account binding;

2. To achieve multi-platform account opening, it is necessary to achieve multi-platform account opening, that is, all accessing multi-platforms can query the user identity;

3. User identity between platforms is independent. To achieve user identity independence between platforms, it is necessary to create a platform user identity based on the user identity of the user system;

(1) Multi-platform access of the user system

Explanation of terms

1)Appid: it is assigned first when accessing the user system, which is used to distinguish the accessed app;;

2)Unionid: when a user's mobile phone is registered, it is created by the user system according to the mobile phone number and used as the unique identity of the user in the user system;

3)Appuserid: when a user registers, it is created by the app server according to the openid authorized by the union or a third party, and serves as the unique identity of the user in the app;

Basic principles

1) As the only way to register the user system account, the unionid; is created and saved on the user system server according to the mobile phone number; The app server creates and saves the appuserid according to the unionid, and correspondingly saves the unionid;

2) the same unionid in the user system can correspond to different appuserids

3) registered users authorized by using third-party openid are not counted in the user system, and only the app server exists as a single app user, that is, only the appuserid is generated when the unioid is empty; Third-party authorization includes Weibo WeChat, QQ, Facebook and Twitter

1. Main flow chart

The main process of mobile phone number registration is:

When a user registers, the user system server needs to verify whether the mobile phone number+verification code is true or not, and whether this mobile phone number already has a corresponding unionid;; If prompted to register, please log in; If the corresponding unionid is not created, the app server creates an appuserid according to the unionid. At this point, the user system identity and the current app user identity have been successfully generated.

the main process of mobile phone number login is:

when a user logs in, the user system service verifies whether the mobile phone number+password is true, and whether this mobile phone number has a corresponding unionid. If so, it means that the user has the identity of the user system.

the app server also needs to inquire whether there is a corresponding appuserid. If there is a description that this user has this app identity, log in directly with his appuserid; If not, it means that other registered users of the joint app in the user system created the user identity of this app according to the unionid, and the login has been successful.

most apps have multiple user systems, and a single user system is not so complicated. However, if you want to build a product matrix to connect users between multiple platforms, plus account binding and unbinding, you will not be able to think clearly for a while. If you are interested, you will continue to supplement the things that account binding and account security products should care about and design. Thank you:)