 Have you ever gone to a website to buy something and you know actually found it surprisingly difficult to fill in address and payment forms to complete your purchase especially on mobile? Or maybe you actually work on a website that sells stuff. Do you worry that you lose customers between shopping trolley and checkout? Well we talked to our colleagues on the Chrome team and we looked through loads of case studies to find successful patterns for payment and checkout that can increase your conversion rates. I'm Ali. I'm a product manager on Chrome and I work on password manager and autofill for payments and addresses. And I'm Sam a developer advocate for the Chrome team. We're not going to cover everything. Yeah we'll show you how to simplify the checkout journey, how to build the best possible experience for address and contact forms and how to implement best practice for payment forms. Checkout and payment design can make or break a business. One small fix to a code can have a massive impact on conversion rates. So even if you're an experienced developer we hope you'll find something useful here. Yeah speaking of which if you do one thing after watching this video please check your HTML code. Well formed HTML is the core of a good checkout experience and it gives you meaningful readable code. If you've seen our video about sign-in best practice you may recognize some of the advice here but it's worth repeating. So first thing use the elements built for the job. Your old friends form, label, input and button. Use these elements as intended and that enables cross-platform built-in browser functionality and improves accessibility. You can style all these elements just how you want and still take advantage of their special powers. So let's take a look. Now you might be tempted to avoid using a form element you know just like wrap inputs in a div or something and handle form submission purely with JavaScript. Well don't do it. A plain old form gives you access to a powerful set of built-in features across all modern browsers and can help make your site accessible to screen readers and other assistive devices. An HTML form also makes it simpler to build basic functionality for older browsers with limited JavaScript support and to enable form submission even if there's a glitch with your code and actually for the small number of users who you know disable JavaScript. Now as well as using a form you should take advantage of all the features that the HTML input element has to offer. Input attributes provide like a whole stack of useful standardized features. First up let's take a look at the type attribute. Make sure to use the appropriate type attribute to provide the right keyboard on mobile and to enable basic built-in validation by the browser. No JavaScript required. So you know use input type equals email for email and type equals tell for telephone numbers. But watch out using type equals number adds an up-down arrow to increment numbers and you know that makes no sense at all for data like credit card numbers or pin numbers. So instead you should specify input mode equals numeric to get a numeric keyboard on mobile. You know some sites used to use this like type equals tell for credit cards to get the right keyboard. Input mode is widely supported now. So you don't do that. Just use the default input type value which is text. In the examples here I've actually set it here explicitly just to be clear. Now the autocomplete attribute is even more powerful. Using appropriate autocomplete values enables browsers to help your users by securely storing data and auto-filling inputs. By default if an appropriate autocomplete value is available for an input well you should add it to your code. Lastly make sure to add the required attribute to required fields. Reason being that modern browsers automatically prompt and set focus for missing data when a form is submitted. Okay so that's enough about inputs. Well what about input labels? Well to label an input use a label element. You associate a label with an input by giving the labels for attribute the same value as the inputs ID. On your address forms use a single label for a single input and don't try to label multiple inputs. A tap or a click on a label moves focus to the input it's associated with and screen readers announce label text when the label or the label's input gets focus. Sign in, heading one. Email with a hint. Now placeholders can be useful but you know don't use them like solely as input labels. It can be really hard to remember what the input was for once you've started entering text especially if you're out and about you know you're using your phone and you get distracted. You know what it's like was I entering my email address or a username I just can't remember. Anyway lastly I've said it before but use buttons for buttons. Button elements provide accessible behavior and built-in functionality for form submission and you can also use input type equals submit you know but there's no point in using like a div or some other random element acting as a button. You should consider disabling a submit button once the user has tapped or clicked it especially when they're making payment or placing an order. Many users click buttons multiple times even when they're working fine and this can really mess up your checkout flow and add to server load. Now on the other hand don't disable a submit button waiting on complete and valid user input. For example you know don't just leave a make payment button disabled as something is missing or invalid in an address form. It you know it just looks like it's not working. Instead explain to the user what they need to do and show them how to fix it if they attempt to submit the form with an invalid data. This is a real example you know I was trying to buy tickets to an event this morning and it was really difficult to work out why the payment button was disabled. Anyway there are loads more tips about layout design and accessibility in our web.dev live talk sign in best practice and there's a link in the description of this video. Okay enough HTML. Let's take a high level look at the whole checkout journey. The guiding principle here is pretty obvious. You can think of your users as having a fatigue budget. Once you've consumed too much of it your users will leave. So you need to reduce friction and maintain focus. How can you structure the checkout journey so that you don't lose customers along the way? Well it's worth thinking about where your customers start and end their shopping journey. Many sites get more traffic on mobile but far more conversions on desktop. You need to minimize lost conversions on mobile and maximize conversions once customers are on desktop. The mobile commerce gap as it's been called is partly about customers choosing to convert on desktop. However lower mobile conversion rates can also be a result of poor user experience. Research has shown that there's a huge opportunity to provide a better form experience on mobile. Most of all users are more likely to abandon forms that look long, complex and without a sense of direction. Especially on smaller screens and when users get distracted or if they're in a rush. First of all for an online store you can reduce friction by making guests checkout the default. In other words don't force users to create an account before making a purchase. Not allowing guest checkout is cited as a major reason for shopping cart abandonment. Let users select products and check out with the minimum of data entry. You can offer account sign up after checkout. At that point you already have most if not all of the data you need to set up an account. So account creation should be quick and easy for the user. One small tip here. If you do offer sign up after checkout make sure that the purchase the user just made is linked to the newly created account. You can find out more from our video and article about sign up form best practices. You can make your checkout process feel less complex by clearly showing what needs to be done next. And by showing progress throughout the checkout flow you need to maintain momentum. For each step towards checkout use descriptive call to actions that make the next steps obvious. For example you can label the submit button on your delivery address form as proceed to payment rather than simply continue or save. Limit potential exit points by removing visual clutter and distractions such as product promotions in the checkout step. Many successful retailers even remove navigation and search functionality at this step. Keep the journey focused. This is not the time to tempt users to do something else. For returning users you can simplify the checkout flow even more by hiding data they don't need to see. For example you can set the billing address to be the same as the delivery address by default and then allow users to change this. Cut down on visual clutter by displaying existing data as plain text rather than showing the data in a form. You should make it easy for users to go back and forth within the checkout flow particularly for adjusting their order when they're at the final payment step. The aim is to make life easier for users and lastly show full details of the order before the final payment step. Some sites only show a limited summary. Users should be able to quickly confirm that they haven't made any mistakes with items or quantity. Speaking of which make it possible to edit item quantities from the payment page. Again the aim is to avoid interrupting the progress towards conversion. Okay thanks for that Allie. I particularly like the advice about offering guest checkout. Anyway let's dive into name and address forms. As we said before the core principle is to reduce form fatigue especially on mobile and for addresses that means minimizing the amount of typing. Now first question which I know is pretty obvious but you know do you really need to get all the data you're asking for from your user? If you don't really need a name or a physical address don't ask for it. If you just need to support features like you know allowing a user to find their nearest store let them use their zip or postal code or whatever. Anyway first up name inputs. Now unless you have a good reason not to use a single input for names dividing name inputs into multiple parts makes forms more complex and by the way it does actually assume that your user structures their name like that which may not be the case. Shout out to our colleague Serma. His name is Serma. Not Serma Serma not Hair Serma. Just Serma. Anyway use a single name input and that also makes cut and paste and auto-fill simpler. Also you know unless you have a good reason not to don't bother adding a separate input for a prefix or title like misses or doctor. Users can type that in with a name if they want to. Also just in general make sure to use the right autocomplete values and that's name for a full name and there are other values available if you really do have to split out name parts. You might want to validate your name inputs but you need to be as unrestrictive as possible with characters and alphabets for names and other values. You know it's pretty rude to get told your name is you know invalid. So here's a top tip for names addresses and usernames. Don't use regular expressions that only match Latin characters. Latin only is a pain for users with names or addresses that include characters that aren't in the Latin alphabet. Use unicode letter matching instead and you know your back end must support that securely as both input and as output. Now when you're designing an address form you know bear in mind the bewildering variety of address formats even within a single country. Be careful not to make assumptions about you know what you might think of as normal addresses. Having said that using two address lines does actually work well enough for quite a lot of address formats and for this use inputs with address line autocomplete attributes and add labels to match. Wherever possible keep address form fields you know as flexible as possible. For example don't put house number and street name in separate inputs because that makes it hard for browsers to autofill address inputs and it doesn't always fit address formats. So you may also want to consider using a single text area for address entry and that's the most flexible option of all. For a text area use street address as the autocomplete value. The text area approach fits any address and it's great for cutting and pasting but just I mean bear in mind that of course it may not fit your data requirements and users may miss out on autocomplete if they previously only used forms with address line one and address line two. You should of course use autocomplete values for billing address just as you do for shipping address so the user doesn't have to re-enter the same data. Of course the billing address may be different from the shipping address. Well luckily you can add a prefix word to an autocomplete attribute to enable different values for inputs with the same name in different sections. So in this example you enable autofill for a billing address as well as a shipping address but also allow for differences. Now it's really important to consider internationalization and localization depending on where your users are located. We all know the variations in address formats. US addresses have a state you know and UK addresses have a county well mostly actually mine doesn't but anyway you know the deal but you know just be aware that naming varies as well zip versus postcode shipping versus delivery and so on. We can't go into all the details for regional variations in this video but just you know bear in mind that it's really off-putting to be presented with a form that doesn't fit your address or that doesn't use your language. You can find out more from the article that goes with this video. Now one trend we've seen recently is for websites to use a service to look up addresses based on postal code or zip and this you know this might be sensible for some use cases but you should be aware of the potential downsides. Postal code address suggestion doesn't work for all countries and in some regions postcodes can include a huge number of potential addresses. Apparently there are postcodes in the UK that cover up to seven different roads and actually my colleagues just told me that in Germany that you know it can be way more than that and it's really fiddly for users if they have to select from a long list of addresses and then you know you can still get it wrong. It could just be quicker and less error prone to let users take advantage of autofill. That way they can get their complete address filled with a single tap or click. Thanks Sam. I think your guidance on localization is particularly important. Now let's take a look at payment forms. First up once again the autocomplete attribute helps the browser store and autofill data to users so that they don't have to type. That's particularly helpful on mobile where users may struggle to correctly enter their credit card numbers and other details. You should add autocomplete values for credit card number, the name on the card and for the expiry year and month. For dates as a general rule try to avoid using custom select elements since they break the autofill experience if they're not properly implemented and they don't work on all the browsers. You may also want to consider using a plain input element for data such as year rather than a select. We've also noticed that some sites add multiple inputs for credit card and phone numbers. It's best not to do that. Use a single input instead. It makes it easier for users to fill in their data and it enables browsers to autofill. You should add validation for data entry both in real time and before submission. One way to do this is by adding pattern attribute to a credit card input. If the user attempts to submit the payment form with an invalid value the browser displays a warning message and sets focus on the input. No javascript required. HTML form elements and attributes have built-in features for basic validation but you should also use javascript to do more robust validation while users are entering data and when they're about to submit the form. You can find out more from the code lab that goes with this video that goes into the constraint validation API which is widely supported to add custom validation using built-in browser UI to set focus and display prompts. Just bear in mind that even with client-side validation you must still ensure that the backend securely handles input and output of data from users. You may want to use a one-time passcode for address or payment verification but just bear in mind that copy-pasting or entering a one-time passcode from an email or SMS can be a source of friction. If you're interested in learning more about SMS OTP form best practices then you can check out AGES Talk. Thanks Ellie. Okay one really important extra thing. Now testing usability and performance locally you know from your desk with your colleagues can be helpful but you need real-world data to properly understand how your users experience your payment and address forms and for that you need analytics and real user measurement. I mean getting data for the experience of actual users such as how long pages take to load or how long payment takes to complete. For your checkout forms you need to monitor page analytics but page views bounce rates exits and so on. Make sure to add interaction analytics such as goal funnels where the users abandon your checkout flow and for events like what actions do users take when they're interacting with your forms. And lastly track website performance for your users you know are your checkout pages slow to load and if so what's the cause. Well our web vitals documentation explains how you can access real user performance data for core metrics. Now page analytics and interaction analytics and real user performance measurement become especially valuable when combined with server logs conversion data and A-B testing. Yeah it means you can answer questions such as whether discount codes increase revenue or whether a change in form layout improves conversions and that gives you a solid basis for prioritizing effort and making changes. Thanks Sam. Testing usability and performance is incredibly important so I appreciate you covering that. That covers some of the basics for payment and address form best practices. To find out more you can take a look at the article on web.dev that goes with this video. It has lots more tips and links to lots of other really useful resources. And we also have a code lab where you can try out the stuff we talked about in the video. Thanks for watching. Yeah thanks for watching.