Viewers: in countries Watching now:
In this course, interaction designer Luke Wroblewski shows how to create web forms that encourage visitors to enter information and covers ways to capture input without the use of forms. The course covers boosting conversion rates and customer satisfaction, organizing the structure of forms, aligning and grouping form elements, assigning the correct input field types, validating input, and handling data entry errors. The last chapter highlights alternatives to static forms, such as using dynamic inline forms, using web services, and leveraging device capabilities, which can be used to gather additional information or replace a traditional form altogether.
At this point we have looked at why web forms matter, talked about how to organize them by looking at labels, whether we divide them across multiple pages, single pages, and even the structure. We have also looked at form interactions, that is the back and forth between our customers and our service through web forms. But now we've got another topic ahead of us, which is actually moving beyond static web forms. That's right, while all the best practices about Labels, Input Fields, Actions and Layout we discussed, will go a long way to boosting conversion. There are a lot of different opportunities for gathering input that don't actually involve web forms.
Let's start off by looking at one called Inline Validation. Inline Validation is a relatively simple technique, what basically means is giving people feedback as they provide information, that is not waiting till later. So when I'm trying to find the username here on Tweeter and I enter jim, I get instant feedback that that's taken. When I tried jimbo, same story, finally getting the jimbones, the form tells me that that's available and I can move on. Note that I don't actually have to go through the form, submit everything and then click the button to get feedback, it's happening right there inline.
Another example of Inline Validation that we can turn to is around creating a Password. Here, the Inline Validation is more about the validity of the input, that is how good it is, versus whether it's available or not. So if the Password we have got a couple of constraints, and you can see as I enter a password the little Password strength meter down to the right moves from red to yellow and ultimately if I kept going, to green. Now there is some debate about whether or not this is a great technique, because it can actually lead to passwords that are little bit too strong, that is, we might not remember what they are, but the idea of having a meter that tells you how good your input is, is another example of Inline Validation in action.
And we can see that illustrated in this sequence here. You will note that the meter again on the right moves along as your password changes. Now let's look at the rest of the form where this Password meter comes from? Note that I've moved it all the way to the right and got a real strong password. Then I've been asked to repeat it. Let's hope I got it right. Looking at the security questions they asked me next I've selected my Favorite Teacher, which quite easily is Edna. Going further down, I am asked for my First Name, Last Name and Birth date. Here I am going to put 2020, because frankly, why do they need my birth date, just to register? Rest of the form looks pretty common, including the Captcha and Terms and Service.
So I'll click Accept. What happened, well, looks like I got my grayed back and it turns out that strong password I put in there, doesn't match the one I put in next, that is, I forgot how I got it all the way to strong, and when I tried to repeat it, I didn't do a very good job. Then I see that my favorite teacher can't actually be Edna, because her name isn't five characters long, and last but not least, my Birth date is not valid. Please verify that I've entered the correct date. This is what a lot of form interactions look like, that is we do our best to fill things in, we click Submit, and then we get back a score card, how we got graded.
In this case I've failed a bunch. Let's look at how inline validation differs. Here on the Yahoo! registration form, similar situation, but very different interactions. As I actually go in and fill in my First Name and Last Name, you will note a little green tick mark shows up to the right. This lets me know I'm on the right track as I fill in the form. I go through Gender, same thing. Okay, you have supplied a valid answer. Now we are back to Birth date and remember I really don't like providing the right information here, so I am going to once again go with 2020.
Moving on to where I live, you will note that an error message pops up right there asking me if I'm really from the future. Clearly I am not, they caught me, and I've put in the right information. Now as I go through Postal Code and make my way to select ID and Password you will note that a number of options just pop up for me using the First Name and Last Name I already entered. This is a great technique for managing situations where I may not know what's available, like what User Names are there. Moving on to Password, you can see I'm entering my password up here, and once again I decide to move that Password meter forward.
Now the password below that I had typed, can no longer match, so the form removes it, thereby preventing me from getting into an error state. It's a small detail, but an important one. Overall the Yahoo! form is doing a lot of Inline Validation as I complete the information. It's telling me what's valid, it's catching errors as I enter them, it's offering new suggestions, such as the user name, and it's helping me prevent error states by removing duplicative forms. Here is a little detail of how that animation happens on the right. You can see as my input is entered, I get a little spinner dialogue; it lets me know it's valid, and then it fades away.
Now there are a number of different ways of rendering Inline Validation and forms. So let's look at another example. Here on the Mint site I'm also asked for my E-Mail address but as soon as I enter the first character an error pops up, that is, that's not a valid email address. I know, I haven't even tried yet. Please give me a chance. Luckily, Mint redesigned and applied Inline Validation a little differently. Here we can see that now Mind waits until you are actually done filling in a question before they give you an answer through Inline Validation.
So once I enter brian and then move on, it gives me an error that hey, that's not an e-mail. But note, that when I type brian again in the Confirm E-Mail dialog, it says that's okay. This is because they're only checking to see if the two fields match, not to see if the second one is actually a valid e-mail address. With Password, we will see a similar situation, that is, I enter a Password at the top, match it on the bottom and then change the one above it. The two fields are both listed as okay, even though they don't match. So Mint really isn't doing its best to prevent errors from happening here.
Now you'll see that when I actually go through and enter an e-Mail address at the top, the Confirm e-Mail address won't match, because the two things aren't equal. I am showing all these details to illustrate one simple fact, which is Inline Validation is really into details, that is, the little nuances of how people interact between form fields actually matter a lot. We saw in the Yahoo! form that when I actually went through and removed or changed my password, the one below it went away as well. That is Yahoo! doesn't want me to get into an error state.
Now given we have to be concerned with all these little details when we do Inline Validation, is it really worth it? Can we just go with this traditional Submit and Page Refresh model of telling people what's wrong? Why put in all this extra effort to give people real time feedback as they are filling in a form? So once again, we did some testing to see what's going on here. We compared a traditional form, simple registration with a Page Submit and Refresh model, that is, somebody filled in all the information, they hit Submit, and the server came back with, here's where your errors are.
We then also built a model that used inline validation, which gave people real time feedback as they filled in the information, and we compared how people did. What we saw was that a 22% increase in completions on the Inline Validation model. We saw 31% increase in satisfaction scores, a decrease in completion times, decrease in the number of error made, and a decrease in the number of eye fixations. That is people took a lot less effort to visually parse the form than they did with the Page Submit and Refresh model.
All of these statistics were great. They were all turning in exactly the right direction in pretty significant ways. So yes, taking the time to do Inline Validation right, can really pay off, which begs a question, how do we do Inline Validation right? What are the design techniques and those details I've been talking about a lot that make the difference? Well, through our testing we tried to explore a number of these. One of the things we learned was that Inline Validation doesn't make sense everywhere. In particular, at the top part of our form where we are asking people for their Name, Email Address, Gender and Location.
We saw that only about 30% of people actually interacted with the little Inline Validation controls we put in the form and when we asked them about that, they said, well, I kind of saw that, but I wasn't sure, do you know if that's really my name. Of course we couldn't really know if it was their name, but just the fact that they started to think about it, brought up questions of, hmm, maybe this isn't the right technique. It also didn't prove very useful, because as I said only a small portion of people interacted with that Inline Validation control.
In the second half of the form, we are asking people to select the username and a password. Nearly 100% of people noticed the Inline Validation and interacted with it. This is because these questions really benefited from real-time feedback, that is, how do I know what usernames are available, how do I know what a valid password is? Giving people feedback in real-time help them to avoid error states in areas where they are uncertain of how to answer. So what this shows is that there are places where Inline Validation is really powerful and other places where it's kind of just okay.
The next question we want to talk about is when to show Inline Validation. As we saw of the Mint and Yahoo! examples, there are a couple of different techniques out there, and we tested a few of them. The first one we did was when somebody enters an answer and then moves on, we'll validate things after the fact. Give us an answer, then we will tell you how it did. The second technique we tried was actually validating things while people were answering. So as they start to enter field we are immediately providing them feedback. This is most noticeable in the e-Mail Address field below.
Here tony is not a valid email address, neither is tony@, but email@example.com is, so they get a correct validation. Down on the bottom, we tested the technique we saw on the first Mint form, that is, as soon as somebody enters some data, we tell them they're wrong, until proven otherwise. This is sort of the guilty until innocent model. You don't have it right until you finish up, again, most noticeable in the e-Mail address field. So what do we learn when we try these three different models? First of all the highest success rates, lowest number errors and just general all good metrics happen with the after model.
When we waited until we gave somebody a chance to answer, and then told them how well they did, that worked the best across-the-board. The second technique proved to be good around a number of key metrics, except for speed. Here, people were 7-10 seconds slower on this simple form, which is quite substantial, and what we saw happen, was as soon as people noticed the Inline Validation was happening while they were entering their inputs, they would enter a letter, check to see how they did, enter another letter, check to see how they did, which really slowed them down.
Again, 10 seconds is quite a lot. The before model in contrast was actually really frustrating for people. That is they didn't react well to being grayed before even being given a chance to answer a question. As soon as they saw red flashing and they got frustrated, they weren't even given a chance to answer. Now with that said, there are places where validating while makes a lot of sense, in particular in User IDs. You don't know what User IDs are available. So giving people a chance to type a character, see if it's available, type up character, see if it's available, goes a long way.
You can see this in action in the User ID field at the top. Similar thing with Password. People don't know necessarily what a valid password is. So giving them feedback while they are entering their input makes a lot of sense. The next thing that we looked at in the form was how to show Inline Validation. So we talked about where Inline Validation makes sense, we talked about when to actually surface it, but how do we represent it on the form? Again, we tried a number of different variations. The first one, we represented a validation check mark to the right of the form field, as people move throughout the form, that went away.
In the second instance, we went through and did a similar placement, but we kept the validation checkmark visible even after they moved on. And in the third one we tried to put the validation checkmark inside of the text field. The thinking here was, closer proximity and making it part of the answer. We also kept this visible throughout the process. So what did we learn? We saw, which in retrospect is somewhat obvious that many people are "hunt and peck" typists. That is they look down at their keyboard to provide input and aren't always staring at their screen.
They are not touch typists. So using a model of showing a validation checkmark and then fading away, didn't give these "hunt and peck" typists a chance to actually see their answers were right. The persistent messages really supported both, "check as you go" and "check after strategies." That is, someone looking at the screen would see it, and someone that was looking down and looked back up would also see it. The approach of placing that validation message inside the input field didn't gain any noticeable benefits. In fact, it was actually harder for some people to find.
So when we talk about how to show Inline Validation, usually a persistent marker that sticks around after someone completes an input field is a good way to go. Where Inline Validation gets really exciting though is not just in terms of telling people that hey, you entered a valid name or a valid e-mail address. There are ways that we can use Inline Validation to suggest what could be a right answer. On the Kayak site, which is a travel booking form, you will see that as I enter the first few letters of Chicago, I am given the option to select the right airport code.
I may not know that's ORD, but really quickly I can jump down the menu and find it. The other interesting thing that happens on the Kayak form is that after I select the right airport, you'll note that the message on the right actually changes to a series of options. Here, I can just postpone going to the rest of the forms and jump right into a price point and date that makes sense to me. We are using inline validation, so that people don't actually have to go and fill in the rest of the form. One more great example of that comes to us from Yahoo! Answers. Yahoo! Answers is a service where human beings answer questions for each other.
In order to get people to good answers, it helps to ask a good question. Over the years that Yahoo! Answers has been live, the team has analyzed what makes a good question, and they've built an Inline Validation system that allows anybody to ask a great question. When you ask a great question, chances are much higher that somebody will answer it, leading to success on both sides. So when you start out with the Ask a Question form, there is a little message on the right that tells you how you can ask a good question. Let's say you ignore it and just write "growing carrots." The message at the right changes to say, hey, this is a little short, you might want to be more descriptive.
Again, the data has shown that when titles run below a certain character count, they are much less likely to get a quality answer. If someone chooses to continue without lengthening their question, it can actually trigger an error state, which says, hey, the question actually needs to be at least 20 characters long. So at this point someone will go in there and just pile in a bunch of question marks (?) and punctuation, to which we can respond, woo, you used too much punctuation, try revising your question. At this point someone gets really angry and goes to all caps HOW DO I GROW CARRORTS? Once again we can respond by saying, hey, did you leave the Caps Lock key on.
You really don't want to yell at people if you are asking for their help in answering this question. Finally, we get down to a real question. How do I grow carrots? And this is where the magic happens. Because there are over a billion resolved question-and-answer pairs on Yahoo! Answers, we already have an answer to this question. So you can ignore the next couple of pages of the form, and you will note on the right, the little spinner dialog pops up, and tada, there are the answers you're looking for. Inline Validation works as a system on Yahoo! Answers and you can see a number of their pieces here From Tips to Messages to Errors, even to Misspelling Corrections. The Yahoo! Answers' inline communication gives you real time feedback about how good the question you're asking is, so that you can get real answers real fast.
We can use Inline Validation for more than just verifying correct answers and helping people with formatting. Inline Validation can also help communicate limits. If you see in this example there are 1000 characters available for a message. As someone actually enters their message, we can count down the number of characters left, thereby providing them with real-time feedback around how good their input actually is. If we go over the limit, this toggle changes to let you know that you've passed what's possible. Wrapping up on Inline Validation: Generally we want to use inline validation for areas where people can struggle, that is where they may not know what a valid answer is, or they may not know the set of options available for them when they're actually picking an answer.
We can also use Inline Validation to disambiguate, that is to give people suggestions of what a valid answer can be, and as we just saw of the characters left example, is also a great technique for communicating limits, keeping people within boundaries. In each of these cases, we are using real-time feedback to turn web forms into more of a conversation.
There are currently no FAQs about Web Form Design Best Practices.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.