This article was written by **Logto* Team - An open-source solution that helps you build the sign-in, auth, and user identity within minutes. Check out our **GitHub** ! (5.0k stars)*

In the previous piece, we discussed the development of the Sign-in Experience, what makes a positive end-user encounter, and we ended on some thought-provoking topics.

How can I do this with as little effort as possible using the Logto Admin Console?
When compared to currently available market solutions, how does Logto’s configuration experience stand out? Curious to understand why this is the best choice for my business.
From a business perspective, how can sign-up be evaluated?
What does Logto have in store for future service and product development?

In this article, we'll answer these questions and show you how the Logto Admin Console can help.

Make Admin Console thoughtful and educational

The permutation and combination of identifier, Authentication Factor, Connector, and Personal information is a complex interaction design question. It’s very ambitious and there are lots of directions we can go. We listed them out, evaluated them and made the decision with the aligned trade-off on our team.

To enable the sign-in and sign-up, there are three high-level directions we explored.

Direction	Intuitive & easy to understand	Scalable and use cases coverage	Business reasonable	Examples
User has complete control over which identifiers to use and how they are linked using "or" and "and" logic.	Low
High	Low	Other CIAM products
Give users access to every conceivable option and let them decide what to pick.	High	Low	Medium	Logto V1
In the sign-up process, exhaust the enums until you're down to one single option. For sign-in, however, user choice and configuration flexibility that supports "or" logic is essential.	Medium	Medium	High	Logto V2

A sign-in experience is never complete without the Admin Console. We never lose sight of the fact that the Admin Console exists to support the experience we have suggested, and not the other way around. Many of the solutions out there that let users choose their own sign-in and sign-up processes end up making things more complicated for our developers and lowering the quality of the experience for end users because they don't cater for actual use cases.

In the end, we picked direction 3.

There are far too many illogical outcomes when following Option 1.
The second direction is not consistent with the principle of progressive disclosure. The amount of mental effort required is excessive, and there is no way to make it more scalable in the future.

First, we'll look at our sample of the Admin Console and run through the two most common use cases. You may learn more about how we make it possible with a robust tool like this.

The first scenario，

Sign up	Email with a password and verify email at sign up
Sign in	Email with password, Social accounts