Video: Unnecessary inputsEvery question we ask people on a web form requires them A) to understand what the question is B) think about how they're going to respond to it and then 3) put in their answer in the affordance we've provided for them. That's a lot of thinking for every single question we ask. As a result it makes a lot of sense to be very vigilant about everything we're putting in front of people. As I mentioned earlier in talking about form length, asking ourselves, Can this question be removed? Can this question be postponed? Or, can it be inferred based on information we already know? In other words, what are the ways we can really cut down on unnecessary inputs.
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.
- Understanding why forms matter
- Deciding on the form length and structure
- Adding tabs to a form
- Creating required fields
- Adding input masks
- Creating selection-dependent inputs and actions
- Displaying success and error messages
- Adding inline validation
- Understanding gradual engagement
- Enabling touch and audio input on devices
Every question we ask people on a web form requires them A) to understand what the question is B) think about how they're going to respond to it and then 3) put in their answer in the affordance we've provided for them. That's a lot of thinking for every single question we ask. As a result it makes a lot of sense to be very vigilant about everything we're putting in front of people. As I mentioned earlier in talking about form length, asking ourselves, Can this question be removed? Can this question be postponed? Or, can it be inferred based on information we already know? In other words, what are the ways we can really cut down on unnecessary inputs.
There are some obvious examples, but there are also a few that take a little bit of thought, but the benefits can be really big. So let's look at an example from eBay's original registration form. This was pre-2004 so around 2003 and when somebody actually signed up to use eBay to either buy or sell something of interest to them they were asked a series of questions. Some of these questions were pretty standard like your email address, your full name, not that confusing. But right after that information was a series of questions titled optional that asked you, how did you hear about eBay? Not too bad.
What's your date of birth? Why did you need to know that? Annual Household Income? Hold on a second, why is this information necessary for me to join eBay? Even though the section was labeled optional information at the top, it's still crept people out. In fact, this was a key point of drop-off in this registration form. So what the team did when they actually redesign the eBay registration process as they took these unnecessary inputs and they ask them after someone had already registered. This change of context around these questions actually dramatically increased the percent of people who have filled these in.
If thought the thinking probably would something like this okay, I've registered now you're asking me for a little bit of additional information I'm happy to help out, or, ooo this looks a little bit like the survey. When the same questions were asked in the actual registration form they felt intrusive and out of place. I'd need to know my household income if all I'm trying to do is buy a laser pointer on eBay. So unnecessary inputs can be dictated by context, but they can also be dictated by things that we can infer. There as an example, let's look at a pretty standard payment form, this one comes from PayPal and here they're asking me for my billing information associated with the credit card.
So it makes sense to ask, what credit card I'd be paying with, right? You can note that the third input field is card type, I can pick MasterCard, Visa, American Express. Yet, it really turns out that this is an unnecessary input and it's not one that's glaringly obvious at first sight, but in the redesigned PayPal form you'll note that they put this payment type information after the credit card number, because based on the credit card number that you enter, they can actually tell what credit card you're using. It's not necessary for them to ask you to specify what credit card type you're paying with.
They know a credit card that's starts with 5 is a MasterCard. This example has been applied to other places and it's worth noting some of the usability details that come along with this type of solution. On Apple, they're actually doing something that I consider to be a no-no. What happens here is they put the pictures of the card that they support before they ask you for the number. So people when they see these images are quite inclined to actually click on one of them to select the type of card, they see it as a question, even though it's simply series of images.
Now when you enter your actual credit card number the appropriate card number highlights. Much better to manage it like this, where the credit card number is the first field you ask, then use that inferred information to highlight the one below it, thereby making that section really look like a label as opposed to an input field. In other words, which card have you paid with? Now little shortcuts like this of removing input fields can actually go a long way on mobile device as well. As I have mentioned earlier the constraints of mobile are a lot tighter, screens are smaller, inputs a little bit harder, so every little detail we use to make things simpler and easier on mobile and to eliminate errors goes a really long way.
You note the same pattern on a very small screen form here on this Railways site. As you enter a credit card type, it boiled it down to Visa. Card that's starts with 42 can only be a Visa card. Now on more advanced mobile devices here we're looking at a pretty basic feature phone running this form, but a device like the iPhone can do a lot more. So the native iPhone application for the payment service square, this is how credit card information is requested. Your first step is to actually enter a credit card number and you'll note, the icon to the right of the sample number is a generic credit card.
As you actually enter your credit card number that graphic changes to represent the card you're using to pay. In this case let's switch to Visa. Now the same input field here is actually shifted a bit to allow you to enter your month, year, and zip code, but we'll save that topic for input masks later. Now it maybe tempting to start looking for unnecessary inputs all over the place and while the credit card example we looked at is a great model of something we can infer and don't really need to force people to take the time to consider what we're asking to formulate an answer and then to input it.
There is other places where we maybe a little over zealous about removing requirements. Take for example from the same Apple checkout form the idea of simply asking for a ZIP code to infer a City and State. Here when somebody enters a ZIP code a little drop-down menu pops up that says oh, you're in San Jose, California. Now the reason they have a drop-down menu is some ZIP code they are associate with more than one city and state combination, so it's necessarily sometimes for you to pick. This doesn't seem like a very big deal, but when you look at the same implementation on Weber's checkout form, you notice something interesting.
As an interface designer, I'm generally tuned to areas of usability problems and where I can see a usability problem in the making or usually in existence is where I see a bunch of help text. The more help text, the bigger the problem tends to be. If that help text is red probably an even bigger problem. If that help text is big, red, and bold usually a sign of a severe issue inside a form or any other kind of web interaction. So here on the Weber checkout form you'll note that there is a whole block of text explaining how this feature of entering the ZIP code and getting your city and address works.
I've expelled out after entering your zip code above you must select click to highlight your city state combination from the left, after selection it will autofill display in the category below. Man, it's a lot of work. Most people know the city and state they either living, or they're shipping something to and in fact entering that is pretty simple. This solution seems to make them think an awful lot as indicated by the amount of help text they have decided they need to work people through it. So it tried to be a quicker solution by removing city and state as input fields actually turns out to be something a bit more complicated.
And the lesson here really on not necessary inputs is, don't just remove things for the sake of removing things, because sometimes that complicate stuff. Really look for opportunities where unnecessary inputs make things easier and streamline the process as we saw with the credit card example. Anywhere you're able to remove the need for people to see a question, parse it, formulate an answer, input their answer; you've cut down not only in the time, but on the mental load they needed to think through your form.
There are currently no FAQs about Web Form Design Best Practices.