Payment and address form best practices

(upbeat music) - Have you ever gone to a website to buy something and 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 auto-fill 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.

00:58 - - Checkout and payment design can make or break a business. One small fix through 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.

01:25 - 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.

02:06 - 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 disabled 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.

02:48 - 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 the browser. No JavaScript required. So use input type=“email” for email and type=“tel” for telephone numbers. Ah, but watch out. Using type=“number” adds an up/down arrow to increment numbers and that makes no sense at all for data like credit card numbers or pin numbers. So instead you should specify inputmode=“numeric” to get a numeric keyboard on mobile.

03:27 - Some sites you used to use this like type=“tel” for credit cards to get the right keyboard. Inputmode is widely supported now so don’t do that. Just use the default input type value, which is text. In the examples here, I’ve actually said 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 autofilling 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.

04:27 - You associate a label with an input by giving the labels for attributes the same value as the input’s ID. On your address forms, use a single label for a single input and don’t try to label multiple inputs. A tap or 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 focused. - [Screen Reader] Sign in, Heading 1, Email with a hint. - Placeholders can be useful, but 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’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.

05:23 - Button elements provide accessible behavior and built-in functionality for form submission. And you can also use input type=“submit” 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.

05:50 - 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, don’t just leave a make payment button disabled or if something is missing or invalid in an address form. 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. 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.

06:29 - 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 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.

07:20 - 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.

07:50 - First of all, for an online store, you can reduce friction by making guest 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 checkout 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.

08:43 - 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 distraction such as product promotions in the checkout step. Many successful retailers even remove navigation and such functionality at this step. Keep the journey focused.

09:17 - 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.

09:51 - 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 progress towards conversion. - Okay, thanks for that, Ali. I particularly liked the advice about offering guest checkout.

10:20 - 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 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 allowing a user to find their nearest store, let them use their zip or postal code or whatever. Anyway, first up name inputs.

10:58 - 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 colleagues Surma. His name is Surma not Surma Surma, not Herr Surma, just Surma. Anyway, use a single name input. And that also makes cut and paste and autofill simpler.

11:29 - Also, unless you have a good reason not to, don’t bother adding a separate input for a prefix or title like Mrs. or Dr. 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.

12:02 - And that’s pretty rude to get told your name is 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 your backend must support that securely, as both input and as output. Now, when you’re designing an address form, bear in mind the bewildering variety of address formats even within a single country.

12:37 - Be careful not to make assumptions about 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 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.

13:13 - 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 autofill 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 reenter the same data. Of course the billing address may be different from the shipping address.

13:57 - 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 and UK addresses have a county. Well, mostly, actually mine doesn’t, but anyway, you know the deal. But 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 videos, but just 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.

14:58 - 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 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 it can be way more than that. And it’s really fiddly for users.

15:35 - If they have to select from a long list of addresses and then you can still get it wrong. It can just be quicker and less error prone to let users take advantage of autofill. That way they can get that 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.

16:06 - 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 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.

16:45 - It makes it easier for users to fill in the data and 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.

17:16 - 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 CodeLab 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 security 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.

17:59 - If you’re interested in learning more about SMS OTP form best practices, then you can check out AJ’s talk. - Thanks, Ali. Okay. One really important extra thing. Now testing usability and performance locally, from your desk or 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 for page views, bounce rates, exits, and so on.

18:43 - 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. 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 AB testing. That means you can answer questions such as whether discount codes increase revenue or whether a change in form layout improves conversions.

19:31 - 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.

19:56 - - And we also have a CodeLab where you can try out the stuff we talked about in the video. - Thanks for watching. - Yeah. Thanks for watching. (upbeat music) .