 Have you ever tried to create an account and log into a website and found it surprisingly difficult? Now in this video you'll learn some simple techniques to make sure your site does a great job of handling names, passwords and account details. But before I start, do you really need your users to create an account? You know the best login is no login. Don't gate features behind login just because you can. Asking a user to create an account is asking them a favor. And remember that every password and every item of personal data that you store carries with it something I call privacy data debt. If you just need to save information for a user between navigations or browsing sessions, use client-side storage instead of forcing the user to create an account. You can find out more about client-side storage on web.dev. For example, for shopping sites, forcing users to create an account to make a purchase has been cited as one of the major reasons for shopping cart abandonment. Now if you do run an online store, make guests check out the default and offer to save customer details and create an account once a purchase has been completed. Okay, with all that out of the way, if you must get users to sign in, make it as quick and easy as possible. Firstly, make it really clear where to sign in. You know, one big login or sign-in button is good, not just some obscure icon or vague wording. And once users have signed in, make it really obvious how they can access their account details. In particular, make it simple to change passwords. Now you may be wondering whether to add buttons or links for account creation as well as to sign in. Well, many sites now simply display a single sign-in button and when the user clicks on that, they also get a link to create an account if necessary. Now that's a common pattern now and most of your users will understand it. Make sure to link accounts for users who sign up via an identity provider such as Google or Facebook and who also sign up using email and password. That's easy to do if you can access a user's email address from the profile data from the identity provider and match the two accounts. Now, I keep saying this, but whatever you do, make the most of the powerful cross-platform functionality that's built into form and input elements on all modern browsers. You can find out more from our article and video about sign-in form best practices on web.dev. That also has lots of great tips on how to improve form design, layout and accessibility. You know, in the sign-up flow, your job is to minimize complexity. So cut the clutter and keep the user focused. This is not the time for distractions or temptations. Collect additional user data such as name and address only when you need to and when the user sees a clear benefit from providing that data. Every item of data you communicate and store incurs cost and liability and you need to remember that. And by the way, don't double up your inputs just to make sure users get their contact details right. With autocomplete, that just makes no sense. Instead, send a confirmation code to the user once they've entered their contact details and then continue with account creation once they respond. That, again, is a well-known sign-up pattern now and a good approach. And one simple technique you might want to consider is to allow password-free sign-in by sending users a code every time they sign in on a new device or browser. Sites such as Slack and Medium use a version of this. As with Federated Login, this has the added benefit that you don't need to manage passwords. Now, in this case, you'll need to make a careful decision about session length, you know, how long the user remains logged in and what might cause you to log them out. But you'll need to do that whatever approach you take to user identity. There's no one hard and fast rule here, but you need to consider mobile versus desktop and whether users are sharing on desktop or, you know, sharing devices. You can get around some of the issues of shared devices by enforcing reauthentication for sensitive features, for example, when a purchase is made or an account updated. So here's the elephant in the room. You know, what's up with passwords? Like, passwords are, say, you know, last century. We need to wean ourselves off passwords, but that's not going to be an easy journey. You should, of course, offer Federated Login via identity providers, but the reality is that some users are more comfortable with email and password login. The problem, of course, is that users may give up on your site if they forget their password and, you know, especially with a new phone or computer and on shared devices. So what can you do? Well, you need to help third party and built-in browser password managers do what they do best. Suggest and store passwords so that users don't need to choose, remember, or type passwords themselves. Password managers work really well in modern browsers, syncing accounts across devices, across native and web apps, and for new devices. And this means the single most important task for you is to make sure you code your forms correctly. If you do one thing after watching this video, please double-check your HTML to make sure you're using the correct autocomplete values in your sign-up form. The sign-up forms use autocomplete equals new password for new passwords and autocomplete equals email. For email addresses. Coding forms correctly enables browser password managers to understand your code in order to save and to suggest strong passwords. Now, enabling password managers to suggest strong passwords is the best option, but many users want to enter their own passwords. So you need to implement rules for password strength. I won't go into the details here, but the U.S. National Institute of Standards and Technology, also known as NIST, provides full guidance. Now, whatever rules you choose for passwords, you should never allow compromised passwords. You know, once a user has entered a password, you need to check that it's not a password that's already been compromised. The site HaveIBeenPwned provides an API for password checking, or you can run this as a service yourself. Chrome password manager also allows you to check if any of your existing passwords have been compromised. If you do reject the password that a user proposes, tell them specifically why it was rejected. You know, show password problems in line as soon as the user has entered a value, not after they attempt to submit the sign-up form. You should, however, allow password pasting. There are a number of sensible use cases for copying a password from one context to another. Now, just a couple of quick things about password policy on the back end, and the single most important rule here is salt and hash your passwords, please. In other words, do not store or transmit passwords in plain text. And don't try to reinvent, you know, like your own hashing algorithm. Also, don't force users to periodically change their password. Research has shown that forcing password updates can be costly for IT departments, of course, and doesn't really have much impact on security. It's also likely to encourage people to use insecure, memorable passwords or to keep a physical record of passwords. Instead, you should monitor for unusual account activity and warn users. You should be doing that anyway. If possible, you should also monitor passwords for your existing users. To check for passwords that have become compromised because of data breaches. You can also give your users access to their account login history, showing them where and when a login happened. You should, of course, make it really simple for users to reset their password if they forget it. OWASP, that's the open web application security project, provides detailed guidance for this and lots of other identity use cases. You certainly should not use password hints to re-ferrify accounts. These are highly insecure. You should consider supporting multi-factor authentication, especially if your site handles personal or sensitive information. I really recommend taking a look at AG Kitamura's work on this, including his new video about SMS OTP best practices. So, you know, in the real world, you'll need to implement password handling. However, you should also enable your users to login via a third-party identity provider, also known as Federated Login. Now, this approach has several advantages. For users who create an account using Federated Login, you don't need to ask for, communicate, or store passwords. You may also be able to access additional verified profile information from Federated Login. Such as an email address, which means the user doesn't have to enter that data, and you don't need to do the verification yourself. Federated Login can also make it much easier for users when they get a new device. And you really need to think about this to consider first-day experience. Now, remember that many users are now expecting login from their phone, their laptop, their desktop tablet, like TV in the car, and, you know, on other platforms as well. And this is a moment where you risk losing users, or at least losing contact with them until they get set up again. You need to make it as easy as possible for users on new devices to get back up and running on your site, so this is another area where Federated Login can really help. Whether users access Federated Login or not, you should make account switching simple. Many users share devices, and it really reduces friction to be able to easily swap between accounts. Now, here's a thing that's crucial for keeping your users and your business safe. On many sites, it's surprisingly difficult to work out how to change your password. It's especially important to help your users change their password if they discover that it's been compromised. To make this even easier, you should add a well-known change password URL redirect to your site. And this enables password managers to navigate your users directly to your password management page. This feature is now implemented in Safari and Chrome, and is coming to other browsers. And you can find out more from our web.dev article. You should also make it simple for users to delete their account, if that's what they want. So, let's talk about names and usernames. And the first rule here is, don't insist on a username unless you need one. Well, if you do need usernames, don't impose unreasonable rules on them, and allow users to update the usernames and other personal information. Now, it sounds obvious, but that's why on the back end, you need a unique ID for every user, like not an identifier based on user data, such as a username. Now, you might want to validate names and usernames on the front end, but you need to be as unrestrictive as possible with characters and alphabets. So, here's a top tip. For names, addresses, and usernames, don't use regular expressions that only match Latin characters. Use Unicode letter matching instead, and your backend storage should support that securely as input and as output. Okay, one last thing. For signup forms, it's crucial to implement analytics and real user measurement. For your signup forms, you need to monitor page analytics for page views, bounce rates, exits, and so on, and make sure to add interaction analytics, such as goal funnels, you know, where do your users, like, abandon signup and so on. And events, like, for example, what proportion of users click your forgot password link. And lastly, track performance metrics to understand the real experience of your users. You can check out web vitals on web.dev to see how you can access real user performance data for core metrics. So that covers some of the basics to find out a whole lot more. Take a look at the article and the codelab that go with this video. And thanks so much for watching.