After trying a product’s sign-up process again, my friend decided to quit

In this article, we demonstrate how Logto can mitigate certain frustrating user sign-in/up scenarios by presenting a real-life use case of Thomas, who had trouble signing in to the W app.
Darcy Ye
Darcy YeDeveloper
April 26, 20238 min read
After trying a product’s sign-up process again, my friend decided to quit


In this article, we demonstrate how Logto can mitigate certain frustrating user sign-in/up scenarios by presenting a real-life use case of Thomas, who had trouble signing in to the W app. As a dual user of both Apple and Android phones, he wanted to be able to check updates on W anytime and anywhere on both of his phones. However, he encountered problems while trying to sign in on his Android W app. After examining Thomas' usage scenario, there are several aspects of W's user login system that could be improved, which Logto avoids by integrating Apple login into the Android application, providing clear prompts and inquiries when adding information, prioritizing checking for related accounts, and having a relaxed time limit for account deletion.

Signing in/up is the first step for any app to acquire users, and a smooth and efficient login and registration process is the first impression that attracts users. When we meet new friends, we try to present our best side to leave a good first impression. Logto, as a product that values user experience very much, is also like this. In this article, we will demonstrate to users how Logto can mitigate certain frustrating scenarios by presenting a real-life use case.

Many times, it is difficult to migrate from one app to another. For example, if all your friends are using Facebook, even if you find Facebook not user-friendly and don't want to use it anymore, it is hard to persuade all your friends to switch to another social app because they also face the same problem. The same situation applies to other apps, such as a very active UGC platform. You may not want to use it, but many high-quality content producers only publish their content on this platform. In order to see the content of bloggers you like, you have to endure the inconvenience and stay on the platform.

Maintaining login and registration processes and user systems may seem very simple, but in reality, there are many complex scenarios.

Thomas’ user experience of W app

My friend Thomas shared with me his experience of using W (a cross-platform app with almost twice as many monthly active users as Twitter) and his troubles with it. What's surprising to Thomas is that an app with nearly 500 million MAUs can have such a terrible user experience!

W is a platform where users produce and share their own opinions. Users can see public interactions of the users they follow on their timelines. Thomas spends almost an hour on W every day to understand everyone's opinion on current hot topics.

Thomas was a heavy user of W until he ran into trouble. It all started when his personal account was banned by the platform. He still wanted to follow the content of bloggers he liked on W, so he had to register a new account.

As a dual user of both Apple and Android phones, he wanted to be able to check updates on W anytime and anywhere on both of his phones.

He attempted to create a new account on his iPhone W app and opted for Apple account sign-in due to privacy concerns. However, when he tried to sign in on the Android W app, he discovered that there was no option for Apple account sign-in. Therefore, he added a seldom-used phone number to the account already created on his iPhone and attempted to sign in to the previously created account on his Android phone using the phone number. However, W created a new account for him when he signed in with the newly bound phone number on his Android phone. The different accounts cannot manage the same subscription list, and there is no option for one-click migration of subscription lists, which means he cannot switch phones and ensure consistency in the content he views.

After a closer examination, he found out that a phone number added to an existing W account is not a default option for signing in, but rather a hidden option that can be upgraded. When he attempted to upgrade the phone number associated with the account he registered on the W app on his iPhone to a sign-in option, the system informed him that the number was already being used as a sign-in option and could not be updated. Moreover, when he tried to delete the account accidentally registered while attempting to sign in with his phone number on his Android device, the system informed him that the account could not be deleted within 30 days of its creation.

At this point, his plan to sign in to the same W account on both his Android and iPhone devices had to be abandoned, unless he wants to wait for 30 days and try again.

Later, we simulated the use case of W and built a demo with Logto as a login system, inviting Thomas to try out the sign-in experience. He mentioned that a qualified product shouldn't obstruct any operation that users want to complete. In comparison, the user experience of W is unsatisfactory. He expressed anger about it because some stupid product decisions made him unable to keep up with current events and important opinions in the upcoming month.

Key issues affecting W’s user experience

After examining Thomas’ usage scenario, there are several aspects of W's user login system that could be improved.

  1. Apple login could be integrated into the Android application.
  2. There could be an option to automatically upgrade the bound phone number or email address to a login option, or clearer prompts and inquiries when adding such information.
  3. When logging in with phone numbers or emails, which can easily prove ownership, the system should prioritize checking for related accounts and provide a quick login option, instead of simply creating a new account.
  4. For an empty account without any records, the time limit for account deletion could be relaxed.

Some may argue that the above usage scenario is extremely rare and seldom encountered, so it does not affect overall usage. However, Logto believes that the purpose of product design is to satisfy all reasonable usage scenarios when possible. Just like we cannot ignore the troubles that the current situation may cause to minority groups just because our lives can go on smoothly, one day we may encounter such situations ourselves.

If it weren't for the coincidence of all four issues happening at the same time, Thomas wouldn't have encountered this problem. Improvements made to any of the four issues mentioned regarding W's login system would address the obstacles in Thomas’ use case.

How does Logto avoid the aforementioned problems?

When designing the end-users’ sign-in/up flow, Logto conducted extensive research and made a lot of considerations.

Regarding the first issue, we have tried to use an Apple account to log in on different devices. Apple devices may have special handling for this, while in other cases, we can achieve this using an Apple account to log in on non-Apple devices by redirecting to the Apple ID webpage and obtaining the user's authorization. If you are a Notion user, you will find that they also do this and allow using an Apple account to log in on all devices without distinction.

For the second and third issues, any identifiable information added to a user's profile in the Logto account (such as phone number, email address, Google account, Apple account, or other related accounts) can be used as a basis for login. For example, if I have a Logto account created with a username and password, and then I bind an email address to the account, I can use this email address and password or verification code to log in to the same Logto account on any device. We do this to avoid creating multiple accounts unintentionally (which would make it difficult to manage resources across multiple accounts), and merging multiple accounts later on is a very complex task. We want to avoid this problem from day one.

For the last issue, as Logto is a backend identity infrastructure, we do not provide a user management page for end-users (Logto's direct users usually customize their own user detail pages with their own branding style). However, we provide a bunch of APIs for Logto's users to help them build their own end-user detail pages. Logto's users can use Logto Admin Console or APIs to modify, delete, suspend, and re-activate end-users' accounts.

What’s more?

What we've mentioned here is just the tip of the iceberg when it comes to Logto's design philosophy. In the future, we'll be publishing a series of articles to share our process under the hood of designing products and making important product decisions. We hope these will also help readers gain insights into how to optimize their own businesses. We're also looking forward to receiving feedback from readers about Logto products, as this is a two-way learning process.

The Logto team continuously improves its product by drawing inspiration from the community's various suggestions, with the aim of providing users with the best possible experience. Without the active input of users providing constructive feedback and collaborating with the team, we cannot create the perfect product. If you believe that Logto could benefit your business, please try Logto Cloud. If you have any questions or suggestions during use, do not hesitate to contact the Logto team and let us know your thoughts and requirements. Together, let's make Logto better!