As a UX designer, or a UX designer to-be, do you remember the first time you design a login flow? Shorten the required steps is usually regarded as the “guidance” of a design, but why are still many login processes are like the pain in the neck? I recalled my first time designing a login page as a UX practice, it was such a “comfortable” experience. I put two input boxes at the centre of the frame and a submit button below. Even the “forget password” handling flow seems so natural. A year after, my thought of the login page changes when I got my first Login task at work: a login page for an enterprise cybersecurity product Like all enterprise product designs, the design focus is not only to create the experience of the provided feature itself, but also to fit into the customer’s ecosystem, and most importantly, to solve the security concerns. Usability is still one of the top priorities from the UX design perspective, but we might need a bit trade-off to meet the requirement of the solution ...

Have you thought about, why in some login page, the account and password input boxes are on the same page, but in other platforms are separated into two steps? When we sign up for a product, we create an identity on it that we can regard as a “local account.” However, most enterprises have used Identity and Access Management (IAM), which allows them to manage their assets and employers’ identity from accessing multiple products or services. With IAM integration, a user does not need to sign up for all the products for access, it is possible to sign in with the same account. That is, the user using their IAM account will be redirected to Single Sign-On (SSO) page to complete the login process.

The main purpose of a login page is to identify whether an account is valid to access. Imagine the local accounts and IAM accounts are stored in two separated tables, each table maps the account with the password and its access permission. How does the system know which table to check? This leads to the complex login process of an enterprise product.

A couple of user flows are commonly seen in the enterprise login page design.

Some of the login pages require the user to select the account type before inputting the account. The system then can map to the corresponded table for the identity information. However, the experience strongly relies on the user’s knowledge. A user may not be fully aware of their account type while signing into a console, a knowledge-based mistake then happens. The instruction and the error handling, in this case, is crucial to direct the user to the right attempt. ... Another common login design is to verify the account type by the system. When a user inputs their account, the system will verify if the account is an account from the integrated third-party IAM. This avoids the user’s mistake from selecting the incorrect account type, as long as they input the account correctly.

Let’s go over the types of errors we make, what causes them, what are the strategies for correcting errors and last but not least how to design for errors.

Disclaimer: the term system is used loosely to describe digital products, flows, actual systems, etc.