is a blog about design, technology and culture written by Khoi Vinh, and has been more or less continuously published since December 2000 in New York City. Khoi is currently Principal Designer at Adobe. Previously, Khoi was co-founder and CEO of Mixel (acquired in 2013), Design Director of The New York Times Online, and co-founder of the design studio Behavior, LLC. He is the author of “How They Got There: Interviews with Digital Designers About Their Careers”and “Ordering Disorder: Grid Principles for Web Design,” and was named one of Fast Company’s “fifty most influential designers in America.” Khoi lives in Crown Heights, Brooklyn with his wife and three children.
Clearly, they’ll have to come up with a sexier title than that if they ever adapt the book into a major motion picture, but at least it makes no bones as to what it’s about: designing highly intuitive and efficient forms for capturing user inputs on the Web. You can get a kind of preview of the content over at his blog, where this one essay on optimizing sign-up forms for wireless networks will teach you more about the art of interaction design than most courses will teach you in a year.
Listen Up, It’s Forms
And no wonder. I consider Wroblewski one of the smartest practitioners in the business, so I’ll pretty much read anything he has to say on any kind of interaction design subject. Even if the topic is forms, which is something that will likely put most people to sleep, but that I happen to really adore. (By coincidence, Afshan Kirmani also published an article on the subject at Boxes and Arrows last week.)
In fact, I think it was really the ‘dry’ stuff like forms, tables and charts that first got me interested in the less-subjective aspects of this craft, and made it much more interesting for me. Beyond the aesthetic, emotional dimension that rightly defines so much of what we call design, I realized that it was very often these deceptively boring aspects that deliver the most meaning to an audience. Web forms, in particular, are the principal gateway through which the majority of a user’s information gets into a system — a kind of interface lifeline, if you will, that deepens interaction and that, as it happens, often delivers the actual revenue to an online business.
The Beauty of Boring
Still, I apply a kind of aesthete’s eye to these ostensibly objective elements. I have a soft spot in my heart for exceptionally beautiful forms, which is part of the reason I made my now-stalled effort to create a library of reliable forms-rendering markup and CSS called The Subtraction Good Form. (I haven’t touched it in a while.) Additionally, I take some pride in the simple but, I think, aesthetically pleasing nature of the comment form on Subtraction.com (at the bottom of this page), as well as this membership application that I designed for the writers’ workspace Paragraph.
Probably the best Web-based forms I’ve ever seen, though, are the ones designed for Mint by Shaun Inman. They’re as aesthetically airtight as a bathysphere, with their delicate strokes and pixel-perfect alignment. Gorgeous.
I haven’t yet read Wroblewski’s book, so I don’t know if he addresses these more superficial aspects of form design. In fact, you could argue that emphasizing beautiful forms can often run counter to accepted best practices for efficiency and usability. That tends to go back to the age-old argument that beauty and functionality are mutually exclusive, but personally I don’t buy that. Forms can be eminently usable and visually pleasing at once.
New Breakthrough in Forms
As an aside, here’s a form that I came across today that isn’t particularly beautiful, admittedly, but still quite ingenious. It’s a credit card payment form, the likes of which any casual Internet consumer has come across dozens and dozens of times. It’s not the kind of common Web element that you would assume could offer even a little bit of delightful innovation, but somehow PayPal, who are responsible for this one, managed to pull off something unexpectedly good.
The first stage of the form is very standard. But you’ll notice there’s no apparent way for the user to actually specify whether the card they’ll be using is a Visa, MasterCard or American Express, etc. Usually a pull-down menu or a set of radio buttons is provided for the user to indicate the card they’re using, but here only the logos of those cards are displayed, with no indication that a user should interact with them.
In fact, I’ve always wondered why a pull-down menu or radio buttons was necessary to identify card types at all. The very first digit of any credit card already indicates what kind of card it is. If you’ve got a card that starts with a 3 then it’s an American Express; with a 4 then it’s a Visa; with a 5 then it’s a MasterCard. By simply entering the number, the system should be able to discern that information automagically. To my knowledge, there’s no value in asking the user to identify the kind of card they’re using if they’re already entering the card number anyway.
In fact, the way PayPal has done it, users only need to start entering the card number in order for the form to recognize the card type. Only the first digit is required before the form immediately acknowledges that it understands that information by cleverly dimming the logos for the other card types — no user submission is required. The form just knows. It’s simple and, technologically speaking, not particularly complex or even impressive. But it’s also really, really smart, the kind of subtle but powerful feedback that makes all the difference in form — and interaction — design.
I once asked someone who was requiring users to manually select the type of credit card they were using why they did that (given, as you note, that you can deduce it form the first diit of the card number). He gave methe following answer: security.
See, not everyone knows that the first digit of the number indicates the card type. So, if you stolen my credit card number, you’d know it was a MasterCard because it starts with a “5” — but someone else might not. Asking them to manually select MasterCard is one more check that helps ensure they actually have the card in-hand.
Now, I’m not sure what I think of this. To me, this seems like pretty common knowledge, and I would think it’s especially common knowledge to the type of person who’d steal credit card number. But, still — at least he had an answer.
Hmmm. Jeff, we know each other and I hope you know that I respect the hell out of you. But can I politely suggest that the batteries in your bullshit detector may have been low that day? I just don’t buy it.
Haha. Well, like I said, I wasn’t totally buying it, either. But, when i asked, I honestly expected him to have never even considered parsing the number and getting the type from that — so I was relived to hear he’d at least thought through the problem and had a reason for the decision he made.
I love the description of exceptionally good design as “aesthetically airtight as a bathysphere.”
Thanks for the link Khoi, Wroblewski is good, I can’t wait to check the book out.
ToddG
Also baffling in credit card forms — the ones (most in my experience) that don’t let you use spaces in the number. 1234 5678 9123 567. It’s even on the card like that! Sigh… apparently some programmers don’t know how to strip whitespace before validating numbers…
Wroblewski’s lecture regarding web forms at An Event Apart Chicago was fascinating. Seems to be one of those niche design aspects that makes a humongoid difference in the joy of using a website. I’m glad to see topics such as these rising amongst us.
In addition to checking the first number of a card, you can also do a checksum on the entire number to see if it is a valid number sequence for that card type.
I haven’t seen it in any immediate feedback element yet (as in your Paypal example), but it certainly could be used in a similar way to head off incorrectly typed numbers.
My theory: Once upon a time a lazy computer programmer decided that forcing the user to choose the card type in the form was easier than writing one line of code to translate the first digit into a card type. Millions of lazy programmers and lazy information architects/UI designers have followed suit ever since.
So many hamfisted UI designs are directly attributable to laziness: initially it’s a programmer’s laziness, and later it’s lazy UI designers who simply repeat the designs that already exist without questioning why.
The first time I saw the web forms book advertised, the listed publication date was “Summer 2008” – but now it says “early 2008”. Either way, that’s too long! I need this damned thing now.
I’ve always wondered something similar to the first number of the CC issue: if you ask for a zip-code, why ask for city or state? Isn’t city and state implicit in zip? Shouldn’t a zip code + street address be entirely sufficient?
I’m playing Devil’s Advocate here — I generally agree that card type fields should not exist, and city/state fields probably shouldn’t either, if there is a zip field.
But, to play the other side…there is something to be said for the Python programmers mantra of “explict is better than implicit.” If you removed the city/state fields, you would almost certainly end up with more incorrect submissions by users. Why? Because you can’t validate them aganist each other. If you ask for both, you can confirm that the zip they’ve entered matches the city and/or state they’ve entered. You’re doing the user a favor by double-checking for them.
In removing the city/state fields, you’d improve the user experience in filling out the form, but you’d potentially harm the user experience after filling out the form — i.e., when the item they ordered is shipped to the wrong zip code. Which is more important?
I’d learn towards removing the city/state, but it is a more interesting question than it initialy appears to be.
“In removing the city/state fields, you’d improve the user experience in filling out the form, but you’d potentially harm the user experience after filling out the form — i.e., when the item they ordered is shipped to the wrong zip code. Which is more important?”
I’ll take the bait Jeff 😉
Is there any reason not to simply display the city / state that has been inferred from the ZIP code, prior to completing the order?
This could be a nice bit of unobtrusive JS that provides a form of inline validation, and / or a confirmation screen (which most checkout processes include as standard anyway).
Either way, the user will have the opportunity to confirm that their purchase is indeed heading to Nevada, not Alaska.
I like the idea of auto-selecting the credit card type, but I see two problems with that PayPal form. First of all, Khoi, weren’t you a little thrown off by the unnecessary whitespace between the credit card number field and the card images?
Second, I think setting them up on their own line in a row with a label that is like the other input labels is a bad idea: “Wait, why does this look like the other fields? Do I click on one of these?” It would be better, I think, to show the card type image to the right of the number input field, and keep it invisible until after the user had begun typing a number.
What do you think? I can draw up a prototype if my description wasn’t clear enough.
Matthew: You’re right, that extra white space doesn’t help much. As I said, it’s not an oil painting of a form, for sure.
I also understand what you mean about having the credit card icon appear to the right of the number field. That’s a good idea. I guess the one drawback to that is that you’d lose the opportunity to visually communicate what cards the form will accept. So in that sense that row of cards is doing double-duty.
One thing Mr. Wroblewski talked about at AEA (and I’m sure this will make an appearance in the book) is when most form fields are required, instead indicate which forms are optional. I think the Mint form could definitely benefit from this approach. All those green flags are distracting and don’t allow my eye to rest.
Zip codes don’t map one-to-one with cities. There are zip codes that span multiple cities (and multiple counties) where those cities also have additional zip codes.
One of my acquaintances lived in a zip code that spanned 3 cities.
You’d need to provide additional UI to sort these cases out, which might not be worth it vs. just taking the CSZ info all at once from the user.
Also, it costs money to subscribe to a zip code update service. Possibly not a lot of money (I haven’t checked, though we do have a zip database), but again, more than just taking the 3 fields as-is.
I haven’t looked into this to see whether it is the case or not, but could it be the case that it’s best to ask the user for their card type because banks may have different numbering schemes in different countries. So to accurately match an entry against a pattern would first require the user to state where they live, as PayPal did in the above example.
@Beth: I’ve become a believer in using optional markings instead of required markings. In user tests we found that everyone assumed all form fields to be required unless they were otherwise marked.
After listening to Luke speak on the subject at AEA Chicago last month I can say I am equally impressed with him. Prior to him beginning I was skeptical that anyone would be able to speak to form design for an hour and not put the >500 attendees to sleep. He not only managed this daunting task but actually made the subject interesting.
And while I agree that Mr. Inman’s skill at design skills are tight and his forms are excellent, I see something in the grab you posted that brings to mind one thing I learned from Luke that day, if every field is required there is no need to have a required note beside each field just make mention of it at the start.
A small thing to be sure, but an excellent opportunity to show that I was in fact paying attention.
heh.
Scott
I worked for VeriSign Payment Services and I did this in our Manager application (for Transaction Terminal, which was renamed Virtual Terminal) well before we were bought by PayPal. I think we eventually carried it to PayflowLink, although I’m not sure since I didn’t personally do it there.
It was a bit of a controversial move at the time, but it made total sense to me. The main argument against it is if your terminal is going to accept private label cards that don’t necessarily follow the bin range rules that majors do.
Craig Welch
“I haven’t looked into this to see whether it is the case or not, but could it be the case that it’s best to ask the user for their card type because banks may have different numbering schemes in different countries”.
No.
“Is there any reason not to simply display the city / state that has been inferred from the ZIP code, prior to completing the order?”
Yes.
Not all countries have zip codes. Not all zip codes are in the same format. It’s not possible to keep a current database that covers all countries’ zip codes.
Stevie D
Craig:
if you ask for a zip-code, why ask for city or state? Isn’t city and state implicit in zip? Shouldn’t a zip code + street address be entirely sufficient?
Firstly, that only applies if you’ve already ascertained that the customer is resident in the USA. In the UK, a postcode will give you precision down to one street, or sometimes one part of a street. For example, I could unambiguously give my address as “28, YO9 9XX, UK” (except that that isn’t my actual address). I don’t need a street name or town at all. Different countries have different systems, and for most web applications, it would be an inordinate amount of work to cope with them all.
Second, redundant information is important. It’s the same reason that you are often asked to retype an email address or password; it enables a check that you have got it right the first time. A zip code or postcode is a pretty arbitrary way to present an address, and it’s likely that people will get it wrong from time to time. But if one digit is wrong, your mail could end up on the wrong side of the country. With a street, city and state, even if you have misspelled them, it’s likely that the postal service will be able to figure out what you meant.
Third, more advanced sites – in the UK at least – offer something even better. You type in your house/flat number and postcode, and it will look up the complete address in the Post Office database, and then ask you to confirm Yes/No that it is correct. This reduces the burden on users to type in lots of information and gives them the opportunity to check and correct any mistakes.
steve
For what it’s worth, the Mint forms are far from Shaun Inman’s best design work, and they’re hardly an example of “pixel-perfect alignment.” The borders around each input are visually noisy and bump against the right side; the border around the checkbox is at least a pixel too tall or too short, and the label sits well above the center of the checkbox; every field is required, so the individual “Required” flags are overkill; the parenthetical disclaimer needs different/less visual weight than the labels; the purpose of the “Current Date & Time” dropdown should be spelled out (i.e., to set the time zone); and the input text is rather small and would be more readable with some padding.
I think 37signals’ work is a far better example of best practices for forms — this Basecamp form being a good example.
Rob F
The views expressed here are all logical but betray a very simplistic understanding of the availability and use of BIN data.
Whether full issuer by issuer and country by country ranges, or simply the bounds of each card type, it is commercially sensitive data!
Sure you could ‘stumble upon’ the latter data quite easily via Google, but some developers quite rightly will not trust unofficial data.
BIN ranges are growing and card schemes will only release the up to date numbers to Tier 1 acquiring banks (not Joe Web Developer).
Officially (it took me 2 years of chasing Visa on this) it is up to the acquiring banks if they wish to then share this with Merchants.
Some acquirers do, some won’t, many certainly won’t provide it with sufficient updates to ensure a developer has wholly accurate data.
I have spoken to countless web developers who use this data to know that I could introduce a bogus BIN range document, get it up the Google rankings and ruin forms that assume the type!
Although I agree that credit card form design is un-inventive and assumes the status quo is right just because it exists, don’t assume this field is simply about lazy me-too development.
Try telling a non tech savvy website owner you had duff BIN data when he balls you out for a good clients payment being rejected because your form submitted his transaction as Visa credit when it was Visa Debit or Electron. I’ve seen this happen and would excuse any developer from taking the safety first approach.
One thing I can say for certain – a Luhn / Mod 10 check in jS is quite sensible, but anyone who is putting assumed BIN ranges into their jS is not only risking mistakes, but potentially making their client non-compliant in the eyes of Visa/MC over this data’s publication!
Rob F
@Jeff. Well I don’t think your bullshit filter failed as Khoi suggests! You’re absolutely right about why some people ask for card type as an extra layer of validation.
Although 3D Secure and CV2 are simpler and more effective these days, any extra questions are always healthy, there are still some older card forms that still ask who your issuer is too!
Some developers are lieing if they pretend the field exists because they’ve thought about it, but the answer you heard is still genuine and not just bullshit. Promise!
There is a general rule of thumb I’ve seen in payment processing and card scheme compliance that the less information you collect the higher risk you are. This is no different.
@Stevie D. You’re spot on – redundant info is important. Your example is useful, if only because the UK is the only country in the world where AVS (address validation) is compulsory if requested – so abstracting address information fields in web forms is a high risk business on any non-UK . And in any case AVS is risky altogether because it just checks numbers and is easily spoofed. If I gave my address without a postcode but as Room 1012, I could pass AVS for 10 Downing Street SW1A 2AA. I’d just need Gordon Brown’s credit card 🙂
@
Rob F
Sorry, not post-hogging but having re-read the blog while relating it to a colleague, I realise I should have added something far more fundamental and basic too, to this discussion.
It’s not enough to simply say ‘it begins with 4 it’s a Visa, 5 it’s MasterCard’. These schemes have a range of credit and debit subtypes which need to be identified too.
What PayPal have done is certainly not new and nor is it ingenious, changing the opacity of the logos as a result of the keyed data is neat but abstracting this field isn’t new.
The point is to draw these conclusions in the browser using jS is innaccurate and falible. 5 followed by all the zeros in the example isn’t even a valid card number let alone MasterCard.
To me, and I’m sure the card schemes, drawing this visual connection between their brand and potentially innaccurate data entry, is unhelpful and promotes confusion and concern.
I could key in a UK Maestro card which would light up Visa logo and International Maestro cards that would light up the MasterCard logo. But they would have neither logo on the card.
How is this ingenious? From a user point of view it would put me off making payment on an inaccurate form and from a business point of view it may mean submitting invalid payments.
Usability is hugely important but sacrificing valid user input and authentication just to look smart in the browser at the expense of accuracy is design for all the wrong reasons.
My view is that the achievement which you have rightly highlighted as desirable would only be valid and commendable if handled server-side using full and legitimate card scheme data.
Okay this adds a server request to the process (less pronounced with Ajax etc) but doing this in the browser is gimmicky and flawed and far from the ‘breakthrough’ you describe.
Rob: I am delighted you’ve put about 10,000 times the thought, energy and critical analysis into credit card forms that I have. I wish I had that kind of time on my hands.
As someone who has only applied a cursory look at the way these forms behave, I admit that my use of the word ‘breakthrough’ may have been inaccurate.
I think it’s good to have the form field there, and I like how PayPal has done it. The problem is that not all people know 3 = AMEX, 4=VISA, 5=MC so they’re looking for the option to select their credit card. If they don’t find it then they think they’re missing something.
I really like how PayPal does it, but I think the form field for credit card type has to be there.
If anyone is interested, Luke and I are actually proposing a joint presentation for SXSW next year (it’s in the panel picker). The session would be 1/2 theory and 1/2 practical application of that theory in code. It should be pretty interesting if we get the votes.
KJ
I’ve seen a few comments around the idea that visitors don’t know that the first digit of a card number = the credit card type. My question is… Why should they care? Customers don’t need to know that 4 = Visa, or 5 = MasterCard, we do.
When I walk into a store, all I want to know is that the credit card I plan to use is accepted at that store, not the technical details of how a credit card is identified.
My usual purchase process goes something like this:
1. I bring my stuff to the register
2. The cashier tells me the final price
3. I hand them (or swipe) my card
4. Payment processed
5. End of transaction
It doesn’t usually go like this:
1. I bring my stuff to the register
2. The cashier tells me the final price
3. Are you using Visa?
4. Are you using MasterCard?
5. Are you using American Express?
6. Are you using Discover?
7. I hand them (or swipe) my card
8. Payment processed
9. End of transaction
I’ll digress for a moment and say that they will occasionally ask me if I want to put it on *their* charge card, but that’s just a marketing gimmick to get you to sign up for their card. So why do we ask visitors what credit card they are using? As Khoi pointed it out, it’s certainly not for security.
I agree 100% with @Christopher Fahey:
My theory: Once upon a time a lazy computer programmer decided that forcing the user to choose the card type in the form was easier than writing one line of code to translate the first digit into a card type. Millions of lazy programmers and lazy information architects/UI designers have followed suit ever since.
I think that the credit card drop down box is a piece of legacy web development that has stuck around way past it’s time, if it ever had “a time”. We can totally obfuscate the entire credit card check/security process by adding a few, simple lines of code.
@ Khoi: You’re right about the invisible credit card images being a bad idea, and I think the solution is simply to move the existing ghosted credit card images up to the right of the number. That way they’d look follow the “row of logos” convention, functioning like the credit card sticker on a restaurant door. The correct credit card logo would become fully saturated once the user starts typing the number, making it clear they don’t need to make any further designations.
In the interest of further usability, some explanatory text might be helpful in this situation, as people generally aren’t accustomed to credit card type auto-selection. Something like: “Just start typing your credit card number; your credit card type will be selected automatically.” But that might not be enough to eliminate confusion (“Automatically? How does it do that!?”) so:
I see this as an analog to the “VIN” number that started being added to credit card forms a while back. At first it required special explanatory popups and the like, but now it’s more or less ubiquitous and understood. Maybe it wouldn’t be a bad idea to provide the same explanation for this functionality.
Another issue was brought up by my colleague Cody: If any of the underlying patterns ever changed, the validation would suddenly stop working and become incredibly confusing. He suggested talks with the credit card companies (to ensure correctness) would be the best way to avoid this potential issue. He also added that removing the credit card type field gets rid of another check against the user entering bad data, and that removing it could be potentially hazardous.
The lesson here, I think, is that any serious change in the established routines of design (credit card forms, in this case) need to be approached from a number of angles and the repercussions considered fully before moving forward.
Paulo
Personally, I think the winner here could be the solution of only showing a single image (invisible at first) which would show up upon verifying the card number and inferring the card type from it. But only, as Rob F pointed out, if the verification is strong and done server side (Ajax is a blessing for that, I think). Finally, right beside the card icon a small type link saying something like “(not this card type?)”, which when clicked would bring out an old fashioned way to pick out card type.
If you design Web pages with any kind of transactional component and you’re not paying attention to this, then you should: the talented interface designer 
I once asked someone who was requiring users to manually select the type of credit card they were using why they did that (given, as you note, that you can deduce it form the first diit of the card number). He gave methe following answer: security.
See, not everyone knows that the first digit of the number indicates the card type. So, if you stolen my credit card number, you’d know it was a MasterCard because it starts with a “5” — but someone else might not. Asking them to manually select MasterCard is one more check that helps ensure they actually have the card in-hand.
Now, I’m not sure what I think of this. To me, this seems like pretty common knowledge, and I would think it’s especially common knowledge to the type of person who’d steal credit card number. But, still — at least he had an answer.
Hmmm. Jeff, we know each other and I hope you know that I respect the hell out of you. But can I politely suggest that the batteries in your bullshit detector may have been low that day? I just don’t buy it.
I’m fairly certain that PayPal stole that design/idea/code straight from Google Checkout.
Haha. Well, like I said, I wasn’t totally buying it, either. But, when i asked, I honestly expected him to have never even considered parsing the number and getting the type from that — so I was relived to hear he’d at least thought through the problem and had a reason for the decision he made.
Whoaaa damn. Let the web form wars begin.
I love the description of exceptionally good design as “aesthetically airtight as a bathysphere.”
Thanks for the link Khoi, Wroblewski is good, I can’t wait to check the book out.
Also baffling in credit card forms — the ones (most in my experience) that don’t let you use spaces in the number. 1234 5678 9123 567. It’s even on the card like that! Sigh… apparently some programmers don’t know how to strip whitespace before validating numbers…
Wroblewski’s lecture regarding web forms at An Event Apart Chicago was fascinating. Seems to be one of those niche design aspects that makes a humongoid difference in the joy of using a website. I’m glad to see topics such as these rising amongst us.
In addition to checking the first number of a card, you can also do a checksum on the entire number to see if it is a valid number sequence for that card type.
I haven’t seen it in any immediate feedback element yet (as in your Paypal example), but it certainly could be used in a similar way to head off incorrectly typed numbers.
Why does the Credit Card Type field exist?
My theory: Once upon a time a lazy computer programmer decided that forcing the user to choose the card type in the form was easier than writing one line of code to translate the first digit into a card type. Millions of lazy programmers and lazy information architects/UI designers have followed suit ever since.
So many hamfisted UI designs are directly attributable to laziness: initially it’s a programmer’s laziness, and later it’s lazy UI designers who simply repeat the designs that already exist without questioning why.
The first time I saw the web forms book advertised, the listed publication date was “Summer 2008” – but now it says “early 2008”. Either way, that’s too long! I need this damned thing now.
Apple’s credit card form should have the image bounce and errors given with faux growl balloons.
I’ve always wondered something similar to the first number of the CC issue: if you ask for a zip-code, why ask for city or state? Isn’t city and state implicit in zip? Shouldn’t a zip code + street address be entirely sufficient?
I’m playing Devil’s Advocate here — I generally agree that card type fields should not exist, and city/state fields probably shouldn’t either, if there is a zip field.
But, to play the other side…there is something to be said for the Python programmers mantra of “explict is better than implicit.” If you removed the city/state fields, you would almost certainly end up with more incorrect submissions by users. Why? Because you can’t validate them aganist each other. If you ask for both, you can confirm that the zip they’ve entered matches the city and/or state they’ve entered. You’re doing the user a favor by double-checking for them.
In removing the city/state fields, you’d improve the user experience in filling out the form, but you’d potentially harm the user experience after filling out the form — i.e., when the item they ordered is shipped to the wrong zip code. Which is more important?
I’d learn towards removing the city/state, but it is a more interesting question than it initialy appears to be.
“In removing the city/state fields, you’d improve the user experience in filling out the form, but you’d potentially harm the user experience after filling out the form — i.e., when the item they ordered is shipped to the wrong zip code. Which is more important?”
I’ll take the bait Jeff 😉
Is there any reason not to simply display the city / state that has been inferred from the ZIP code, prior to completing the order?
This could be a nice bit of unobtrusive JS that provides a form of inline validation, and / or a confirmation screen (which most checkout processes include as standard anyway).
Either way, the user will have the opportunity to confirm that their purchase is indeed heading to Nevada, not Alaska.
I like the idea of auto-selecting the credit card type, but I see two problems with that PayPal form. First of all, Khoi, weren’t you a little thrown off by the unnecessary whitespace between the credit card number field and the card images?
Second, I think setting them up on their own line in a row with a label that is like the other input labels is a bad idea: “Wait, why does this look like the other fields? Do I click on one of these?” It would be better, I think, to show the card type image to the right of the number input field, and keep it invisible until after the user had begun typing a number.
What do you think? I can draw up a prototype if my description wasn’t clear enough.
Matthew: You’re right, that extra white space doesn’t help much. As I said, it’s not an oil painting of a form, for sure.
I also understand what you mean about having the credit card icon appear to the right of the number field. That’s a good idea. I guess the one drawback to that is that you’d lose the opportunity to visually communicate what cards the form will accept. So in that sense that row of cards is doing double-duty.
One thing Mr. Wroblewski talked about at AEA (and I’m sure this will make an appearance in the book) is when most form fields are required, instead indicate which forms are optional. I think the Mint form could definitely benefit from this approach. All those green flags are distracting and don’t allow my eye to rest.
Zip codes don’t map one-to-one with cities. There are zip codes that span multiple cities (and multiple counties) where those cities also have additional zip codes.
One of my acquaintances lived in a zip code that spanned 3 cities.
You’d need to provide additional UI to sort these cases out, which might not be worth it vs. just taking the CSZ info all at once from the user.
Also, it costs money to subscribe to a zip code update service. Possibly not a lot of money (I haven’t checked, though we do have a zip database), but again, more than just taking the 3 fields as-is.
@Stephen: That does, indeed, sound like an ideal solution. 🙂
@Adam: Good info! Thanks!
I haven’t looked into this to see whether it is the case or not, but could it be the case that it’s best to ask the user for their card type because banks may have different numbering schemes in different countries. So to accurately match an entry against a pattern would first require the user to state where they live, as PayPal did in the above example.
@Beth: I’ve become a believer in using optional markings instead of required markings. In user tests we found that everyone assumed all form fields to be required unless they were otherwise marked.
After listening to Luke speak on the subject at AEA Chicago last month I can say I am equally impressed with him. Prior to him beginning I was skeptical that anyone would be able to speak to form design for an hour and not put the >500 attendees to sleep. He not only managed this daunting task but actually made the subject interesting.
And while I agree that Mr. Inman’s skill at design skills are tight and his forms are excellent, I see something in the grab you posted that brings to mind one thing I learned from Luke that day, if every field is required there is no need to have a required note beside each field just make mention of it at the start.
A small thing to be sure, but an excellent opportunity to show that I was in fact paying attention.
heh.
I worked for VeriSign Payment Services and I did this in our Manager application (for Transaction Terminal, which was renamed Virtual Terminal) well before we were bought by PayPal. I think we eventually carried it to PayflowLink, although I’m not sure since I didn’t personally do it there.
It was a bit of a controversial move at the time, but it made total sense to me. The main argument against it is if your terminal is going to accept private label cards that don’t necessarily follow the bin range rules that majors do.
“I haven’t looked into this to see whether it is the case or not, but could it be the case that it’s best to ask the user for their card type because banks may have different numbering schemes in different countries”.
No.
“Is there any reason not to simply display the city / state that has been inferred from the ZIP code, prior to completing the order?”
Yes.
Not all countries have zip codes. Not all zip codes are in the same format. It’s not possible to keep a current database that covers all countries’ zip codes.
Craig:
Firstly, that only applies if you’ve already ascertained that the customer is resident in the USA. In the UK, a postcode will give you precision down to one street, or sometimes one part of a street. For example, I could unambiguously give my address as “28, YO9 9XX, UK” (except that that isn’t my actual address). I don’t need a street name or town at all. Different countries have different systems, and for most web applications, it would be an inordinate amount of work to cope with them all.
Second, redundant information is important. It’s the same reason that you are often asked to retype an email address or password; it enables a check that you have got it right the first time. A zip code or postcode is a pretty arbitrary way to present an address, and it’s likely that people will get it wrong from time to time. But if one digit is wrong, your mail could end up on the wrong side of the country. With a street, city and state, even if you have misspelled them, it’s likely that the postal service will be able to figure out what you meant.
Third, more advanced sites – in the UK at least – offer something even better. You type in your house/flat number and postcode, and it will look up the complete address in the Post Office database, and then ask you to confirm Yes/No that it is correct. This reduces the burden on users to type in lots of information and gives them the opportunity to check and correct any mistakes.
For what it’s worth, the Mint forms are far from Shaun Inman’s best design work, and they’re hardly an example of “pixel-perfect alignment.” The borders around each input are visually noisy and bump against the right side; the border around the checkbox is at least a pixel too tall or too short, and the label sits well above the center of the checkbox; every field is required, so the individual “Required” flags are overkill; the parenthetical disclaimer needs different/less visual weight than the labels; the purpose of the “Current Date & Time” dropdown should be spelled out (i.e., to set the time zone); and the input text is rather small and would be more readable with some padding.
I think 37signals’ work is a far better example of best practices for forms — this Basecamp form being a good example.
The views expressed here are all logical but betray a very simplistic understanding of the availability and use of BIN data.
Whether full issuer by issuer and country by country ranges, or simply the bounds of each card type, it is commercially sensitive data!
Sure you could ‘stumble upon’ the latter data quite easily via Google, but some developers quite rightly will not trust unofficial data.
BIN ranges are growing and card schemes will only release the up to date numbers to Tier 1 acquiring banks (not Joe Web Developer).
Officially (it took me 2 years of chasing Visa on this) it is up to the acquiring banks if they wish to then share this with Merchants.
Some acquirers do, some won’t, many certainly won’t provide it with sufficient updates to ensure a developer has wholly accurate data.
I have spoken to countless web developers who use this data to know that I could introduce a bogus BIN range document, get it up the Google rankings and ruin forms that assume the type!
Although I agree that credit card form design is un-inventive and assumes the status quo is right just because it exists, don’t assume this field is simply about lazy me-too development.
Try telling a non tech savvy website owner you had duff BIN data when he balls you out for a good clients payment being rejected because your form submitted his transaction as Visa credit when it was Visa Debit or Electron. I’ve seen this happen and would excuse any developer from taking the safety first approach.
One thing I can say for certain – a Luhn / Mod 10 check in jS is quite sensible, but anyone who is putting assumed BIN ranges into their jS is not only risking mistakes, but potentially making their client non-compliant in the eyes of Visa/MC over this data’s publication!
@Jeff. Well I don’t think your bullshit filter failed as Khoi suggests! You’re absolutely right about why some people ask for card type as an extra layer of validation.
Although 3D Secure and CV2 are simpler and more effective these days, any extra questions are always healthy, there are still some older card forms that still ask who your issuer is too!
Some developers are lieing if they pretend the field exists because they’ve thought about it, but the answer you heard is still genuine and not just bullshit. Promise!
There is a general rule of thumb I’ve seen in payment processing and card scheme compliance that the less information you collect the higher risk you are. This is no different.
@Stevie D. You’re spot on – redundant info is important. Your example is useful, if only because the UK is the only country in the world where AVS (address validation) is compulsory if requested – so abstracting address information fields in web forms is a high risk business on any non-UK . And in any case AVS is risky altogether because it just checks numbers and is easily spoofed. If I gave my address without a postcode but as Room 1012, I could pass AVS for 10 Downing Street SW1A 2AA. I’d just need Gordon Brown’s credit card 🙂
@
Sorry, not post-hogging but having re-read the blog while relating it to a colleague, I realise I should have added something far more fundamental and basic too, to this discussion.
It’s not enough to simply say ‘it begins with 4 it’s a Visa, 5 it’s MasterCard’. These schemes have a range of credit and debit subtypes which need to be identified too.
What PayPal have done is certainly not new and nor is it ingenious, changing the opacity of the logos as a result of the keyed data is neat but abstracting this field isn’t new.
The point is to draw these conclusions in the browser using jS is innaccurate and falible. 5 followed by all the zeros in the example isn’t even a valid card number let alone MasterCard.
To me, and I’m sure the card schemes, drawing this visual connection between their brand and potentially innaccurate data entry, is unhelpful and promotes confusion and concern.
I could key in a UK Maestro card which would light up Visa logo and International Maestro cards that would light up the MasterCard logo. But they would have neither logo on the card.
How is this ingenious? From a user point of view it would put me off making payment on an inaccurate form and from a business point of view it may mean submitting invalid payments.
Usability is hugely important but sacrificing valid user input and authentication just to look smart in the browser at the expense of accuracy is design for all the wrong reasons.
My view is that the achievement which you have rightly highlighted as desirable would only be valid and commendable if handled server-side using full and legitimate card scheme data.
Okay this adds a server request to the process (less pronounced with Ajax etc) but doing this in the browser is gimmicky and flawed and far from the ‘breakthrough’ you describe.
Rob: I am delighted you’ve put about 10,000 times the thought, energy and critical analysis into credit card forms that I have. I wish I had that kind of time on my hands.
As someone who has only applied a cursory look at the way these forms behave, I admit that my use of the word ‘breakthrough’ may have been inaccurate.
Still, it worked for me and I liked it a lot.
I think it’s good to have the form field there, and I like how PayPal has done it. The problem is that not all people know 3 = AMEX, 4=VISA, 5=MC so they’re looking for the option to select their credit card. If they don’t find it then they think they’re missing something.
I really like how PayPal does it, but I think the form field for credit card type has to be there.
If anyone is interested, Luke and I are actually proposing a joint presentation for SXSW next year (it’s in the panel picker). The session would be 1/2 theory and 1/2 practical application of that theory in code. It should be pretty interesting if we get the votes.
I’ve seen a few comments around the idea that visitors don’t know that the first digit of a card number = the credit card type. My question is… Why should they care? Customers don’t need to know that 4 = Visa, or 5 = MasterCard, we do.
When I walk into a store, all I want to know is that the credit card I plan to use is accepted at that store, not the technical details of how a credit card is identified.
My usual purchase process goes something like this:
1. I bring my stuff to the register
2. The cashier tells me the final price
3. I hand them (or swipe) my card
4. Payment processed
5. End of transaction
It doesn’t usually go like this:
1. I bring my stuff to the register
2. The cashier tells me the final price
3. Are you using Visa?
4. Are you using MasterCard?
5. Are you using American Express?
6. Are you using Discover?
7. I hand them (or swipe) my card
8. Payment processed
9. End of transaction
I’ll digress for a moment and say that they will occasionally ask me if I want to put it on *their* charge card, but that’s just a marketing gimmick to get you to sign up for their card. So why do we ask visitors what credit card they are using? As Khoi pointed it out, it’s certainly not for security.
I agree 100% with @Christopher Fahey:
I think that the credit card drop down box is a piece of legacy web development that has stuck around way past it’s time, if it ever had “a time”. We can totally obfuscate the entire credit card check/security process by adding a few, simple lines of code.
@ Khoi: You’re right about the invisible credit card images being a bad idea, and I think the solution is simply to move the existing ghosted credit card images up to the right of the number. That way they’d look follow the “row of logos” convention, functioning like the credit card sticker on a restaurant door. The correct credit card logo would become fully saturated once the user starts typing the number, making it clear they don’t need to make any further designations.
In the interest of further usability, some explanatory text might be helpful in this situation, as people generally aren’t accustomed to credit card type auto-selection. Something like: “Just start typing your credit card number; your credit card type will be selected automatically.” But that might not be enough to eliminate confusion (“Automatically? How does it do that!?”) so:
I see this as an analog to the “VIN” number that started being added to credit card forms a while back. At first it required special explanatory popups and the like, but now it’s more or less ubiquitous and understood. Maybe it wouldn’t be a bad idea to provide the same explanation for this functionality.
Another issue was brought up by my colleague Cody: If any of the underlying patterns ever changed, the validation would suddenly stop working and become incredibly confusing. He suggested talks with the credit card companies (to ensure correctness) would be the best way to avoid this potential issue. He also added that removing the credit card type field gets rid of another check against the user entering bad data, and that removing it could be potentially hazardous.
The lesson here, I think, is that any serious change in the established routines of design (credit card forms, in this case) need to be approached from a number of angles and the repercussions considered fully before moving forward.
Personally, I think the winner here could be the solution of only showing a single image (invisible at first) which would show up upon verifying the card number and inferring the card type from it. But only, as Rob F pointed out, if the verification is strong and done server side (Ajax is a blessing for that, I think). Finally, right beside the card icon a small type link saying something like “(not this card type?)”, which when clicked would bring out an old fashioned way to pick out card type.