Need someone to lead product management at your software company? I create software for people that create software 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 20 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.

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.

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

Great prodct managers own the outcomes (May 14)
Being a product manager means never having to say, "that's not my job."
Too Big To Fail (Apr 9)
When a company piles resources on a new product idea, it doesn't have room to fail. That keeps it from succeeding.
Go small (Apr 4)
The strengths of a large organization are the opposite of what makes innovation work. Starting something new requires that you start with a small team.
Start with a Belief (Apr 1)
You can't use data to build products unless you start with a hypothesis.
Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2024 Adam Kalsey.