My Role: Lead Product Designer Length: 3 months Project Type: Company project
This project started because the executives in my company, Mogujie, strategically decided to merge the account systems of our five products. Because of my experience in helping customer service and develop departments deal with registration related issues, I was recommended as the lead product designer for this project.
There are more than 150 million registered users using these five products. The number of account conflicts with active users (active in 6 months) is more than 50K, and these accounts also involve financial security problems.
Each product’s structure and account system differs with each other greatly, and we need to deal with a lot of information conflicts, which can easily confuse users.
Internal stakeholders including designers of each product, security team, financial team, mobile developers, back-end/front-end developers, Customer service, the legal team and so on are involved.
As the lead product designer, I worked with various teams to discuss problems and create solutions. I was also responsible for managing the project’s progress with a developer project manager.
About 40 days after release, the coverage of new versions of each product reached to about 90%, We forced all users to upgrade and no longer provide the old method of registration. At this point, we decided that the project was completed.
As a product designer, I did not just aim to realize the account integration. I also decided to redesign the entire account system in order to make the new system unified, safe, and bring a delightful experience. In order to achieve this goal, I set three main task goals:
Resolve information conflicts that occurred in the merging process.
Solve potential security risks, and make sure the new system is safe and reasonable.
Minimize the unpleasantness of the merging process and improve the experience of registration and login.
Currently, the account system of the five products is completely independent, having several different ways to register/login.
We need to merge these different ways into one Super Account to log in all products.
The main obstacle of account integration lies in dealing with the information conflicts among the different product accounts of each user.
After a comprehensive collection, we divided account information of different platforms into two types: main identify information and other personal information.
Considering that the changes may cause operational burdens on users, I set some principles for solving this problem:
After discussing with the cooperating departments, I decided to provide all products with one main processing logic. Each sub-product will then adjust the logic according to the special conditions of the various products. This is the main processing logic that has been determined after several iterations:
Due to the complex nature of the logic, I gave an example of the processing logic as a typical user case so that each member involved to better understand it.
Based on user feedback, we found that there was a serious security issue in the current registration/login flow. Some users changed their phone number, and the number was taken back and resold by mobile network operators, which might allow other users to access their account.
After discussing this with colleagues in the customer service and development departments, and after communicating with users, I found the main reasons behind this problem:
To deal with these problems, we put forward solutions one by one, and integrated them into a new registration/login process:
I optimized user experience throughout the entire project design process. Here, I extract some independent points to illustrate this.
Our products are partly social, and previously, in order to reduce registration costs, the system will randomly provide usernames composed of numbers and letters if the user does not want to set it themselves. I checked the data and found that more than 40% of accounts use default usernames, all of which made them look like spam accounts, destroying the community atmosphere.
So I decided to adjust the logic of setting usernames in the registration process to let more users use lovely names. But if users are required to set usernames manually, registration costs will inevitably increase, which may increase the turnover rate of registration. So how might we help users have lovely usernames without increasing operation costs?
I investigated the reasons behind why users do not like to set their own usernames:
I have used three methods to solve this problem:
1. Highlight a personal image in the registration process
2. Lower setting costs: extract username from third party accounts
3. Provide recommended usernames when what users have filled in are unavailable. Make sure that they can finish the process by inputting information only once.
I read a lot of comments to see what kind of usernames users would prefer, and I found that many users added English or numeric prefixes or suffixes to their usernames.
Therefore, I decided to provide English or number suffixes when a username was unavailable.
As an e-commerce platform, security is very important to our accounts. But our security department is always worried that users are using very simple passwords. In fact, a slight increase in the complexity of passwords can greatly increase account security. How can we encourage users to increase password complexity without increasing their operational burden?
First of all I dug through a variety of ways the reason why users always set a simple password: They are unaware of the importance of passwords when registering, and also did not realize that the complexity of the password can greatly improve account security.
In order to enhance the user's safety awareness, I designed two measures:
Only those whose network environment are unsafe will receive a security verification.
In order to increase account security, our security department requires an additional step of safety verification in the registration process, but this will inevitably increase users’ operational burden and affect user experience. How might we add security verification without compromising user experience?
At first, my discussions with the security department focused on which steps to add safety verification, and to try and reduce verification times. But safety and experience are hard to get along. After many rounds of tug-of-war negotiations, I suddenly realized that security and experience should not be antagonistic. We shouldn't compromise the experience of the majority users because of the security risk of the minority.
In the end, we have taken this strategy: determine users’ network environment in advance, divide them into different security levels, and then take different verification strategies under different levels of security.
The project lasted three months and involved more than 100 people in 9 teams. Within 40 days after release, the account complaint rate increased less than 1%. The third month after the new version was released, the account complaint rate dropped by 27% less than previous version, showing that the new account system had greatly improved in both security and experience.
This is my first time to be the Lead Product Designer of a large scale, cross-departmental cooperation project.
