Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

More Form usability

Freshness Warning
This blog post is over 17 years old. It's possible that the information you read below isn't current and the links no longer work.

Paul Scrivens has some additional ideas about making Web forms easier to use.

He suggests using a single name field instead of separating first name from last name unless you really need the names separated. The problem with this is that you never know what future uses you might have for that data. If you don’t make sure it’s in a format you can use, it’s useless. I’ve been on countless projects where I had to go back and reconstruct data that people didn’t collect because they thought they’d never use it. Common sense should prevail, however. Blog comments would probably be overkill to have separate fields. Use what makes sense in your situation.

I also suggested to Paul that you should only provide a single phone number field and said that you can clean up whatever the user enters with some simple code. I should elaborate. I’m not taking a programmer’s view for entering phone numbers, I’m taking a user-centered view. As Paul noted with the first name last name issue, it’s harder and more time consuming to fill out two or three fields than it is to fill out one. People see a phone number field and they start typing. A hunt and-peck typist will often have entered their entire phone number before they look up at the screen and realize that all the system accepted was their area code. They then have to make the conscious effort to click in the next field and fill it out. They then switch back to their mouse, click the final field, and fill it out. It’s amazing how many users don’t tab through fields.

One solution I’ve often seen to this is to automatically progress to the next field when the required number of characters are filled out. This frustrates users. They made a mistake on the last digit, but hitting backspace doesn’t work because they’re now in the other field. Or they usually tab through fields so they enter the area code and hit tab, skipping the second phone number field.

Of course, it all depends on the situation. If the application is an internal data-entry form that is used hundreds of times each day by the same person, you need to optimize for speed and to reduce keystrokes. In that case, you can (and should) sacrifice usability for speed. All that is required to overcome the lack of usability is a little training. Call center operators can easily learn that when they enter an area code, the cursor automatically moves to the next field and will actually appreciate the step. In this case “easier” actually means “faster.”

But if the application is something that someone is only likely to use on rare occasions, optimize for usability at the expense of speed. A checkout form on an ecommerce site is a good example. Make it easy to use. Anticipate the choices they are going to make and account for them. Ask for their phone number and let them enter it however they want. You can clean it up with the code. The thing is, unless someone’s a programmer or familiar with database concepts, they won’t wonder at all what format their number should be in. It doesn’t occur to them that there’s any reason a phone number would need to be in a certain format.

Paul Scrivens
July 18, 2003 12:35 PM

On the single name field idea, I believe your last sentence sums up my thoughts: Use what makes sense in your situation. Great point on the phone numbers and I completely see your point. However, I still believe that it would be easier from a user's perspective if they saw three small fields and would automatically know how they should input the phone numbers. Therefore you are guaranteed to get the data in the format you want. Yes it is somewhat more difficult to input data into more than one field, but for this example I believe it would be best. However, though you are making me doubt the way I am looking at the problem so I will definitely have to think this over some more. All in all you made some excellent points (as usual). Thanks for the insight.

Paul Scrivens
July 18, 2003 1:42 PM

Alright, Microsoft has forced me to change my mind on the whole matter and I totally agree with you now. I was installing XP on a computer and messed up on the serial key part and tried to backspace to the previous box and it wouldn't let me. Sounds like what you were talking about. Point Kalsey.

Jemaleddin S. Cole
July 19, 2003 6:04 AM

The worst thing about auto-advance forms is that I'm accustomed to hitting tab after each element - I see three phone number blanks, I type "123 tab 456 tab 7890". Except what I get is "(123) -456" and "7890" for my address or something. Blech. The principle of least surprise is called for here.

ThaNerd
July 21, 2003 5:12 PM

About this matter, met me tell you about my experience. I live in Belgium. And since i got my Visa, i started buying stuff online, mostly either from france or from USA. And about those phone number fields, let me tell you this: if in USA, phone numbers are like (xxx) xxx-xxxx, in France, they are like 0x xx xx xx xx (ten digits). But in belgium, they are either 9 digits. BUT! Mobile phone numbers are 10 digits. All numbers start with a 0, and zone field is either 3 or 4 digits. So a big problem i had, when i was asked on a few websites for my phone number, was to be told that my phone number was not correct. Even further, when i write down phone numbers anywhere, i often write them in international format: (+32 (84) 315450), and as a result, this is what i usuall type in phone fields in forms (without the parenthesis). And of course, most form validation schemes tell me "to use numbers". Now about the multi-fields trick, it could be though about deeper. Like, automatic jump to next field, but going back to previous field if either "tab" or "backspace" was pressed... It Can Be Done.

Barbara
December 9, 2003 11:58 AM

I'd like to stress the points ThaNerd made, think about international users! (and international does not just mean Canada like Crate&Barrel assumes). Zip or Post Codes can be anywhere in front or behind the city, there may be numbers and letters, special characters... Same with the phone number. Just like ThaNerd said, he'll put it in the form in the correct international format so why not just trust your users to make the phone number usable for you. Phonenumbers can have lots of digits don't limit the field to 9 digits! (so annoying!) Just some suggestion from germany.

Nick Gassman
December 13, 2004 3:44 AM

If you have a free-format field, and rely on sorting it out, then software may or may not be able to tell if people have included and international code or a region code. Also, if you require the international code, you could just indicate this in text against the entry box, but it would probably be clearer to the user if there was a separate entry box for it.

This discussion has been closed.

Recently Written

Domain expertise in Product Management (Nov 16)
When you're hiring software product managers, hire for product management skills. Looking for domain experts will reduce the pool of people you can hire and might just be worse for your product.
Strategy Means Saying No (Oct 27)
An oft-overlooked aspect of strategy is to define what you are not doing. There are lots of adjacent problems you can attack. Strategy means defining which ones you will ignore.
Understanding vision, strategy, and execution (Oct 24)
Vision is what you're trying to do. Strategy is broad strokes on how you'll get there. Execution is the tasks you complete to complete the strategy.
How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.