How to strike a balance between ease of use and security in the login interface

Whether you are a web designer or a UI designer, the design of login and registration pages is a job that you must have experienced. The design of the login interface is neither difficult nor easy. Finding the balance between security and usability requires considerable experience. Today's article comes from the GoSquared team. They are meticulous in the design of the login interface, which is worth learning~

We pay great attention to every design detail of GoSquared. The login interface has been recently revamped, and the newly added two-factor authentication mechanism makes user accounts more secure. At the same time, we also take this opportunity to gradually improve the user login experience.

Improving the user experience of the login interface is not as simple as it seems. While you make the login interface more beautiful, intuitive, fast and easy to use, you also need to make the process not so simple that it can be easily invaded by hackers or other bad actors.

Next, let’s take a look at the decisions made in this revision. If you want to experience the details of our revised version, please register a GoSquared account and log in!

Easy and effortless

Usually, we open the login interface not to view the login form itself, but to log in to the account. The form itself is merely a means to obtain personal information, not an end. From this point of view, the login experience should be easy and effortless, and all designs should try to reduce interference and remove obstacles, allowing you to complete the login task more easily without performing any unnecessary operations.

Due to the addition of the two-factor authentication mechanism, the login process is much more complicated than before. Compared to the traditional login method that only requires email and password, the current login method is not a simple one-time input to determine whether to log in or not. The newly added steps make login a new process consisting of several steps: clarify whether the account has relevant settings for two-factor authentication, and which verification method the user chooses. Many processes should also include the use of alternate devices/contacts, as well as emergency backup codes. We must take all of these factors into full consideration, but we cannot let them become a burden for logging in and make users feel tired.

Placeholders and Labels

How to choose the display form of placeholders in the form is a very tricky thing. From a design perspective, placeholders are great. But it’s not easy to use well, especially when it comes to accessibility and form auto-fill. If you use HTML to implement placeholders, the placeholders will disappear while the user is typing, with the result that some users may forget what they actually wanted to enter. What’s more troublesome is that if your browser automatically fills in the previous information, then you will never see the placeholder.

We have successfully circumvented this problem before by detecting whether the form content is manually entered or automatically filled. When the content is automatically filled by the browser, there will be a label to indicate the input content. If it is manually entered, no label will be displayed. However, we later discovered that users like to have label reminders before submitting to ensure that what they enter is correct, which means that they hope that the label will remain during the input process.

So, we finally came up with an elegant solution, using a separate element as the placeholder label. When the user enters, the placeholder label will automatically move out of the input box:

Of course, on mobile devices, space is limited, so the placeholder tag can be moved like this:

Of course, in order to perfectly realize all of these designs, some interesting challenges still need to be solved.

Awkward security features

When we first used code to control these labels and placeholders, it was not complicated: every time the content in the form changes, the content is detected; if the content is empty, the placeholder label is displayed in the form; if it is not empty, it is moved out. When the page is just loaded, the system will automatically check several times to see if the browser has auto-fill content.

But even so, there are still problems. There is a security feature in the Chrome browser called PasswordAutofillAgent::PasswordValueGatekeeper. The special thing about this feature is that it does not fill the previously saved account and password fields directly into the form, even if they appear to be filled in (of course, users usually don't want the browser to fill in the content and submit it). Only when the user interacts with the page (that is, when submitting the content), the form in the browser can detect that the content has been filled. Therefore, the browser design makes our tags appear like this:

So in order to avoid these problems as much as possible, the main solution is to detect whether the input content is consistent with the :-webkit-autofill selector, and whether the input content exists or not. It doesn't look pretty, but it's very effective.

A more fluid interface

Redirecting the page after each step is what web designers did in 2008. This design may be more compatible and more foolproof, but GoSquared's app no ​​longer supports this feature.

The new GoSquared login interface has stronger fluidity, smoother motion and natural state switching, which is really fascinating.

Verification and recommendations

As we mentioned in the previous article, the previous design made it very easy to type the wrong login email address and username, and the system would not remind you until you submitted the entry that the password or account you entered was incorrect.

Email name correction tools such as Mailcheck can correct most email address input errors, greatly reducing the login input error rate. We added this component in the previous version and it now also serves the new version.

The return of the login button

When we designed the previous version, we drastically cut down on other non-important elements in the interface, resulting in only two input boxes on the login interface without any other visual elements. After all, today, it is natural to enter your account and password and press the Enter key to log in, so having a login button doesn’t seem to matter much.

However, when we observed actual user operations, we realized that many users would rather click a button to submit the form than click the Enter key. This also prompted us to finally bring back the login button in the new version.

Wait, why is login so slow?

After we click the "Login" button, we usually wait for a few seconds before entering the login interface. Even after we have made many optimizations, users still need to wait for a few seconds before they can log in properly. There is actually a reason for this: security. After users submit their account passwords, the backend server needs to spend a huge amount of computing to make sure they are correct. We cannot describe the specific mechanism in detail here, but this is done to prevent someone from hacking into the system by brute force.

Of course, it is precisely because of this slow process that we don’t want users to face a stuck login interface alone. We need to use visual feedback through design to tell users “your form has been submitted, everything is normal, you just need to wait a moment to enter!”

So we added a progress bar in this step to show users how long it is expected to take to log in, which gives them a clear expectation of how long it will take to log in. However, a time-based progress bar on its own is pretty dull and not necessarily accurate, so we ended up using a very subtle animation as an alternative.

Conclusion

User experience and UI design are not static things, they will constantly adjust with changes in time and region. I hope you will like the improvements to the GoSquared login interface, and I also hope that our improvement process can provide some inspiration to our peers.